Wallet and QR Payments
“Wallet” can mean a device presents a tokenized card credential, an operator maintains a custodial account ledger, or a user controls a blockchain private key. A QR code adds another axis: it packages an identifier or short-lived payment intent for scanning. None of these mechanisms alone proves that funds settled.
Mobile Wallet Tokenization
Separate five concepts often collapsed into “the wallet sends a token”:
- Provisioning associates a card or account with a wallet after issuer, network, and device checks.
- Payment token substitutes for the PAN and can be constrained to a device, merchant, or usage domain.
- Device credential and user verification authorize release of transaction data; they do not settle payment.
- Transaction cryptogram or signed payload binds transaction-specific data for downstream verification.
- Merchant processing still routes the method through a gateway, acquirer, network, issuer, or account rail.
Apple documents an encrypted payment token produced with Secure Element participation. Google Pay can return PAN-based data or a device token with a cryptogram; direct integrations must verify, decrypt, expire, and protect the payload. No single historical server-vault diagram is a universal wallet architecture, so that source image remains rejected.
Tokenization reduces PAN exposure but does not automatically remove PCI DSS scope. Prefer hosted or gateway-tokenized integration unless direct payload handling is a product requirement. Keep token vault and detokenization access narrow, rotated, audited, and absent from logs.
QR Presentation and Replay Safety
| Presentation | Static | Dynamic |
|---|---|---|
| Merchant-presented | Reusable merchant identifier; payer confirms merchant and amount | Short-lived intent binds merchant, amount, currency, reference, and expiry |
| Consumer-presented | Weak choice for reusable payment credentials | Short-lived wallet credential or transaction payload for merchant scanning |
Presentation does not determine whether the rail is debit, credit, card, or account-to-account. EMVCo standardizes QR data formats; the provider contract defines the messages after parsing. The four-mode source image remains rejected because it assigns unsupported debit and credit semantics to presentation direction.
For a dynamic merchant-presented code, sign or MAC intent_id, merchant, amount, currency, expiration, and nonce. The server loads the canonical intent, rejects expiry or merchant mismatch, and accepts one idempotent confirmation. A static QR should resolve only a merchant identity; the server creates a fresh attempt after the payer confirms the amount.
Scan-to-Pay Example
- Checkout creates an expiring payment intent and signed QR payload.
- The wallet scans it, displays canonical merchant and amount, and obtains user authorization.
- The wallet submits the intent with a stable confirmation key.
- The payment service changes
AWAITING_PAYER -> PROCESSINGonce and creates one provider attempt. - The merchant reads a verified server result, not the payer’s screen.
- Timeout produces
UNKNOWN; lookup, callback processing, and reconciliation resolve it.
The visual shows the participants, not replay prevention, ledger posting, callback verification, or reconciliation. A client-side “paid” screen is never settlement evidence.
Custodial Accounts and Self-Custody
| Question | Custodial ledger account | Self-custodied blockchain wallet |
|---|---|---|
| Authorization | Operator authenticates the customer | Private-key holder signs the transaction |
| Authoritative balance | Operator ledger reconciled to safeguarded or bank funds | Replicated ledger state for the chain |
| Recovery | Controlled support and compensating entries may be possible | Lost keys may be unrecoverable |
| Operational burden | Ledger integrity, custody, compliance, settlement | Key custody, fees, nonce handling, chain monitoring |
Choose custody when the product needs regulated account controls, reversible support operations, and bank or card integration. Choose self-custody only when user-controlled keys and protocol-level transfer semantics justify the recovery and chain risks. On Ethereum, an externally owned account address is derived from the public key; it is not simply the public key. The source visual asserting that equivalence remains rejected.
References
- EMV Payment Tokenisation — official token roles, domains, and constraints.
- Apple payment token format — official encrypted Apple Pay token structure and validation boundary.
- Google Pay payment data cryptography — official signed and encrypted payload, expiry, cryptogram, and direct-integration requirements.
- EMV QR Codes — official merchant-presented and consumer-presented formats and the boundary of the QR specification.
- PCI Tokenization Product Security Guidelines — tokenization security properties and system boundaries.
- Ethereum accounts — private-key control and address derivation for externally owned accounts.