Mirage Gateway
Payment Infrastructure
Mirage Gateway is a payment infrastructure platform in development: tokenization and vaulting, gateway APIs, processor orchestration and billing, designed so that ordinary applications hold tokens instead of card data.
The problem
Once a card number is copied into an application database, a log line, a support tool and a backup, every one of those becomes something that has to be protected, assessed and defended.
- Payment credentials spreading through systems that never needed them
- Each processor integration rewritten from scratch, with its own state machine
- Provider acceptance mistaken for settlement, so the books balance until the money does not arrive
- Security scope growing quietly with every system that touches a card
The product vision
Keep payment data inside one small, isolated environment and give everything else a token.
- A vault and tokenization layer, so applications hold references rather than card numbers
- One normalized payment API instead of one integration per processor
- Routing and failover expressed as policy rather than as branching in a checkout
- Reconciliation that distinguishes accepted from settled
Intended architecture
Intended architecture — no component of this is in production
- 01
Sources
Merchant checkouts, marketplaces, invoices and booking flows
- 02
Isolated environment
Payment data is vaulted under hardware-backed key control
- 03
Token
Applications receive a reference, brand, last four and status
- 04
Processor
Authorize, capture, refund by reference only
Planned modules
Six modules, one integration — all in preparation
Mirage Gateway is payment infrastructure in active development: the systems around a payment hold a token, never a card number. It is not yet available to merchants, and every module below is planned work.
Vault & tokenisation
In preparationPayment-account data isolated in one small environment, so ordinary applications hold a token and masked metadata instead of a card number.
- Tokens in place of card numbers
- Account data kept inside one isolated boundary
Gateway API
In preparationA normalised API for payment operations, so an integration is written once rather than once per processor.
- One contract for payment operations
- Distinct accepted, authorised, captured and settled states
Orchestration
In preparationProcessor, acquirer and payment-method abstraction, with routing and failover expressed as policy.
- Routing and failover as policy
- A second processor as configuration, not a rewrite
Billing
In preparationSubscriptions, usage-based billing, invoicing and recurring payments on the same primitives.
- Subscriptions and usage billing
- Invoicing and recurring payments
Connect
In preparationThe developer and merchant integration layer: APIs, webhooks, SDKs and processor connections.
- APIs and webhooks
- SDKs and processor connections
Wallet
Future — regulatory gateOrganisation-level balances, credits and prepaid funds, held behind a regulatory gate: stored value changes what a business is, not only what it does.
- Balances and credits
- Only after the regulatory question is settled
Questions
Mirage Gateway — frequently asked questions
Can merchants use Mirage Gateway today?
No. Mirage Gateway is in active development and not yet available to merchants.
What problem does it solve?
Card data spreads into application databases, logs, support tools and backups, and each copy has to be protected. Mirage Gateway is designed so applications hold a token and card data stays in one isolated environment.
Who is it being built for?
SaaS platforms, marketplaces, e-commerce, travel and hospitality, telecom, subscription businesses and the software vendors serving them.
Technology direction
Planned to be engineered on the Mirage technology stack
- Cardholder data environment minimization as the governing design constraint
- Independent identifiers for merchants, customers, payments and tokens — never a processor's own
- Idempotency and replay resistance on every payment mutation
- Event model that separates provider acceptance from settlement
- Independently deployable, with no dependency on another product's database
Security by design
Security is being designed in, not added later
Intended use cases
Where Mirage Gateway is intended to operate
SaaS & Subscription Platforms
Recurring billing, card-on-file renewals and failed-payment recovery, with one integration rather than one per processor.
Marketplaces & E-commerce
Payments on behalf of many sellers, routing on approval rate and cost, and reconciliation attributable to each party.
Travel & Hospitality
Guarantees taken well before service and charged long after — deposits, no-shows and post-stay balances, handled by token rather than by reading a card number.
Telecom & Digital Services
High volume and low ticket, where per-transaction overhead and retry logic decide the margin.
Software Vendors
Companies that need to offer payments inside their own product without building a payment security stack.
Mirage Gateway is in development.
Talk to the enterprise team about the roadmap and early access.