A finance team exports a "customers" table for a churn analysis. One column still holds full card numbers from an old billing integration, and by lunch the file sits in three inboxes and a shared drive.
Card data spreads like this in many businesses, into CRM notes, call recordings, tickets and exports. Holding cards puts your whole stack in scope: every server the data touches, every database it lands in and every backup it survives in.
Card vault tokenization changes where the card number lives. In this guide, we cover how it works, how the architectures compare, how far it cuts PCI scope and how to choose a provider.
What is card vault tokenization?
Card vault tokenization is a payment security method that swaps a card's PAN for a random token and stores the real number in a separate, encrypted vault that only authorized services can reach.
Your systems keep the token, and the vault keeps the card. When a payment needs the real number, the vault supplies it inside its own environment.
What is a card vault?
A card vault is a hardened store built to hold card numbers and release them only under strict rules. What sets it apart from an encrypted database column:
- Isolation: it runs as a separate service, apart from your application.
- Key management: keys sit apart from the data, often per customer and backed by hardware security modules (HSMs).
- Access policy: only named services, with scoped credentials, can request a card.
- Audit: every tokenize, detokenize and forward request is logged.
What does a card token look like? Formats and types explained
The right format depends on what your existing systems expect.
| Format | Example (test values) | When to use it |
|---|---|---|
| Original PAN | 4111 1111 1111 1111 | Never stored in your systems |
| Random token | tok_8fK2mQ9xZrT4vB | New systems |
| Format-preserving token | 4111 1187 4420 1111 | Legacy fields that expect 16 digits |
| Luhn-passable token | Passes the card checksum | Code that validates card numbers |
| Deterministic token | Same card, same token | Matching and card-on-file logic |
Format-preserving tokens often keep the first six and last four digits, so staff still see the brand and "ending in 1111". The vault also returns safe display metadata: brand, last four and expiry.
Why is a stolen card token useless to attackers?
A random token has no mathematical relationship to the card number, and no key converts it back. Three more barriers block a charge:
- The vault is the only way back: Detokenizing needs authenticated vault access.
- Credentials are scoped: A client can use only the actions it was granted.
- Destinations are allowlisted: Card data goes only to approved gateway domains.
The vault itself becomes the target, so your provider's isolation and key handling matter as much as the token.
What is detokenization?
Detokenization is the reverse step: the vault retrieves the real card number for an approved purpose.
In a well-designed setup, detokenization rarely returns the PAN to you. The vault inserts the card into an outbound gateway request, and you receive only the response. When a person must see the card, it happens in a controlled, logged session.
Why businesses are moving card data into a token vault
Businesses move card data into a token vault because stored card numbers spread across apps, inboxes and recordings, and every system that touches them adds breach exposure and PCI audit work.
Why stored card numbers are a breach and audit liability
PCI DSS applies to every system that stores, processes or transmits card data, plus connected systems. Store a PAN in your billing database, and its backups, admin tools and network all join your cardholder data environment (CDE). What that means in practice:
- Each in-scope system needs yearly PCI controls, evidence and testing.
- A breach of any one exposes usable card numbers.
- Backups and exports outlive the original record.
Why remote card collection (phone, email, links) makes it worse
Card-not-present collection multiplies where numbers land.
| Channel | Where the card number ends up |
|---|---|
| Phone | Agent notes, call recordings, transcripts, screen recordings |
| Inboxes, forwards, archives, mobile devices | |
| Chat | Chat history, support tools, exported logs |
| Generic web forms | Form vendor storage, notification emails, spreadsheets |
Each copy sits outside your payment controls, often for years.
Why card-on-file workflows need a safer storage model
Subscriptions, deposits, balances and no-show fees all need the card again later, which without a vault means keeping it somewhere.
A token gives you reuse without custody: it sits on the customer record while the card stays in the vault.
Card vault tokenization vs encryption: what's the difference?
Encryption scrambles the card number with a key and stores the result in your systems, whereas vault tokenization removes the number entirely and leaves only a token with no mathematical link to it.
| Factor | Encryption | Vault tokenization |
|---|---|---|
| What you store | Ciphertext of the PAN | A token |
| Reversible by | Anyone with the key | Only the vault, through an authorized request |
| Where the PAN lives | Inside your systems, encrypted | Inside the vault, outside your systems |
| PCI treatment | Encrypted PAN is still cardholder data | Tokens that cannot recover the PAN are generally not |
| Main risk | Key theft exposes every record | Vault compromise, so provider security matters |
| Best fit | Data in transit and at rest | Card numbers you must reuse |
The practical difference: encrypted PANs keep your databases in PCI scope, while tokens can take them out. Most vaults use both: encryption inside, tokens outside.
How card vault tokenization works: a 7-step payment flow
Card vault tokenization works by capturing the card outside your servers, encrypting it in a vault, returning a token you store, then injecting the card into gateway requests when a charge is due.
Let's follow a subscription software company that charges a customer's card monthly.
Step 1: Capture the card without touching your servers
The customer types the card into a hosted or embedded form, often an iframe, which posts it straight to the vault. Other capture options:
- IVR phone payments, with keyed digits going directly to the vault.
- A direct API call for server-to-server flows.
E-commerce example: a WooCommerce or Magento store embeds the vault's form in its checkout and receives only a token.
Step 2: Encrypt and store the PAN in an isolated vault
The vault encrypts the card with AES-256 or similar, ideally with per-customer keys, in an environment isolated from other tenants and your application.
Why per-customer keys matter: one compromised key leaves every other tenant's cards protected.
Step 3: Return a token and store it against your records
The vault returns a token and safe metadata. The company saves the token against the customer's account, with a record of consent to future charges.
| Where it lives | What it holds |
|---|---|
| Your application and CRM | Token, brand, last four, expiry, consent record |
| The vault | Encrypted PAN, mapped to the token |
| Your logs | Request IDs and tokens, never the PAN |
Step 4: Handle CVV separately and temporarily
PCI DSS prohibits storing the CVV after authorization, even encrypted. A good vault holds it encrypted just long enough for the first authorization, then deletes it.
Later card-on-file charges run without CVV, as is normal for merchant-initiated transactions.
Step 5: Send a tokenized charge request to the proxy
On billing day, the company builds a normal gateway charge request with a placeholder where the card number would go, and sends it to the vault's payment proxy. The proxy checks three things first:
- Scoped OAuth2 credentials on the caller.
- A valid request signature.
- An allowlisted gateway domain as the destination.
Step 6: Inject the card number and forward it to the gateway
Inside the vault, the proxy swaps in the real card number and forwards the request to Stripe, Authorize.net, Braintree, PayPal or another gateway. The gateway's response returns through the proxy, without the card number in it.
Step 7: Log every access and enforce retention rules
Every tokenize, forward and retrieval request is logged with who made it and the result. Retention rules to set:
- Delete cards when customers cancel or request it.
- Purge expired cards on a schedule.
- Document legal hold exceptions.
What are the core architectures for card tokenization?
The core architectures for card tokenization are vault-based lookup, vaultless cryptographic tokens, network tokens issued by card brands and gateway tokens held by your payment processor.
Each answers one question differently: where does the token-to-card link live?
Vault-based tokenization: how the lookup model works
A vault stores each PAN encrypted with a token-to-PAN mapping table, so detokenizing is a secure lookup.
Strengths: random tokens cannot be reversed, and the vault can forward cards to any gateway.
Trade-offs: the vault must be secured and scaled, and each lookup adds a small step.
Vaultless tokenization: how FPE and HSM keys replace the vault
Vaultless systems skip the mapping table and generate tokens with format-preserving encryption (FPE), such as NIST-approved FF1, using HSM-held keys.
- No database of PANs to protect.
- Fast, because tokens are computed rather than looked up.
- Key compromise is the central risk, since the keys can reverse every token.
- Cards needed later by a person still get decrypted somewhere.
Network tokenization: how Visa and Mastercard tokens work
Card networks issue tokens through Visa Token Service and Mastercard Digital Enablement Service (MDES). Each is bound to a merchant or device, and each transaction carries a one-time cryptogram. What they add:
- Lifecycle updates: when a bank reissues a card, the network token keeps working.
- Higher trust: issuers see a cryptogram-backed charge from a known merchant.
- Domain controls: a token bound to one merchant fails anywhere else.
Network tokens are requested through a token requestor, usually your gateway or vault provider.
PSP gateway tokens: how processor-held tokens work
Save a card with a payment service provider (PSP), and it returns a token that works only with that PSP.
It is the simplest start, with no extra vendor. The catch is portability: a second or new processor means a card migration.
Vault vs vaultless vs network tokens: architecture comparison
Vault tokens stay portable across gateways and allow controlled retrieval, whereas vaultless tokens swap stored cards for key risk and network tokens add automatic card updates on brand rails.
| Factor | Vault-based | Vaultless | Network tokens | PSP tokens |
|---|---|---|---|---|
| Where the PAN lives | Encrypted in the vault | Nowhere, derived from keys | With the card network | With the processor |
| Token mapping | Lookup table | FPE with HSM keys | Network token service | Processor database |
| Gateway portability | Any gateway the vault can forward to | Depends on implementation | Depends on the token requestor setup | One processor only |
| Card lifecycle updates | Needs account updater or network tokens | Same | Automatic | Processor dependent |
| Card retrieval for staff | Possible under strict controls | Possible with decryption | No | No |
| PCI scope effect | Strong for systems holding tokens | Strong, keys stay in scope | Strong for merchant systems | Strong, locked to one PSP |
| Best fit | Multi-gateway, card-on-file, human workflows | High-volume, low-latency internal systems | Recurring and stored-credential charges | Single-processor merchants |
Why vaults and network tokens work best together
Many enterprises run both. The vault holds the card and stays portable, while network tokens handle charges that benefit from lifecycle updates and cryptograms.
Example: a subscription company keeps cards in its vault and uses network tokens for recurring billing. If it adds a processor, the vault still holds the source card.
How far does card vault tokenization reduce PCI DSS scope?
Card vault tokenization reduces PCI DSS scope by taking card numbers out of systems that hold only tokens, such as apps and CRMs, while capture pages and connected systems stay in scope.
It reduces scope a lot without removing it, so be wary of anyone promising "no more PCI".
Which systems drop out of scope and which stay in
| Usually out of scope | Usually still in scope |
|---|---|
| CRM and customer records holding tokens | Web pages that load or host the payment form |
| Billing and booking databases | Any system that receives a detokenized PAN |
| Data warehouses and analytics | Staff workstations used for card retrieval |
| Support tools and ticketing | Your vault provider, through its own AOC |
PCI guidance treats tokens that cannot recover the PAN as outside cardholder data, while the tokenization system stays in scope. Tokens that can directly initiate charges, called high-value tokens, may get closer scrutiny, so confirm how yours are treated.
What determines your SAQ: SAQ A vs SAQ A-EP vs SAQ D
Your Self-Assessment Questionnaire (SAQ) depends mostly on how cards are captured.
| SAQ | Typical setup | Relative effort |
|---|---|---|
| SAQ A | Card-not-present merchant that fully outsources capture, such as a vault-hosted iframe or redirect, with no card data on its systems | Lightest |
| SAQ A-EP | E-commerce site that controls the payment page or scripts, even if the card goes straight to a third party | Moderate |
| SAQ D | Merchant that stores, processes or transmits card data itself | Heaviest |
A hosted capture form plus a vault can support SAQ A eligibility for many card-not-present businesses. Under PCI DSS v4.0.1, SAQ A merchants also confirm their site is protected against script attacks that could affect the payment page.
What pulls systems back into scope
Scope stays reduced only while card numbers stay out. Common leaks:
- Staff pasting card numbers into email, chat or CRM notes.
- Call recordings that capture spoken card numbers.
- Application logs that record raw request bodies.
- Screenshots and screen recordings during support sessions.
- A "temporary" export that becomes permanent.
Who confirms your scope: acquirer, QSA and your vault's AOC
Nobody can promise your SAQ in advance, including us. Three parties decide:
- Acquirer: sets which validation applies to your merchant level.
- QSA: if you use one, assesses your actual data flows.
- Vault provider: supplies its PCI DSS Attestation of Compliance (AOC), which covers its side.
What are the business benefits of card vault tokenization?
The business benefits of tokenizing cards in a vault are smaller breach impact, lighter PCI work, gateway freedom, safe card reuse, remote capture without custody and one shared security layer.
| Benefit | What changes |
|---|---|
| Smaller breach impact | Attackers find tokens in place of card numbers |
| Lighter PCI effort | Fewer systems to control, test and document |
| Gateway freedom | Tokens are not tied to one processor |
| Safe card reuse | Charge again without storing the PAN |
| Remote capture | Phone and link payments without agents handling cards |
| One security layer | The same vault model for cards, data and files |
Smaller breach impact: stolen tokens expose nothing
If an attacker reaches your CRM or billing database, they find tokens with no value outside your vault.
In an incident: you investigate token access, a far smaller problem than exposed cards.
Lighter PCI compliance effort and audit cost
Every system that leaves scope removes controls, evidence and tests. You feel it most at assessment time, when the in-scope list is shorter. Where the savings show up:
- Fewer systems to scan, test and harden.
- Less evidence per requirement.
- A smaller network segment to monitor.
Freedom to change or add payment gateways
An independent vault forwards cards to any supported gateway, so you can add a processor, route by region or renegotiate without re-collecting cards.
Example: a retailer adds a European processor, and stored cards work there from day one.
Reusing cards safely for repeat, recurring and card-on-file payments
Deterministic tokens map one card to one token, so every repeat charge references the same value and the card is entered once.
Where it shows up: travel balances, hotel incidentals, membership renewals and patient payment plans.
Taking cards by phone and payment link without holding them
IVR capture sends keypad digits straight to the vault, and a payment link does the same for customers who would otherwise email their card.
Result: call recordings, agent desktops and CRM notes stay free of card numbers.
One security layer across cards, data and files
The same vault model can protect SSNs, bank account numbers and documents, so security teams review one pattern.
Practical upside: one vendor review and one audit trail for every sensitive data type.
PSP tokens vs independent card vault: who controls your cards?
PSP tokens keep your stored cards inside one processor's system, whereas an independent card vault holds cards on your behalf and forwards them to whichever gateway you choose to charge through.
How PSP tokens lock cards to one processor
A processor holds the PAN and gives you its own token, which works until you want options. Where lock-in shows up:
- Adding a second processor means new tokens for new customers only.
- Switching processors needs a card data migration between providers.
- Routing by region, cost or approval rate is limited to one provider's network.
How an independent vault keeps tokens portable
An independent vault keeps the PAN and issues its own tokens. When you charge, its proxy forwards the card to the gateway you choose.
Switching or adding a gateway becomes a configuration change, while records, tokens and cards stay put.
When one processor is enough
One processor's tokens are usually enough when:
- Sales run through one checkout channel.
- Adding or switching processors is not on the roadmap.
- No person ever needs to use a stored card outside the gateway.
If any of those change, revisit the decision early.
When does an enterprise need an independent card vault?
An enterprise needs an independent card vault when it routes across several gateways, stores cards for later charges, collects cards remotely, lets staff use cards or is migrating processors.
| Situation | PSP tokens | Network tokens alone | Independent vault |
|---|---|---|---|
| Several gateways or regions | Weak fit | Partial | Strong fit |
| Card-on-file and deferred charges | Works with one PSP | Strong fit | Strong fit |
| Phone, agent or link capture | Depends on PSP | No | Strong fit |
| Staff need the real card | No | No | Possible with controls |
| Processor migration | Painful | Partial | Strong fit |
You route payments across multiple gateways or regions
Different acquirers by region, or a backup processor for outages, can all charge the same stored card.
Signal: your payments team talks about routing, failover or local acquiring.
You store cards for recurring, card-on-file or deferred charges
Balances, incidentals, renewals and installments charge after capture, and the vault holds the card until each amount is known.
You'll recognize it when: charges land weeks or months after capture.
You collect cards remotely through agents, phone or links
Call centers, reservation desks and field teams take cards off-site. IVR and link capture keep those cards away from agents.
Watch for: card numbers showing up in call recordings, emails or agent notes.
Staff or partners need controlled access to the real card
Some suppliers have no payment API, so a person must use the card. A vault can support controlled retrieval, which PSP and network tokens cannot.
Typical sign: staff re-type cards into supplier portals or read them out over the phone.
You are migrating processors or consolidating platforms
During a migration or merger, cards sit in several systems. One vault gives you a single, portable source before you switch.
Common trigger: a processor change, or two payment stacks merging after an acquisition.
How can staff use stored cards without exposing the full PAN?
Staff can use stored cards without exposing the PAN to your systems through controlled retrieval, where an authorized user views the card in a secure, logged session that skips your servers.
Travel agencies and other businesses paying suppliers for clients often ask us this.
Why some suppliers still need a human to enter the card
Many hotels, cruise lines and wholesalers have no payment API, so an agent types the card into a portal or reads it out by phone.
The goal is keeping that step without the card landing in your booking platform, CRM or email.
How controlled retrieval works
- Clients enter their card once through a vault-hosted form, and your system stores only the token.
- An authorized staff member signs in to a controlled agent application with SSO and MFA.
- Policy checks their role and permitted purpose before showing anything.
- The vault displays the card in that session, without it passing through your servers.
- Access is time-limited, and every view is logged with the user, time and token.
Where a supplier accepts API calls, proxy injection is safer, since no one sees the card.
What stays your responsibility
Controlled retrieval reduces exposure, while these obligations stay with you:
- Customer authorization: record what each client approved, for which supplier and until when.
- Supplier terms: some restrict third-party card use or require evidence.
- Staff rules: no card numbers in email, chat, notes or screenshots.
- PCI scope: retrieval workstations may stay in scope, so confirm with your QSA.
Which industries benefit most from card vault tokenization?
The industries that benefit most from card vault tokenization collect cards remotely or charge later, such as travel, hospitality, fintech, healthcare, insurance, legal, SaaS and contact centers.
| Industry | Common trigger | Vault pattern |
|---|---|---|
| Travel and hospitality | Cards arrive by phone and email, then go to suppliers | Hosted intake, token on booking, controlled retrieval |
| Financial services and fintech | Card data flows to issuers, processors and network APIs | Signed proxy requests to allowlisted partners |
| Healthcare and insurance | Patient balances and premiums on file | Card-on-file tokens apart from clinical records |
| Legal and professional services | Retainers and recurring fees | Payment link capture, token on the matter |
| SaaS and platforms | Merchants' customers share one database | Vault carries custody, platform stores tokens |
| Contact centers | Agents hear cards on calls | IVR capture through Twilio Pay straight to the vault |
Travel and hospitality
A travel agency books suppliers for clients who want to enter their card once:
- A branded, secure capture link goes to the client, who enters the card on a vault-hosted form.
- The vault returns a token and safe display details, stored against the client ID.
- Client authorization, permitted purposes and expiry are recorded separately.
- Integrated suppliers are charged through the gateway proxy, with no PAN in the agency's systems.
- For a supplier with no payment API, an authorized agent views the card in a controlled, logged session.
Hotels use the same pattern for deposits and third-party card authorizations.
Financial services and fintech
Card programs, payout platforms and lenders send card data to issuers, processors and network APIs. A signing proxy that forwards only to allowlisted domains keeps the PAN in the vault.
Example: a payout platform calling Mastercard APIs signs requests with OAuth 1.0a RSA-SHA256 inside the proxy, so its own services hold only tokens.
Healthcare and insurance
Patient payment plans and insurance premiums run on stored cards.
- Clinics and billing teams: store the token against the patient account and charge each installment on schedule.
- Insurers and agencies: keep the premium card as a token, apart from policy and claims systems.
Keep in mind: if the vault will also hold health data, ask whether the provider signs a Business Associate Agreement.
Legal and professional services
Law firms and accountants take retainers and recurring fees, often by phone or email.
Example: a firm sends a retainer payment link. The card goes to the vault, the token sits on the client matter, and later invoices are charged without asking again.
SaaS and platforms
Platforms offering payments to their merchants face a custody problem: one database, many merchants' customers.
| Without a vault | With a vault |
|---|---|
| The platform's codebase stores card numbers | The vault carries the custody |
| The whole platform sits in PCI scope | The codebase holds tokens and can stay out of scope, subject to assessment |
| Each new gateway means new card handling | The proxy forwards to the gateway each merchant uses |
Deterministic tokens also keep customer records coherent, since the same card always maps to the same token.
Contact centers and phone payments
Agents who hear card numbers on calls put audio, desktops and notes in scope.
Example: a billing call center moves to IVR capture through Twilio Pay. Callers key in the card, agents never hear or see a number, and the CRM shows only the token and card type.
What card vault tokenization solves and what it doesn't
Vault tokenization solves card custody, capture and reuse, and gives you charging without the PAN, whereas consent, fraud, processing fees and your remaining PCI duties stay with your business.
| What it solves | What it doesn't solve |
|---|---|
| Card numbers kept out of apps, CRMs, inboxes and recordings | Customer authorization for each use |
| Secure capture by form, phone or link | Fraud and chargebacks on card-not-present sales |
| Reusable tokens for repeat and recurring charges | Your acquirer relationship and processing fees |
| Charging through your gateway without seeing the PAN | Remaining PCI DSS duties and SAQ validation |
| Logged, controlled staff access | Supplier acceptance of third-party card use |
| Smaller PCI scope and a full audit trail | Weak practices such as shared logins |
What it solves
Capture, storage, reuse and charging all happen without your systems holding a PAN.
In short: the card number exists in one place, and every use of it is recorded.
What it doesn't solve (and what you still own)
Fraud: a vault does not authenticate the cardholder.
Fees: vault charges sit on top of your processing fees.
Compliance: you still validate PCI DSS for in-scope systems and own consent and retention.
Should you build a card vault in-house or use a provider?
Building a card vault in-house gives full control, whereas a provider gives you certified infrastructure, key management and gateway integrations ready to use, with far less PCI work on your side.
| Factor | Build in-house | Use a provider |
|---|---|---|
| Time to launch | Design, build, security review and PCI assessment | Integration work only, with no vault to build |
| PCI burden | Your vault is fully in your scope | Provider's AOC covers the vault |
| Key management | You run HSMs, rotation and access | Provider runs them |
| Gateway support | You build and maintain each integration | Proxy supports many gateways |
| Ongoing cost | Engineers, audits, monitoring, on-call | Subscription or usage fees |
| Control | Total | Defined by the provider's features |
When building makes sense: very high volume, payments as your core product and a mature PCI program. Otherwise, we recommend a provider.
How to evaluate and choose a card vault tokenization provider
Evaluating a card vault provider is a process of checking its compliance proof, capture and token options, gateway support, CVV and staff access controls, token portability and pricing at your volume.
These are the twelve questions we would ask before signing:
| Criterion | Why it matters | Question to ask |
|---|---|---|
| PCI DSS Level 1 AOC | The vault becomes part of your compliance chain | Can we see your current AOC? |
| SOC 2 Type II | Independent proof of controls over time | Is the report available under NDA? |
| Capture options | Cards arrive through more than one channel | Do you support iframe, IVR and API capture? |
| Token formats | Legacy systems may need card-shaped values | Which formats do you offer? |
| Gateway proxy | Lets you charge without touching the PAN | Which gateways and signing methods? |
| CVV handling | CVV cannot be stored after authorization | How long is CVV kept, and how is it deleted? |
| Staff access | Some workflows need a human | Can staff view cards without the PAN touching our servers? |
| Key management | Limits damage from any breach | Are keys unique per customer? |
| Audit logs | Evidence for audits and investigations | What is logged, and for how long? |
| Portability | Avoids lock-in | Can we export cards to another provider? |
| Pricing | Predictable cost at scale | Per request or per card, and what are overage rates? |
| Developer tools | Speed to launch | Is there a sandbox, API reference and sample code? |
Which security and compliance proof should you ask for?
A current PCI DSS Level 1 AOC and SOC 2 Type II report are the baseline. If you also handle health data, ask about a Business Associate Agreement.
Warning sign: a website badge with no current AOC to share.
Which capture and token options do you need?
List every channel where cards reach you, then match token formats to your systems: format-preserving for legacy screens, deterministic for card-on-file logic.
Quick test: any channel without a capture option will keep sending cards to email.
Can it charge through your existing gateways?
Confirm the proxy supports your gateway and its authentication method, and ask whether adding a second processor is configuration or a new project.
Ask for proof: a working sandbox charge through your own gateway account.
How does it handle CVV and staff access?
Look for a stated CVV deletion window. For staff access, ask how retrieval is authenticated, timed and logged.
Watch out for: staff access that relies on shared logins or has no time limit.
Can you take your tokens with you?
Ask for a written, PCI DSS compliant export process with a clear format and timeline.
Why it matters: without one, leaving means asking every customer to re-enter their card.
Is the pricing transparent at your volume?
Get a quote on your real monthly requests, including tokenization, proxy charges and retrievals. Published prices and a free tier are good signs.
Model it: take last month's orders, refunds and retries, and count each one as a request.
How much does card vault tokenization cost?
Card vault pricing is usually per request, per stored card or a flat monthly tier, and real cost depends on how many tokenize, charge and retrieval calls your workflows generate each month.
Common pricing models
| Model | How you pay | Fits when |
|---|---|---|
| Per request | Each tokenize, proxy or retrieval call | Volume varies month to month |
| Per stored card | A monthly fee for each card held | Many cards, charged rarely |
| Flat tier | A fixed fee up to a request limit | Steady, predictable volume |
One order can generate a tokenize call, a charge and a refund.
Hidden costs to watch for
- Overage rates above your tier.
- Separate fees for network tokens or account updater.
- Export charges if you leave.
- Paid support for production incidents.
- Engineering time for unsupported integrations.
Why vault fees sit on top of processor fees
A vault does not replace your acquirer or gateway, so interchange, network and processor fees still apply. Any savings from routing or rate negotiation depend on your own volumes and contracts.
Budget line: weigh vault fees against the PCI work and engineering time they remove.
How Enigma Card Vault tokenizes, stores and charges cards
We built Enigma Card Vault as a tokenization API with a payment gateway proxy, so you accept and reuse cards without storing them.
Capture options: hosted forms, embedded forms, IVR and API
- Hosted and embedded forms: iframe embed in 13 languages with your branding, returning the token through a postMessage callback.
- E-commerce storefronts: forms that fit Magento and WooCommerce checkouts.
- Phone payments: direct IVR-to-vault tokenization through Twilio Pay, with automatic card type detection.
- Direct API: one call, one token, with OAuth2 machine-to-machine auth.
Token options and ephemeral CVV
Tokens are random by default, with no structure to reverse. You can choose format-preserving, Luhn-passable tokens that keep the first six and last four digits, deterministic tokens for card-on-file logic and a per-request TTL. CVV is held encrypted for at most 30 minutes, then deleted.
Why Luhn-passable matters: checkout code, fraud rules and legacy systems that expect a valid-looking card number keep working unchanged.
Gateway-agnostic payment proxy
Card Vault forwards charges to Authorize.net, Stripe, Braintree, PayPal, Mastercard APIs and any REST-based gateway. Placeholders for card number, CVV and expiry are filled inside the vault, requests are signed with HMAC-SHA256 or OAuth 1.0a RSA-SHA256 for Mastercard, and destinations can be limited to an allowlist of gateway domains.
To switch gateways: you change the destination and request template, while tokens and stored cards stay where they are.
What integration looks like: two API calls to a token
- Authenticate: request an access token with OAuth2 client credentials.
- Tokenize: send the card, or let the hosted form send it, and receive the token with safe metadata.
Every request is audit logged, with API docs, Swagger UI and GitHub examples for developers.
Security, compliance and pricing
Card Vault runs on PCI DSS Level 1 and SOC 2 Type II certified infrastructure with AES-256 encryption and per-customer keys, and Enigma is an AWS Partner. Pricing is published and billed through AWS Marketplace:
| Plan | Price | Included requests | Overage |
|---|---|---|---|
| Lite | Free forever | 1,000 a month | $0.08 per request |
| Plus | $49.99 a month | 20,000 a month | $0.04 per request |
| Premium | $249.99 a month | 250,000 a month | $0.02 per request |
Every tier runs on the same certified infrastructure, with Plus adding ephemeral key sharing and email support. Start free with Enigma Card Vault: your checkout keeps working, and your auditor gets a shorter list.
