Industries
A subscription platform, a marketplace and a hotel group describe their payment needs in completely different language. Underneath, they are asking for the same four things: don't hold the card, don't rewrite the integration per processor, don't lose the money's trail, and don't go down.
State of the work
Before the vertical detail, this is the common ground the platform is built on.
Systems hold a token and masked metadata. The account data lives in one isolated environment.
Processors sit behind a single contract, so the second one is configuration rather than a rewrite.
Accepted, authorised, captured and settled are distinct states, because collapsing them is what breaks the books.
Idempotency, replay resistance and health-aware routing, so a timeout is not a double charge.
Listed as peers. None of these is a pilot customer or a special case — the infrastructure underneath is the same.
Subscription revenue, seat changes, trials, upgrades and dunning — with one integration rather than one per processor.
What it asks of the platform
Payments on behalf of many sellers, with the routing and reconciliation that implies.
What it asks of the platform
Authorisation rates, cost of acceptance and checkout reliability, treated as things to measure rather than accept.
What it asks of the platform
Guarantees taken well before service, charged long after — deposits, no-shows, late cancellations and post-stay balances.
What it asks of the platform
High volume, low ticket, and unforgiving of per-transaction overhead.
What it asks of the platform
Revenue that depends on a card still working twelve months after anyone last thought about it.
What it asks of the platform
Invoicing, milestones and terms, where the payment is the end of a process rather than a checkout.
What it asks of the platform
Companies that need to offer payments inside their own product without building a payment security stack.
What it asks of the platform
The same path regardless of industry: the credential is vaulted before it reaches the calling system, which works by reference from then on.
Customer
Checkout, invoice or booking
Mirage Gateway
Vaults the credential, issues a token
Your platform
Token, status and permitted metadata
Processor
Authorise, capture, refund
Diagram · Intended architecture. No production processor integration exists today.
Travel and hospitality is worth spelling out, because it is the case where the gap between taking a guarantee and charging it is widest — and where reading a card off a screen is still normal practice.
A reservation carries a payment guarantee taken weeks before arrival. The property legitimately needs to act on it later — a deposit, a no-show charge, a late cancellation, a refund after departure. The common approach is to show a staff member the card number on a screen, which places the front desk, the browser and the property system inside the payment security perimeter.
The alternative is that the credential is vaulted on arrival into the system, and the property works with a reference: brand, last four, guarantee state, whether it is a virtual card, and the actions permitted to that user at that location. The charge happens by token, with an audit record naming who authorised it.
The same pattern — vault first, act by reference, keep an attributable trail — is what a marketplace, a telecom platform or a subscription business needs. The vocabulary changes; the architecture does not.