In this and subsequent articles we are going to address different concepts, which are relevant for payment gateway software developers.
The purpose of this article is to provide recommendations, allowing payment gateway software developers to enhance the efficiency of servicing of payment gateway customers.
One of the most common processes in the context of a payment service company operation is the process of integration between various third parties and the payment gateway used by the company. Among such integrations are:
- new customers (merchants)
- new software companies that want to resell merchant services
- existing online services (such as shopping carts), that want to offer processing through this gateway to their existing customers, or simply offer their services to the clients of this particular payment system.
In all these situations it is necessary that some external software package is integrated with the payment gateway, so that transactions can be submitted for processing.
The process can, generally be handled in two ways.
What payment processing emulator is needed for
In the legacy systems, merchants were expected to built their integration logic and then submit a certain number of test cases for review by the integration team of the payment service provider. Generally, it was necessary to do so, because emulating capabilities of the integration sandbox were extremely limited (there were no efficient ways to emulate all kinds of processing behavior). Another reason was that, usually, the format of the message itself was extensive and complex, and no proper validation of values of the fields was implemented in the legacy system. In other words, in some situations the system itself was able to identify structural problems, but unable to identify any issues with particular values. For example, correctness of formatting of Level III data could not always be verified by the gateway itself.
In contrast to legacy systems, modern systems take advantage of payment processing emulators. An emulator allows a payment gateway to detect all errors in the incoming messages from merchants, without involving actual operators (real people) for that purpose.
Payment processing emulator features
Most payment gateways today support the basic responses for simple retail (sale) transactions. Usually, a particular response, which a gateway (emulator) sends back to the merchant, is triggered by the amount of the transaction.
However, beside standard retail transactions there are certain additional services, which also have to be supported (emulated). These include account updater, handling of chargebacks and ACH returns. These services also have to be tested during the integration. Traditionally, respective tests were performed manually, but automation of the process makes it much more convenient.
Most modern payment gateways use emulators, which allow them to simplify the process of integration. Consequently, if you are developing a payment gateway, you should implement an emulator, capable of performing several important functions.
While developing a payment processing emulator, you need to consider not only basic sale scenarios, but also scenarios for additional services (including, account updaters, BIN files, AVS, etc).
In your real-time processing software piece you should consider emulating such services as AVS, CSC verification, and 3 D secure verification. In your batch processing software piece you should consider emulating credit account updater or CAU, ACH returns, and chargeback emulation services.
For example, your 1emulator must be able not only to generate an approval or some type of decline for a sale transaction, but also to trigger a specific CSC or AVS response, using a specific card security code or address, thereby, allowing the integrators to verify, that they are submitting this information correctly, and get the responses back as expected.
A traditional problem of the legacy systems in this context was qualification of some transactions for high interchange, because certain data fields (address, ZIP code) were missing. Having a proper payment processing emulator in the system provides the merchant with the ability to address these issues before they even “go alive”.
Conclusion
In some cases you can or need to perform manual review of a particular integration
(of the transactions the merchant is sending). However, in order to increase the productivity and efficiency of the integration process, it is very useful to have a good emulator implemented as part of the payment gateway software. Availability of emulators is extremely important for payment gateways, targeted at small businesses and servicing large numbers of small and medium-sized merchants.