Payment Infrastructure for SaaS: Routing & Failover

Almost every confused payments project starts by treating these as one system. They are two, they fail differently, and vendors on both sides of the line are happy to let you assume otherwise.

A billing engine answers what does this customer owe? — plans and price books, metered usage, seats, proration when someone upgrades mid-cycle, invoices, dunning schedules, sales tax and VAT. When it breaks you invoice the wrong amount.

Payment infrastructure answers how do we actually collect it, and how do we know we did? — which provider takes this payment, what happens when that provider is unavailable, how a retry avoids charging twice, how the result is verified, and how five providers become one set of numbers. When it breaks you lose the sale, or take it twice, or ship something nobody paid for.

Knowing which of the two is hurting is most of the diagnosis. If your revenue numbers are wrong, look at billing. If money is arriving late, twice, or not at all, look here.

A single-provider integration has no routing decision to make, and for one country in one currency that is a feature. It stops being one the moment your customers are somewhere your provider is weak — a currency it will not settle, a method it does not offer, an acquirer with no local presence and therefore a worse approval rate on exactly the cards you want to accept.

The mistake is treating that as a provider-selection problem and re-running the evaluation. It is a structural problem: any single provider is the wrong answer somewhere. Routing turns "which provider" from a decision baked into your checkout into a rule you can change, which is what makes accepting payments across several markets a configuration exercise instead of a rebuild per country.

These are usually planned as separate tickets and that is the error. Failover without idempotency is not a safety feature — it is an automated way to charge customers twice, because the failure it most often reacts to is a timeout, and a timeout means you do not know whether the first charge succeeded.

The requirement that falls out of that: the identity of a payment attempt has to live above the providers, not inside one of them, because a provider's own idempotency key is meaningless to the next provider. This is the single most common gap in a home-built payment layer, and it is unpacked properly in how payment failover is actually built.

First, never mark an order paid because a browser arrived at your success URL. That redirect is attacker-controllable and it is also just unreliable — customers close tabs. The payment is real when your server asks the provider and the provider confirms the capture, which is why orders get stuck between paid and pending in systems that trust the redirect.

Second, verify every webhook signature. Each provider signs differently — an HMAC digest in a header here, a form-encoded signature plus a source-IP check there — and an unverified callback endpoint is an open invitation to forge a "payment succeeded" event and take goods without paying. Implemented once centrally this is a solved problem; implemented per provider by whoever added that provider, it is a lottery. The mechanics are in webhooks for payment events.

Most SaaS products do not have a fraud problem until they have a signup form and a $1 plan, and then they have one immediately. The traffic is not trying to buy your product — it is validating stolen cards against anything that will take a small charge, which leaves you with the declines, the fees and eventually the account review. What stops it is dull and effective: limits on attempts per customer per window, limits on distinct cards, and a rule that reacts to repeated provider rejections rather than waiting for a human. Card testing on signup forms covers what the pattern looks like and which controls actually bite.

Building this is entirely possible and teams do it well. What they underestimate is the ratio: routing, the interesting part, is perhaps a fifth of the work. The rest is idempotency, per-provider error classification, a signature scheme for each provider, state machines that agree with each other, reconciliation, and then maintaining all of it as every provider changes their API on their own schedule.

The honest test is not technical. Build it when your routing logic is genuinely unusual, or when payments are the product. Buy it when payments are critical to the business but are not the business — the comparison in orchestration versus a single gateway is the same decision framed by cost rather than by capability, and the limits of a single payment processor covers what you are carrying while you decide.

One trend raises the stakes on all of it. Software that pays on a user's behalf retries instantly and identically rather than hesitating the way a person does, which turns a tolerable weakness in a payment layer into a visible one — the risks of letting AI agents make payments.

PaymentHood is the payments half of the boundary above, delivered as one integration. Your product talks to one API — or a free plugin if you are on WooCommerce, WHMCS or Joomla — and 30+ providers sit behind it, with routing, failover, idempotency, webhook verification and reconciliation handled once rather than once per provider. Every provider account stays contracted in your own name and funds settle directly to you; PaymentHood is not a processor, an acquirer or a merchant of record, and takes no percentage and no per-transaction fee at any volume.

What it does not do is the other half. No metering, no plans, no proration, no invoices, no dunning, no tax. Keep your billing engine. This layer goes underneath it.