Platform
Mirage Gateway is designed as composable payment infrastructure rather than one monolithic service. Each module has a boundary, a contract and a reason to exist independently — which is also what makes it possible to keep the part that touches card data small.
State of the work
Payment data enters one isolated environment and does not leave it. Everything downstream operates on tokens, states and accounting events.
Card data enters here
Isolated payment environment
planned scopeVault
Holds the account data
Key management
Hardware-backed, separated duties
Everything inside this line is designed to be as small as it can be. Every system added to it has to be assessed, monitored and defended.
What everything else receives
Never a card number, never a security code.
Diagram · Intended architecture. Every element shown is in design; none is deployed.
Five are engineering work with a planned sequence. Wallet is not, and is drawn apart from the others for that reason.
Secure payment-account vaulting and tokenisation. Isolates cardholder data so ordinary applications hold a token and masked metadata instead of a card number.
More on Vault →Intended capabilities
A normalised API for payment operations, so that an integration is written once rather than once per processor.
More on Gateway →Intended capabilities
Processor, acquirer and payment-method abstraction, with routing and failover expressed as policy rather than as branching in each caller.
More on Orchestrate →Intended capabilities
Subscriptions, usage-based billing, invoicing and recurring-payment logic built on the same payment primitives.
Intended capabilities
The developer and merchant integration layer: APIs, webhooks, SDKs and processor connections.
More on Connect →Intended capabilities
Organisation-level balances, credits and prepaid funds. Held behind a regulatory gate — stored value changes what the business is, not just what it does.
What it would require first
Mirage Gateway is a peer product in the Mirage ecosystem, not a component of any other product. That has concrete consequences.
Mirage Gateway does not read another product's tables, and no other product reads its own. Integration happens through explicit contracts, so that a schema change in one system is not an outage in another.
A processor's identifier is never the internal identity of a merchant, customer, payment or token. External references are mapped explicitly, which is what makes it possible to change processor without rewriting history.
The service can be deployed, rolled back or removed without disturbing any other Mirage service — and the same is true in reverse.
No card number in the event bus, in analytics, in logs, in a support tool, or in any product database. This is a boundary the architecture enforces rather than a habit the team maintains.