Card details (PAN, CVV, expiry) and the card PIN each use separate view tokens. You must request the correct
enabled_views for each use case. Never reuse a token between sessions.How it works
Sensitive card data is never returned in plain API responses. Instead, Yativo hosts a secure card view page and provides you with a short-lived URL to embed in your application:- Your backend calls
POST /yativo-card/{yativoCardId}/cards/{cardId}/view-token - If you request
["data"]or["pin-view"]andpin_setisfalse, the API returnsPIN_NOT_SETand apin_setup_url— direct the cardholder there to set their PIN first. If you request["pin-set"], you always receive asecure_view_urlregardless ofpin_setstatus. - Yativo returns a
secure_view_url— a hosted, tokenized page - Your frontend embeds that URL in an
<iframe> - The hosted page renders the sensitive data directly — your application never touches the raw values
Step 1 — Request a view token
Call this from your backend. The token is scoped to the views you request.string
required
The Yativo Card account ID (
yativo_card_id) returned during onboarding.string
required
The card ID from card creation.
array
Which views to enable on the hosted page. Accepted values:
The legacy value
"pin" is accepted as an alias for "pin-set".Combine freely, e.g. ["data", "pin-view", "pin-set"]. The page renders one tab per value. If pin_set is false and "pin-set" is not in the request, the API returns 422 PIN_NOT_SET. Including "pin-set" in any request bypasses that gate — the token is issued so the cardholder can set their PIN.string
Optional extra PIN or unlock code the user must enter before the card details are revealed. Adds an additional layer of protection for high-security flows.
object
Optional per-request theme tokens for the hosted page wrapper. For full CSS control — including card data text colors and fonts — set persistent customization via
PUT /api/card-issuer/pse-customization (see Custom CSS below). All theme fields are optional.string
Primary brand color (hex). Default:
#813AE3string
Page background color (hex).
string
Card panel background color (hex). The card data area itself always stays light, with dark digits. See Light card data.
string
Primary text color (hex).
string
Secondary/muted text color (hex).
number
Border radius in pixels.
string
CSS font-family string (e.g.
"Inter, sans-serif").string
URL of your logo to display on the hosted page.
Response Type Definitions
Response Type Definitions
Step 2 — Embed the iframe
Pass thesecure_view_url directly as the src of an iframe. No SDK or additional JavaScript is required.
Step 3 — Backend proxy (required)
Your frontend must never call the Yativo API directly with your credentials. Always proxy the token request through your backend:- Express.js
- Frontend (after fetch)
- React
View options reference
Pass an array with any combination:
["data"]— card details only["pin-set"]— PIN setup only (e.g. initial onboarding)["data", "pin-view"]— card details + reveal PIN["data", "pin-set"]— card details + change PIN["data", "pin-view", "pin-set"]— all three tabs
pin_set reflects the last known state from card activity webhooks. If pin_set is false and you request ["data"] or ["pin-view"], the API returns a PIN_NOT_SET error with a pin_setup_url — direct the cardholder there to set their PIN, then retry once the webhook confirms.Requesting ["pin-set"] always returns a secure_view_url (HTTP 200) regardless of pin_set — use this to present the PIN setup screen without checking pin_set first.Access code flow
When you passaccess_code in the token request, requires_access_code: true is returned. The hosted page will prompt the user to enter that code before revealing any card details. Use this for:
- Confirming user intent before showing the full card number
- Adding a secondary verification step in high-value contexts
Customization
The secure view page supports two levels of customization: per-request theme tokens and persistent CSS overrides.Theme tokens (per request)
Pass atheme object in the view-token request to apply brand colors, fonts, and a logo. These take effect immediately on every URL you generate.
All fields are optional. Unset fields fall back to the defaults above.
Custom CSS (persistent, issuer-level)
For fine-grained control over colors, typography, and spacing, you can supply raw CSS that is stored against your issuer account and applied to every secure view URL you generate. The page has two layers — your CSS affects them differently: Layer 1 — Page shell (injected directly into the page<style> block)
The Yativo-rendered wrapper: background, header, tabs, status bar, frame container. All standard CSS applies normally.
Layer 2 — Card data area (forwarded to the secure card SDK)
The card number, expiry, and CVV are rendered inside a cross-origin secure iframe. Yativo extracts a specific set of selectors from your stylesheet and forwards them to the secure card SDK, which applies them to the card data elements. Background colors, borders, label fonts, and copy-button styles apply reliably. Card digit text color can’t be changed: card data always renders dark on a light background.
Supported selectors
Page shell
Card data area
Manage your customization
Example: brand colours + Inter font
Light card data
The card number, expiry, CVV and PIN always render on a white background with dark digits. This stays the same on every device, including phones in dark mode, so card details are always legible. Your theme colors, font and logo still style the page around the card data.Styling notes
Virtual Cards
Create and manage virtual cards.
API Reference — View Token
Full parameter reference for the view-token endpoint.

