Handling Errors

In the varous payment scenarios quite a few things can go wrong, not the least of which is the user closing his or hers browser in the middle of a flow/request. This section tries to outline different strategies for handling errors and unforseen events.

Abort Payments if possible

No matter what type of error you have, it is always a good idea to attempt to cancel the ongoing payment, both to inform the backend system that the payment was cancelled, and to ensure it is not re-used in some unexpected way (the browser's back button can do strange things). A payment can be aborted by using the method CancelPayment.

Record unexpected errors

If anything fails, a web service returns an unhandled soap fault, the payment provider returns a strange error code or something similar. Try to record the payment process id that was involved in the flow and possibly as much information such as the request details, and the exact error/response details. Make sure these details are timestamped and sent to the right people for analysis.

It might be that it is not an error at all, in which case the web client should be adapted to handle the error. An example might be that the provider detects that the credit card is fake and sends an error code back - this should of course be handled, but quite often it is not.

Report on "Instant" payment errors

If you are using the instant payment flow and some error happens after having been returned from the provider.
For instance "CompleteSubscription" fails or an external database failure or one of a thousand other things.
In these cases the money has been withdrawn from the customer, and as such someone should react on the failure and possibly handle it manually.
They cannot be cancelled, and should possibly be credited if the order cannot be completed otherwise.

Infosoft recommends to report any such occurences either by mail or some other means.