I did not change it yet in the case of PAYMENT_DECLINED, since I think that, in such case, the transaction may be retried one or more times. If it's well done I suppose that at the end of transactions (with success or not) securityCode and track2 are "nullified" in the DB. So for now I only nullified int the case of PAYMENT_ERROR and I hope it's the exit door (did not look further)

Jacques Le Roux
added a comment - 12/Apr/08 14:55 I did not change it yet in the case of PAYMENT_DECLINED, since I think that, in such case, the transaction may be retried one or more times. If it's well done I suppose that at the end of transactions (with success or not) securityCode and track2 are "nullified" in the DB. So for now I only nullified int the case of PAYMENT_ERROR and I hope it's the exit door (did not look further)

For cases 1, 2 and 3, just report back declined. The customer may enter in a different credit card. For case 4, you shouldn't retain the cvv code past the initial transaction.

In reading the code, there was some retry logic for a not sufficient funds (nsf) case. Could anyone explain when this is actually used? I'm having a hard time figuring out when you wouldn't just report back to the customer with a decline.

Chris Lombardi
added a comment - 12/Apr/08 15:48 I'm not sure of the scenario where you wouldn't just report back to the customer that their card has been declined and instead retain the cvv code for later retries.
1. Online e-commerce
2. POS
3. Card taken over phone by sales
4. Recurring subscriptions
For cases 1, 2 and 3, just report back declined. The customer may enter in a different credit card. For case 4, you shouldn't retain the cvv code past the initial transaction.
In reading the code, there was some retry logic for a not sufficient funds (nsf) case. Could anyone explain when this is actually used? I'm having a hard time figuring out when you wouldn't just report back to the customer with a decline.

The NSF retry stuff can be used for any order, but is mostly intended for automatic orders done through ShoppingLists.

Either way, it totally depends on business policy and desired process.

For CVV codes it doesn't matter anyway. You cannot store or in any way remember them beyond the time scope of the transaction they were entered for (and if it is split into auth and capture then that would be ONLY the auth part you can keep the code for).

That means for ALL automatic retries you will not have the CVV code, and will not get the benefit of the discounted transaction fee for having the CVV code. That's the only real difference.

Again, it's all a business decision to be made with an understanding of these sorts of constraints. Whatever is done OOTB in OFBiz needs to be changeable to different situations. Well, it is always changeable, but the goal is to make more common variations easier to configure.

David E. Jones
added a comment - 13/Apr/08 17:45 The NSF retry stuff can be used for any order, but is mostly intended for automatic orders done through ShoppingLists.
Either way, it totally depends on business policy and desired process.
For CVV codes it doesn't matter anyway. You cannot store or in any way remember them beyond the time scope of the transaction they were entered for (and if it is split into auth and capture then that would be ONLY the auth part you can keep the code for).
That means for ALL automatic retries you will not have the CVV code, and will not get the benefit of the discounted transaction fee for having the CVV code. That's the only real difference.
Again, it's all a business decision to be made with an understanding of these sorts of constraints. Whatever is done OOTB in OFBiz needs to be changeable to different situations. Well, it is always changeable, but the goal is to make more common variations easier to configure.