Payment Gateway

Payment acceptance, routing & orchestration

A region-aware orchestration gateway written in Rust. One API and one checkout route each transaction to the processor most likely to approve it, by region, currency and method. Underneath sit the parts teams usually bolt on later: lifecycle, double-entry ledger, risk, disputes, durable state and webhooks you can trust.

Open live demo Book a consultation

What it covers

Multi-PSP routingregion · currency · method · failover
Token vaultKMS envelope · SAQ A
Double-entry ledgerprovable books
3-D Secure 2 · SCAliability shift
Fees enginecustom fee logic
One API · checkout SDKintegrate once

Problem vs solution

The happy path is quick. The calendar goes to everything around it.

How this normally goes
Idempotency under retry storms, reconciliation when the processor file and the bank statement disagree, disputes, partial captures, and the PCI audit that arrives after the architecture is fixed.
Why the usual escapes cost you
A hosted gateway takes a cut for as long as you take payments and decides which markets you can enter. A single PSP leaves no fallback at 2am on a Friday.
What we deploy instead
A production gateway you own, adapted rather than rebuilt. The domain core has no infrastructure dependencies, and every processor and rail sits behind a port, so adding an acquirer changes an adapter and not your checkout.

Presales and Discovery

Before implementation, our architects run a scoped engagement. You keep the artefacts whatever you decide next.

Book an architecture session

System Design
Target architecture against your systems, with failure domains and the order things get built.
Integration contracts
Every touchpoint with your core, ledger, PSPs and fraud stack, written as API contracts before an implementation exists.
PCI scope assessment
Which systems fall in scope under each design option, and what tokenize-first removes. Normally discovered late and expensively.
Cloud cost model
What the platform costs to run at your volume, by component, so the business case rests on numbers.
Migration plan
Parallel run, reconciliation between old and new, gradual traffic shift, with a rollback point at each step.

Under the hood

The same system the six parts below describe, drawn once. Card data crosses one boundary and everything after it moves on tokens.

Payment gateway architecture — Checkout SDK and REST API in front, processor adapters one per provider, the token vault as the only place a PAN exists, and a webhook dispatcher on the way out.

Routing

Multi-region orchestration

Routes by geography, currency and method across four acquiring regions, with circuit breakers and automatic cascade when a processor degrades.

CDE

Tokenization vault

The only place a PAN exists, held as KMS envelope ciphertext. Everything downstream moves on opaque tokens.

Money

Double-entry, event-sourced ledger

A balance is the replay of its history rather than a number someone overwrote, so a trial balance proves the books.

Correctness

Idempotency and concurrency control

Atomic idempotency and optimistic-concurrency CAS stop double-charge, double-spend and lost updates under real retry behaviour.

Auth

3-D Secure 2 and SCA

Behind a PSD2 exemption engine, so friction is applied only where the rules require it and liability shifts where they allow.

Events

Webhooks you can build on

Signed, ordered and replay-safe across authorization, capture, refund, dispute and settlement.

Level of customization

A white-label foundation, not a product with a settings screen.

Yours to change
Routing rules, fee logic, the checkout surface, data model extensions, and which processors exist at all.
What we keep stable
Idempotency, the ledger invariants and the tokenization boundary. A platform that lets you switch those off will eventually double-charge someone.
How it ships
Your cloud, your repositories, your operational control, with the architects who designed it available to extend it.

99.99%

Uptime SLA

Active-active across regions, zero-downtime deploys.

<150ms

p99 auth latency

Measured on the authorization hot path.

40+

Acquirer & method rails

One integration reaches every rail and region.

SAQ A

PCI scope you inherit

Raw card data never touches your servers.

The PCI boundary, and what it costs you

Inheriting SAQ A is the point of a tokenized boundary, but only if nothing behind it quietly reads a card number. That is an engineering question, and it is the one that decides the size of your assessment.

PCI DSS readiness

Where the scope actually is
A debug field, a retained log line or a legacy batch job puts a system back in scope no matter what the checkout does. Found in code and traffic, not in a workshop.
Evidence, once rather than annually
Configuration snapshots, access reviews and key rotation records collected on a schedule, so the second assessment reuses the first instead of starting over.

ROI and economics

We will not quote a saving in months we have not measured on your estate. We can be precise about where the time and the money go.

What you do not build
Vault, ledger, orchestration, the idempotency model, webhook guarantees, disputes, settlement, and the PCI boundary that makes the rest defensible. Each is quick to prototype and long to harden, and hardening is the cost.
Where the calendar goes
Not the first successful payment, which any competent team reaches quickly, but the second year of edge cases. You start past them.
The recurring line
A hosted gateway is a percentage of revenue for as long as you take payments. Self-hosting turns that into cost that falls per transaction as you grow, and we model the crossover with you in Discovery.
Market expansion
Adding a processor or a region is an adapter behind an existing port, which is the difference between entering a market in weeks and re-planning a platform.

Where this fits

A good fit
Volume across more than one region, a hosted gateway you have outgrown, PCI scope that is an architectural decision rather than a checkbox, and a team that will own this after handover.
Not a fit
Payments live next month with no engineering capacity of your own, or volumes where a gateway percentage is genuinely cheaper than running infrastructure. We say so in Discovery, not after.

How the gateway works

The questions teams ask before they build on it.

What exactly is it?

A self-hosted, region-aware orchestration gateway written in Rust. One API and one checkout route each transaction to the right processor, on top of a token vault, a double-entry ledger and durable state you own.

How is it different from a hosted gateway?

You run it. No per-transaction margin bleed, no lock-in, and full control over routing, data and PCI scope, while staying SAQ A by default through tokenization.

What happens when a processor goes down?

Circuit breakers and geo-aware fallback cascade the transaction to the next processor automatically, so approvals hold instead of failing at 2am.

Can we self-host it?

Yes. It runs in your own cloud on Docker with Rust, Axum and PostgreSQL, with a per-transaction audit trail and signed, idempotent webhooks for every money event.

Seen in the field

Client work where Payment Gateway did the heavy lifting.

Case

PSP-independent payment layer for a subscription platform

UK meal-kit subscription platform

A UK meal-kit subscription platform now owns a payment orchestration layer that treats every PSP as a plug-in behind one internal contract. We built that layer while moving millions of live subscriptions to a new provider with zero downtime.