Who this is for: security reviewers, card issuers, brokerages, POS providers and developers. Merchants can start with the Digital Receipts overview instead.
Design goals
- The customer owns the data. Receipts are encrypted to the customer’s public key. Only the matching private key, held on the customer’s device, can decrypt them.
- Proof of authenticity. Merchant and issuer each sign the receipt, so tampering is detectable.
- Portability. Receipts use a standard JSON-LD format, so they can move between banks, brokerages and apps without being rebuilt.
- No lock-in. The protocol is open, so any party can implement it.
Technical foundation
Participants
The flow
- The customer pays at the merchant’s POS.
- The merchant’s POS builds an itemized JSON-LD receipt and signs it with the merchant’s private key.
- The receipt is encrypted with the customer’s public key and sent to the card issuer.
- The issuer adds its signature and stores the encrypted receipt against the transaction.
- The customer opens it in their banking app, which decrypts it on the device.
See the sequence diagram
The full flow from payment intent through receipt viewing.
Encryption and key ownership
Key generation, storage, signatures and recovery.
Portability and sharing
How receipts move to banks, brokerages and third parties.
Card issuers
Add receipts to a banking app.
POS systems
Send receipts for every merchant on your platform.