Maybe we could fix and add a test for that (test possible with default payment
elements?)
Jacques
From: "J. Eckard" <[email protected]>
I think I've found a problem with the way payment processor errors are handled.
During the execution of authOrderPaymentPreference, your proccesor-specific authorization service will be called. If that service
returns an error, then authOrderPaymentPreference will log an error message saying that "the maxAmount was 0" (this is not true),
and then cancel the payment preference and return an error indicator.
If the product store's retryFailedAuths setting is Y, then the error indicator is ignored and processing will continue (i.e. the
order will not be rejected or cancelled). This is so the retryFailedAuths service can re-authorize the payment preference later.
However, the payment preference was cancelled and will never be discovered by retryFailedAuths.
I tried to find out when this logic was added, but it looks like it has been in place since the initial import in 2006. Is anyone
using retryFailedAuths successfully in production? I may be missing something.
To reproduce, starting with a clean install:
- Go to Catalog Manager > Stores > [9000] OFBiz E-Commerce Store > Payments
- Change the Credit Card Payment Authorization Service to
"alwaysFailCCProcessor"
- Place an order for Demo Customer using a credit card
