Selling Where Stripe Does Not Reach: Building a Billing Engine Across 15+ Payment Gateways

A business selling subscriptions internationally quickly finds that a single payment provider does not cover every customer. Some markets rely on regional gateways and local payment methods that the best-known Western providers do not support. For a subscription and membership commerce engine, the answer was to support more than fifteen global and regional payment gateways, spanning North America, the Middle East and North Africa, and South and Southeast Asia.

This post covers what that kind of engine involves and the design principles that keep it manageable.

Why one gateway was not enough

The business needed to sell to customers in markets that Western payment providers do not reach well. In those markets, a checkout that only offers card payments through one international provider loses customers at the last step, because the payment methods they actually use are missing.

Supporting regional gateways alongside global ones (the engine includes Stripe, PayPal and Razorpay among its fifteen-plus integrations) lets each customer pay in a way that is normal where they live.

What the engine covers

• Package and plan billing for subscriptions and memberships.
• A catalog of packages, memberships and item variations.
• Automated invoice PDF generation, using DomPDF.
• Admin-configurable CMS content alongside billing, so the business manages its offer and its pages in one place.

It is built on Laravel.

Principles that make many gateways manageable

Adding the second gateway is where most payment code starts to go wrong. These are the principles that keep multi-gateway billing manageable, so that the fifteenth gateway is no harder than the second.

One internal payment interface

The rest of the application should never talk to a gateway directly. It talks to one internal interface, "charge this", "start this subscription", "refund this", and each gateway is an adapter behind it. Adding a gateway means writing an adapter, not touching checkout, subscriptions or reporting.

One set of payment states

Every gateway describes payments differently. Internally, there should be one vocabulary for the state of a payment or subscription, with each adapter translating the gateway's terms into it. Reporting, access control and customer emails then work the same way whichever gateway was used.

Treat asynchronous notifications carefully

Many gateways confirm payments through asynchronous notifications such as webhooks, sometimes more than once. Those notifications should be verified as genuinely coming from the gateway, and processing them twice should never charge or extend a subscription twice.

The catalog belongs to the business

Packages, memberships and variations should be modelled on the business's own terms, then mapped to each gateway as needed. If the catalog is shaped around one provider's product model, every other gateway becomes an awkward fit.

Invoices from your own records

Invoices are generated automatically as PDFs from the engine's own records. That means every customer receives the same kind of invoice regardless of the gateway that took the payment, and the business has one consistent set of billing documents instead of fifteen different formats.

When to add regional gateways

Supporting many gateways adds testing, maintenance and reconciliation work, so it is worth doing deliberately:

• Add a gateway when you have or expect customers in a market it serves.
• Check which payment methods customers in that market actually use.
• Confirm settlement currencies and payout timelines before launch.
• Test the full lifecycle: payment, renewal, failure, refund.

A checklist for international subscription billing

• Map your target markets to the payment methods people use there.
• Put every gateway behind one internal payment interface.
• Translate gateway statuses into one internal set of states.
• Verify webhooks and make processing safe to repeat.
• Keep the catalog in your own model, not a provider's.
• Generate invoices from your own records.

The anonymised write-up is in our work library. Adding payment methods and markets to an existing product is typical of our product improvement service. If your product is a marketplace, see how we approach the rest of the foundation in building the account foundation first.