Amazon integrates with dozens of payment processing partners to handle customer transactions across international markets. However, the core payment workflow was originally designed around credit cards, where merchants initiate authorization and settlement requests against a customer’s credit line. This model did not accommodate alternative payment methods common in other markets, including installment payments, mobile wallets, and real-time payment networks.
These limitations created a barrier to entering new markets and supporting locally preferred payment methods. For example, in Brazil, installment payments are used over half of all retail sales and new real-time payment networks, such as Pix, are displacing cash and credit card transactions. We addressed this barrier to enable Amazon’s expansion into the Brazilian market.
Asynchronous payment methods created a new interoperability challenge.
Traditional versus asynchronous payment processing flow.
Unlike conventional credit card transactions, some alternative payment methods require customers to complete an action outside Amazon’s checkout flow. For example, a customer using a real-time payment network may need to approve a transaction through an external application. The payment processor then notifies Amazon when the payment is completed, potentially minutes, hours, or even days after the original request.
Amazon already had a pluggable enterprise service bus (ESB) for routing outbound payment requests to processors while maximizing code reuse. This ESB could handle API and protcol translations at scale. However, this architecture lacked a corresponding mechanism for receiving asynchronous notifications.
Building a separate notification service for each potential payment processor would have introduced duplicated functionality, increased maintenance overhead, and expanded the externally exposed attack surface to cyberattacks. We needed a reusable integration layer that could accommodate multiple processors and protocols without requiring a separate service for each integration.
Developing a dynamic reverse proxy and API gateway solution.
Simplified component diagram showing the functions of the reverse proxy service.
We developed a dynamic reverse proxy service to provide a common, extensible entry point for inbound payment notifications. The service supported multiple independently managed backend services behind a shared endpoint, using configurable routing rules to direct incoming requests to the appropriate handler.
Unlike most reverse proxies, this proxy could be updated dynamically, including adding, modifying, or removing services and routing rules without restarting the proxy. This allowed the integration layer to maintain uninterrupted availability for independently operating services.
A key requirement was support for heterogeneous payment protocols. Most web services use text-based protocols such as SOAP and REST, but some payment processing standards rely on binary formats, including ISO 8583. Our reverse proxy supported both text-based and binary protocols.
Combined with Amazon’s existing plugin-based message translation service, the reverse proxy formed an extensible API gateway. This architecture enabled Amazon to integrate with different payment processors and standards through a shared interoperability layer, while supporting secure handling of payment data and operational changes without disrupting service availability.
Enabling new payment methods and international expansion.
The new integration architecture enabled Amazon to launch full retail services in Brazil with support for locally popular installment payments.
By providing reusable infrastructure for asynchronous notifications and heterogeneous payment protocols, the solution also established a foundation for integrating additional alternative payment methods and supporting expansion into other markets. For example, the architecture contributed to Amazon’s ability to support Pix payments in Brazil and installment payments in Mexico.
- Work conducted at Amazon.com.