Transaction Success Rate | Security | Easy Payment Gateway Integration

 

Problem Statement:

• How can payment gateway integration impact online payment transaction success rate?
• How to integrate a payment gateway to achieve security, and transaction success rate?
• How can payment gateway integration make or break an online business?

Target Audience: Online Merchants, Payment Service Providers, Digital Payments Software Developers and Testers.

While integrating with a payment gateway, always focus on integration security, online payment transaction success rate, ease of integration and integration test-ability.

Security: Attackers can fraud online payments participants, be it online merchant, payment service provider or the buyer. You would want to know the following.

• Protection from man in the middle attack - Attackers use this attack pattern to exploit loopholes in payment integration. Here is another post of mine for providing details about this aspect.
• Passing un-required but sensitive information parameters in a web based transaction. For example a merchant is not supposed to pass hashing seed in the parameters when a buyer is redirected to payment page.
  
• Passing invalid parameters to payment gateway by merchant. For example refund amount more than captured amount. Always validate the fields before sending them to payment gateway.
  
• Transferring data in an unsecured/non-encrypted channel (eg. HTTP instead of HTTPS). It's must to use HTTPS.
  

Online Payment Transaction success rate: A failed online transaction is a direct business loss. It also adds to frustration of customer, makes the payment experience poor and the buyer may not want come again. It also adds to customer care issues. Know the following in this regards.

• A payment gateway may reject or invalidate a transaction if the merchant is sending invalid or un-required parameters. It also makes the message payload heavy and consumes more network bandwidth. Ideally, if possible, a payment gateway should attempt to correct invalid parameter. For example a payment gateway can ignore an optional but invalid value instead of rejecting the transaction. There can be various such ways to sanitize the parameter values.
• A merchant should make a server to server status inquiry when a buyer is not getting redirected to merchant system from PG in a defined time. It might happen that the buyer has paid but was not redirected to merchant because of some network issue. It would also reduce any duplicate payment related issues. Would make the buyer feel good because the buyer would get to know that the payment has been made and accepted by merchant else it leads to buyer feeling uneasy about the payment status.
  
• A Payment Gateway should send a notification to merchant system that the transaction has been successful. This makes it double sure that merchant system gets to know about success of the transaction. Usually this feature is optionally given by all payment gateways but sometimes merchants do not use the feature which creates other issues. The best way to send the notification is to call a restful API of merchant system to update that the payment has been successful failure
  
• A merchant should make status inquiry transaction, if there is a timeout in a particular transaction. For example, if merchant initiated a refund transaction but did not get response. Before invoking a duplicate refund, ideally the merchant should make a status inquiry to validate if the previous refund transaction was successful or not. Same might be applicable to a sale transaction.

 Ease of integration: Following are important steps for ease of integration.

• Integration specification documents - Integration specification documents has to be up-to date, clean, simple, full of examples and details. It's always better to provide examples for various scenarios, details of each parameters, flow diagrams, and information about integration kits in different programming languages.
• Plugins for popular e-commerce platforms - It's always better that the payment gateways always provide integration plugins for different e-commerce platforms like Magento.
• Integration kits in different programming languages - It's a must the the payment gateway provide integration kits in all different programming languages. Like Java, Python, Go, PHP, C#/.NET etc.
• Integration support - A payment gateway needs a team to give support the technical teams of merchants at the time of technical integration
  

Integration test-ability: Automation integration tests - Integration kits in different programming languages needs to have various test cases to cover various scenarios. For example - A positive/negative test case for validating the message hash. A test case for a failed transaction, a test case for a duplicate check, a test case for a fraud transaction, a test case with/without optional fields, a test case capturing an un-authorised transaction, a test case to initiate a refund against a not captured transaction etc.

Thanks for your read. Please comment if you liked my post or need more details.

Man in the middle attack – Protect online merchants & payment solutions

 

Problem Statement:

How to protect from man in the middle attack in the payment’s world?

How to integrate a payment gateway in a secure way?

Why payment gateways and online merchants need to validate hash?

Example: When a payment gateway returns response to merchant system that a transaction has FAILED, the man in middle changes the status of the transaction to SUCCESS while the message is on the way, merchant gets a transaction response with status as SUCCESS, and merchant delivers the product or service to attacker but the status of the transaction with payment gateway is FAILED.

What & How: An attacker can change content of a message when the message is on the way between two payment systems. This is an old but frequently exploited attack pattern. The above is a very basic example of such an exploit.

But you will ask me how the message can be changed when it’s secured with HTTPS encryption – It can be done without spending much time. There are different ways, mainly it captures the content of the message on the web-browser using some tools and changes the content. If you want to learn how to perform an attack, then you may want to search the internet for how to guides. It’s hard to perform such an attack in a server-to-server API call, but it’s easy in case the message is flowing through the web-browser. For example, an HTTPS POST redirect by payment gateway web-application to web-application of merchant.

If you need a protection for your online payment system or not? It’s not a question of If. It’s only a matter of time when the attacker targets you.

How to know if your system is already under attack: A very basic symptom of being a victim is that there are differences in transaction status at different payment systems found at the time of reports reconciliation. For example, a merchant would say that payment gateway returned SUCCESS for a transaction but payment gateway company status that they returned FAILED. This can be validated by comparing the logs or database of the merchant vs payment gateway. One hint is that such reconciliation issues will be found with transactions of higher amount only. But sometimes it can be much sophisticated.

What can a payment gateway or online merchant do to protect against man in the middle attack:

• Validate the message hash: All messages flowing through the payment systems can be validated by generating and validating hash. It’s a simple, effective way to protect. Just make sure that there is a unique seed for each client, and the seed is not supposed to be part of the message. Only the client and server must be aware of the seed at the time of generation and validation of the hash. Make sure that you are using a modern hashing algorithm.
• Change the hashing seed on regular interval: The hashing seed should be changed on regular intervals, may be quarterly. It should not be same for ever because sometimes it’s shared with other people without understanding the consequences. It’s like you change login password with banking systems.
• Perform a server-to-server API based inquiry: A merchant can perform a transaction status inquiry with payment gateway to be double sure of the transaction status before delivery of goods/services. A payment gateway should also perform a status inquiry (with payment processor/acquirer) before delivering a successful response to merchant. Such an inquiry should be a server-to-server call only. Almost all payment systems in the world support such inquiries. Such enquirers can be exposed through restful APIs or ISO 8583 messages.
• Reconcile your payment reports daily: A merchant must reconcile the payment reports on daily bases and should be vigilant of any mismatches. Similarly, a payment gateway should reconcile with up-stream payment solutions.
• Have positive & negative integration tests: The integration test suite must have positive and negative test cases to validate the hash. Such tests must be performed at the time of integration between two payment systems. Such test cases should also be documented in the integration specification documents and should also be part of the integration kit. The technical integration team must perform these tests before the client on-boarding is completed.
• Test invalid hash transactions on production on regular bases: One such production test case can also be set to regularly test if the hash is being validated properly.
• Be vigilant: While the above-mentioned steps can be performed but your information security is not limited to these steps. Being vigilant about what’s happening in the system and having a mind-set of security is must for protection against sophisticated attacks.

 

Thanks for your read. Don’t forget to comment if you need further information.