The vault
Card numbers reach the vault over TLS, are stored under KMS data keys in a separate database, and never leave the vault in the clear. Every card gets a Tranzify token; where an acquirer issues its own token, it is stored next to it, so recurring payments can be routed to any acquirer that knows the card. The vault keeps the expiry date, the masked number, the scheme and the issuer’s country and nothing that a thief could use.
Processing
- Deposits by card with 3-D Secure where the issuer asks, through the provider’s page or server-to-server.
- Recurring and merchant-initiated payments without a CVV, with the provider’s token and the scheme’s rules.
- Google Pay and Apple Pay as card payments with the wallets’ tokens.
- Payouts to cards where the acquirer supports them, with the vault’s token or a card entered once for the payout.
- BIN data — scheme, issuer country, card level and type — available to routing rules and to the merchant’s own risk checks.
- Refunds, partial and full, to the original card, with the acquirer’s answer in the journal.
A card’s life on the platform
| Event | What the vault does |
|---|---|
| First payment | Receives the number from the checkout, stores it under a data key, issues a Tranzify token, keeps the acquirer’s token if it returned one |
| Recurring charge | Finds the acquirer’s token for the terminal the routing chose; if that acquirer has none, sends the card to it once and stores its token for next time |
| Decline at one acquirer | The cascade tries the next terminal with the same card; the issuer’s reason code is in the journal |
| Expiry | An hourly check marks the card expired and notifies the merchant |
| Payer’s request | The merchant deletes the token; the vault removes the card and its tokens |
| Audit | Every use of a token, every encryption and decryption, is journaled for five years without the number itself |
Why it matters to a payment business
Acquirers decline for their own reasons: a BIN range, a country, a risk score. A platform that holds the card once and knows every acquirer’s token can try the next one in the same second instead of asking the payer again. A subscription business keeps its renewals when it changes acquirer, because the tokens move with the platform, not with the acquirer. A PSP that adds a local acquirer for one country routes the cards of that country to it the same day, with the stored cards following.
Scope and compliance
The vault and the checkout are built to the requirements of PCI DSS for service providers: transport over TLS, keys in a managed service, the number never logged and masked everywhere, access by roles with two-factor authentication, an audit log. A merchant on the hosted checkout stays in the lightest PCI scope, because the card number never reaches its systems; a merchant with its own page uses the API server-to-server under its own scope. The compliance documents are shared at contract stage; the security page describes the rest of the platform.