mTokens sits between your checkout and your gateway. We take the card number, hand you back a token, and route the charge to whichever processor you're using today — Stripe, NMI, Authorize.net, or the next one you switch to.
The card only ever gets typed once. Everything after that is a token changing hands.
Your checkout form sends the card straight to mTokens — hosted fields or a direct API call. It never touches your app servers.
We encrypt the PAN inside a PCI Level 1 environment and hand back an opaque token tied to that customer.
From now on you submit the token, not the card. mTokens decrypts it and forwards the charge to whichever gateway is live.
Click a step, or let it play — this is the exact cycle above, running.
At checkout, the card goes straight to mTokens — hosted fields or a direct API call. It never touches the merchant's own servers.
The PAN is encrypted inside a PCI DSS Level 1 vault. What comes back is a random, opaque token — useless to anyone who doesn't hold the vault's key.
From now on, every charge — this one and every renewal after it — sends the token, never the card number.
mTokens decrypts the token back into a real card number internally, and forwards the charge to whichever gateway is active — without the merchant ever seeing the PAN again.
An approval comes back through mTokens to the merchant. Next time this customer buys something, the cycle starts again at step 3 — the card is never re-entered.
Tokenize inside Stripe or NMI and the token is theirs — leave, and every stored card leaves with them. Tokenize with mTokens and the card on file outlives the processor.
The highest tier of card-data compliance, audited annually — so your own PCI scope shrinks to almost nothing.
Stripe, NMI, Authorize.net, Square and more, behind one token format. Swap the destination without touching checkout code.
Change processors mid-quarter and existing subscriptions keep billing on the same token, uninterrupted.
A small, deliberate API surface: create a token, charge a token, retire a token. Nothing to reverse-engineer.
Every tokenization and detokenization is logged with actor, gateway, and timestamp for your compliance record.
Prebuilt, PCI-scoped card fields for web and mobile checkout, or call the API directly from your own form.
ISOs, PSPs, and platforms can resell mTokens under their own domain — your merchants never see our name. You onboard them, we run the vault, you keep the relationship.
A token is a random, opaque identifier — tok_9f3a7c… — that stands in for a card number. It's meaningless outside mTokens: even if it leaked, it can't be charged anywhere else.
Nothing happens to them. The token stays the same; you change which gateway it decrypts to inside the merchant portal. Existing subscriptions keep billing without re-authorization.
Yes — mTokens operates as a PCI DSS Level 1 service provider, the same tier required of the largest processors. Routing full PAN capture through us removes most of your own PCI scope.
Yes. Tokens are built to be charged repeatedly — subscriptions, installments, and saved cards for one-click checkout all work the same way: submit the token, we handle the rest.
Most merchants are live within a day: point checkout at our hosted fields or API, store the token you get back, and submit that token on future charges instead of a card number.
Tell us which gateway you're on today — we'll have sandbox keys back to you the same day.