Integrating Payment Providers with AWS

Enabling smooth and secure transactions is critical to successfully running an e-commerce platform, a SaaS application, or a digital marketplace. Customers expect a streamlined checkout experience with their preferred payment methods, minimal latency, and absolute security.

For developers and businesses, integrating payment gateways is rarely (if ever) straightforward. Between API complexities, handling webhooks for real-time updates, managing PCI compliance, and accommodating a diverse range of payment processors, the process can quickly become a challenge. Even a minor misstep - like a delayed confirmation or failed tokenization - can result in frustrated users, abandoned carts, and lost revenue.

Integrating a Payment System for a Global Publishing Platform

Our team was given the task of integrating a payment system for one of our clients - a well-established player in the publishing industry. The challenge was clear: they needed a payment system capable of handling subscriptions, one-time purchases and international transactions.

Integrating even the most known payment systems comes with its own technical, social and flow-wise hurdles. After all, it is not ideal to send users to a different page, which might make them worry about having to deal with two new companies simultaneously.

We created an AWS Lambda function to handle all processing and connection with the payment provider’s API. However, attempting to connect with the payment system would fail randomly. We investigated all requests and couldn’t find the source of the problem. We searched for a potential bug in all services related to the payment, but could only find information about our payment being rejected by a third party protection system, without any reason as to why.

Soon, however, we noticed a pattern - the connection would fail for a couple of hours, after which it would work again. This prompted us to reach out to the payment service provider.

Uncovering the Hidden Roadblock in Payment Processing

We were met with non-answers - assuring us that the problem must lie on our end. Every developer knows how discouraging poor customer support can be, combined with a lack of relevant resources on the web. Disappointed, but not surprised, we reached out to fellow developers at Stack Overflow in search of answers. Turns out we were not the only ones with this issue and in fact, most of the other developers struggling with it were using cloud-based services as well.

With the new-found knowledge, we decided to share the post with customer support along with the IDs of failing requests and they could no longer blame us for a faulty implementation or incorrect cyphers. We finally received a positive response, announcing a solution, alongside a description of the root cause of the problem.

All of the people struggling with the issue were using some sort of a web-based function that would not have a static IP assigned to it. The third-party system, that the payment provider was using, had a protection that would prevent known bad actors from performing certain operations, based on the IP address. We can only assume that some of the IPs in Amazon’s pool were used to perform malicious actions and that is why we were getting blocked, whenever a function was run on one of those machines. The solution was to turn off that firewall for the clients, but as a precaution, we decided to create a dedicated set of IPs for our functions, so that a similar problem would not happen in the future.