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 capabilities
Planned to work as one platform, not a bundle of tools
- Vault & Tokenization
- Planned. Isolates payment account data so applications hold a token and masked metadata rather than a card number.
- Payment Gateway APIs
- Planned. Authorize, capture, partial capture, void and refund, normalized across processors with idempotency on every mutation.
- Processor Orchestration
- Planned. Processor abstraction with configurable routing, health-aware failover and normalized reconciliation evidence.
- Billing Infrastructure
- Planned. Subscriptions, usage-based billing, invoicing and recurring payment logic on the same primitives.
- Developer & Merchant Connect
- Planned. APIs, signed webhooks, sandbox and merchant integrations. No endpoint is callable and no sandbox is open.
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.