Payment Processor Errors / Retry Failed Auths

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Payment Processor Errors / Retry Failed Auths

J. Eckard-2
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

Reply | Threaded
Open this post in threaded view
|

Re: Payment Processor Errors / Retry Failed Auths

Jacques Le Roux
Administrator
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
>
>