Maybe we could fix and add a test for that (test possible with default payment elements?)
Jacques
From: "J. Eckard" <
[hidden email]>
>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
>
>