After ownership verification, card number, CVV, and expiry are returned in plaintext. We ensure these details are not stored in our databases or logs.
View Card Credentials
POST /v1/cards/{id}/secure-session
After verifying that the card belongs to your merchant and to the member specified by x-on-behalf-of, we call the upstream system in real time and return the card number, CVV, and expiry in plaintext. PIN is not included.
The Boundary Is Not a Ban on Merchant Access
A full card number and CVV are sufficient to spend. Our responsibility covers our own servers: we do not store them in databases or logs, and lists and details expose only the first and last four digits. Once ownership is verified, we return plaintext; how you show it to your own users is your responsibility.
Three Guarantees
- No idempotency caching: otherwise PAN/CVV would enter our idempotency store.
- Responses must not be cached:
Cache-Control: no-store. - Audit records identify who viewed the details, never the credentials themselves.
If CVV Access Is Locked
POST /v1/cards/{id}/cvv/unblock
After several failed card-credential requests, the upstream system locks CVV access and cvv_blocked in card details becomes true. secure-session then returns state_invalid; unlock access before querying again.
Read cvv_blocked first and unlock if necessary. Give the user a clear explanation instead of letting them open a flow that will fail.
- No step-up authentication required: unlocking reveals no credentials. Query the details again in real time afterward.
- Rate-limited to 5 attempts per member per hour.
- The response only confirms unlocking. The source of truth for
cvv_blockedisGET /v1/cards/{id}; query that endpoint again.