QVault — Tokenization & Vault

QVault — Tokenization & Vault

QVault is the tokenization service and secure data vault of the QoinPay Enterprise suite. It replaces sensitive values — primary account numbers (PANs), bank account numbers, IBANs, and other regulated identifiers — with non-sensitive tokens that carry no exploitable value if leaked. The real data lives in a hardened, encrypted vault that only QVault can access, which pulls every other component of your platform out of PCI DSS cardholder-data scope. QVault runs entirely on your infrastructure; sensitive data never leaves your perimeter.

Why tokenize

Under PCI DSS, every system that stores, processes, or transmits cardholder data falls in assessment scope. By routing sensitive values through QVault at the point of capture and handing every downstream system a token instead, you confine cardholder data to one small, auditable component. Fraud rules, 3DS authentication, payout processing, reporting, and analytics all operate on tokens; only QVault — and the specific, tightly controlled calls that require the raw value — ever touch the real data.

Capabilities

• Tokenization — exchange a sensitive value for a token. Tokens can be format-preserving (a token that looks like a PAN, keeping BIN and last-four for display and routing while the middle is meaningless) or opaque random tokens where format is irrelevant.
• Detokenization — resolve a token back to its value. This is the sensitive operation, so it is separately permissioned, rate-limited, and fully audited; most of the platform never needs it.
• Secure storage — the vault store is encrypted at rest with envelope encryption: data keys wrap the records, and a master key held in an HSM or platform key store wraps the data keys. Compromise of the database alone yields nothing usable.
• Vault calls — beyond token/detoken, QVault can perform proxied operations so a token is used without ever exposing the raw value to the caller — for example presenting a PAN's BIN and last-four for display, or forwarding a detokenized value directly to an acquirer over a controlled channel.
• Key rotation and re-encryption — data keys and the master key rotate on schedule with online re-wrapping; tokens are stable across rotation so nothing downstream changes.

Integration

QVault exposes a minimal, high-security surface at /api/v1. The common operation is tokenization at capture:

POST /api/v1/vault/tokens
Content-Type: application/json

{
  "type": "pan",
  "value": "4111111111111111",
  "format": "preserving"
}

The response returns a token plus safe display metadata — never the raw value again:

{
  "token": "tok_9f2a7c...",
  "bin": "411111",
  "last4": "1111",
  "format": "preserving"
}

Every other QoinPay product — QShield rules, Q3DS authentication, payout processing — accepts the token in place of the raw value, so the sensitive data enters the vault once and never propagates.

Editions

• Standard — tokenization and detokenization, opaque and format-preserving tokens, envelope encryption with a software key store, and full detokenization audit. Suitable to remove most systems from PAN scope.
• Advanced — adds HSM-backed master keys, proxied vault calls (BIN/last-four presentation and acquirer forwarding without exposing the value to the caller), scheduled online key rotation and re-encryption, and multi-tenant vault partitioning with per-partition keys.

The active edition is set by the license key and upgraded in place without reinstalling.

Sizing

QVault is CPU-bound on encryption and I/O-bound on the vault store:

• Up to ~200 ops/s: 2 vCPU / 4 GB, single node, vault store on encrypted local or SAN volume.
• 200–1000 ops/s: 4 vCPU / 8 GB across two nodes; place the vault store on dedicated encrypted storage separate from the application database.
• 1000+ ops/s: scale nodes horizontally; HSM throughput becomes the ceiling for detokenization-heavy workloads, so size the HSM connection pool accordingly. Storage grows at roughly 1 KB per stored record; tokens themselves are small and cacheable.

Because tokenization sits at capture, size for peak inbound transaction rate, not average.

Licensing

QVault is perpetually licensed per production instance, with the edition and HSM entitlement encoded in the activation key. First-year SnS is included and covers cryptographic-library updates, HSM connector updates, and security fixes — critical for a component whose job is confidentiality. Non-production vaults (DR, staging) require their own licensed instances with independent key material. See the licensing overview for the entitlement lifecycle.

Deployment security

QVault is the most security-critical component in the suite; deploy it as a hardened, isolated tier:

• Place QVault on an isolated network segment. Only the capture point and the specific services authorized to detokenize should reach its API — enforce this at the network layer, not just in application config.
• Keep master keys in an HSM or dedicated key store; the application host must never hold key material that can decrypt the vault on its own.
• Grant detokenization narrowly and per-service; rate-limit it, and treat the detokenization audit log as append-only evidence for PCI assessment.
• Encrypt the vault store at rest, back it up encrypted, and rehearse key-rotation and restore procedures so recovery never requires exposing plaintext.
• Scope your PCI assessment around QVault deliberately — the entire benefit of tokenization is realized only when downstream systems provably never receive raw values. Pair with QShield, Q3DS, and QAuth, all of which operate on QVault tokens end to end.