The purpose of this article is to describe the store-and-forward mechanism implemented in payment gateway software in the cases when transaction processing becomes impossible due to temporary loss of connectivity with the processing “back end” (for instance, a bank) or due to some other errors.
As we explained in one of the previous articles, issues with transaction processing might be caused by one of the two conceptually different reasons: timeouts and errors. While the previous article focused on timeout handling, this one focuses on offline transaction processing, which is made possible by implementation of store-and-forward technique.
The essence of store-and-forward approach
Originally, when modems were introduced and connection was not always stable, the so-called offline transaction processing concept was developed. Usually, offline transaction processing is implemented at the level of a payment terminal (as it is a standalone device, independent from the host application). Sometimes, this solution is referred to as store-and-forward. On the basic conceptual level, the terminal stores transactions and, once connection is reestablished, it sends them to the host application for processing. The transaction is not actually submitted for processing immediately, but rather a “fake approval” is generated for the sale to be able to complete. The actual transaction information is then stored and processed once the connectivity is available. The underlying assumption, supported by the general experience, is that the card is going to be processed, and money will be available for the given transaction at a later time.
The advantage of store-and-forward mechanism is that transactions which did not go through at the time of initial attempt can still be processed later, and, in most cases, get approved.
The disadvantage of store-and-forward mechanism is that, sometimes, once the system is operational and the previously stored transaction is reattempted, it gets declined.
The systems which support offline transaction processing have to store credit card numbers for some time. Consequently, operators of such systems need to take care of PCI-compliance and respective cardholder data storage-related issues {link}. As a result, systems which do use offline processing need to implement encryption of track data or other approaches in order to minimize PCI consequences.
Offline transaction processing is most suitable for e-commerce businesses, where a customer does not get purchased product immediately after the purchase, leaving some time for transaction re-processing. The approach is also applicable for service providers (such as newspaper subscription, dating web-site subscription) because, in theory, a service can be terminated (canceled) the next day after a customer ordered it. On the other hand, retail businesses may find it difficult to use offline processing, because once a customer gets the purchased product, it is problematic to track this customer if some transaction processing issues arise after the purchase is made. That is why retail businesses usually utilize the approach only on small amounts (usually, under $50).
There are two common scenarios for offline processing implementation. In retail businesses it is usually implemented at the level of payment terminals, while, in general, the approach can be utilized at payment gateway level as well. Some processors also offer offline processing at the level of their own payment systems. Regardless of the level of its implementation, the general store-and-forward mechanism used for offline transaction processing remains conceptually the same.
Conclusions
Offline transaction processing is a relevant solution for e-commerce businesses, experiencing communication problems with the host payment processing application.
Recommended to you
