Sensitive data

A small subset of card endpoints deal with cardholder credentials and authentication material. These endpoints are gated more strictly than the rest of the API — both at the gateway level (mTLS / IP allow-list) and at the application level (per-partner scope, audit logging).

What counts as sensitive

The following operations are classified as sensitive:

Operation	Why it's sensitive
Retrieve PAN (card number)	Full Primary Account Number. Sufficient for online purchases.
Retrieve CVV	The 3-digit security code printed on the card. Required for any card-not-present transaction.
Retrieve 3DS phone number	The phone number used to deliver OTP for 3-D Secure.
Set 3DS answer	The outcome of a 3-D Secure challenge, written back to the issuer.
Change PIN	Replaces the cardholder's PIN. Requires RSA-OAEP wrapping.
Force PIN lock	Invalidates the current PIN after too many wrong attempts.
Reset PIN tries	Resets the wrong-attempt counter on a temporarily locked PIN.
Holder authorize	Confirms a sensitive operation by re-prompting the cardholder for their PIN.

Why the extra friction

These operations can be used to:

• Clone a card (PAN + CVV + expiry).
• Bypass 3-D Secure (if the OTP phone is changed).
• Lock out a cardholder (force PIN lock).
• Approve a fraudulent operation (holder-authorize without the cardholder's consent).

Because of that, every sensitive call is:

1. Authenticated with a partner-scoped JWT including the sensitive scope claim.
2. Logged with full request/response payload (audit-loggable from the B2B dashboard).
3. Rate-limited more aggressively than non-sensitive endpoints.
4. Subject to webhook notifications — the cardholder receives an SMS / push on every successful sensitive call.

The expDate rule

Every sensitive endpoint requires the card's expiration date (MM/YYYY) in the request body or query string. This is a second factor that prevents a stolen API key alone from being enough to perform a sensitive operation.

See the Cards overview → expDate for the exact format and why the field exists.

Public-key cryptography for PIN

PIN changes and holder-authorize are wrapped with the partner's RSA public key using RSA-OAEP. The partner:

1. Generates a fresh AES session key.
2. Wraps the session key with the partner's RSA public key (RSA-OAEP, SHA-256).
3. Encrypts the PIN vector with the AES session key.
4. Sends both payloads in the request body.

The CIP backend unwraps the key with the partner's private key (held in the issuer's secure vault), decrypts the PIN, and forwards it to the card processor over the internal IT-Card channel. The plaintext PIN is never persisted.

Audit trail

Every sensitive operation produces an entry in the partner's audit log (see GET /api/partner/audit-logs → and the equivalent card-level history). The entry contains:

• The endpoint that was called.
• The partner identity and JWT subject.
• The card identifier (masked PAN).
• The HTTP status code returned.
• The timestamp.

API Reference

See the Cards → Sensitive section in the API Reference → for the full list of endpoints, payloads, and the Try it widget.