Hi all, I wanted to follow up to Perrito's email, since we have investigated this and found that this isn't something new or an unexpected behavior, but a design issue in GetPaid itself. As such I wanted to consult the community on how to get the best solution here.
The problem only happens when a user is purchasing something and enters incorrect credit card information and then tries to enter the credit card info again (while data being sync'ed to rdb via getpaid.report). The user won't be able to do so and will have to start over in making their cart and checking out. This problem occurs due to the syncronization of the information about orders to the relational database (via getpaid.report) [1]. The syncronization is recording the failed transaction (potentially useful for auditing how many transactions fail). However, this is inconsistent with how the basic GetPaid transactions are recorded, which only occur on a successful checkout. So, two options arise: 1. Make getpaid.report function like GetPaid: getpaid.report would ignore failed checkouts in this case. 2. Make GetPaid consistent with getpaid.report: failed orders would get an ID and be marked in the "PAYMENT_DECLINED" state and be queryable from the order admin screen. Probably slightly more than (1) in terms of effort, but we just started looking into this. Any more ideas here? Basically the question is: Is information about failed checkouts useful? Please let us know what you think!!! Regards, Chris [1] More specifically, as Horacio described, at the code level: When a user performs the checkout at the last step, when the order is created, we notify OrderCreation which is good, all subscribers are triggered and everything is good but, if the payment processing fails then when the users goes back and corrects his payment data (supposing the problem is fixable and can then finish the purchase) the create notification is triggered again for the same order creating for instance, an error in getpaid report that tries to create again the order in the db and fails with a unique constraint violation. On Tue, Sep 30, 2008 at 12:38 PM, Horacio Duran <[EMAIL PROTECTED]>wrote: > > Hi I (actually a client) noticed because an error thrown by sqlalchemy > in getpaid.report the following behaviour. > When a user performs the checkout at the last step, when the order is > created, we notify OrderCreation which is good, all subscribers are > triggered and the world is happy but, if the payment processing fails > then when the users goes back and corrects his payment data (suposing > the problem is fixable and can then finish the purchase) the create > notification is triggered again for the same order creating for > instance, an error in getpaid report that tries to create again the > order in the db and fails with a unique constraint violation. > The question is, this should be handled in the order creation code and > rething where to notify create or in the subscribers and make sure > this is not the first time we see create? > I believe the first but would love to hear your opinions. > -- > Perrito > > > > -- Cofounder and CEO ifPeople - Innovation for People www.ifpeople.net t: 678-608-3408 130 Boulevard NE, #6 Atlanta, GA 30312 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "getpaid-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/getpaid-dev?hl=en -~----------~----~----~----~------~----~------~--~---
