The Seismic Cards API lets you issue virtual and physical cards, manage budgets, move funds between accounts, and query transaction history. Every request targets the sandbox or production base URL, carries anDocumentation Index
Fetch the complete documentation index at: https://docs.seismic-cards.systems/llms.txt
Use this file to discover all available pages before exploring further.
x-access-token header (except the OAuth endpoints), and sends and receives application/json.
Sandbox base URL: https://sandbox-api.seismic.systems
Production base URL: https://api.seismic.systems
Auth header: x-access-token: <token> on every authenticated request
Authentication
Seismic uses a two-step OAuth flow: first get a short-lived authorization code, then exchange it for a long-lived access token.Get an authorization code
GET /v1/oauth/authorize
Call this endpoint to receive a single-use authorization code. The code expires in 10 minutes — exchange it immediately at the next endpoint.
Your Seismic program’s client ID.
The single-use authorization code. Pass this to
POST /v1/oauth/access-token.Unix timestamp (seconds) when the code was issued.
Generate an access token
POST /v1/oauth/access-token
Exchange the authorization code for an access token and a refresh token. Cache the accessToken server-side — never expose clientSecret or raw tokens to a client browser or mobile app.
Your Seismic program’s client ID.
Your Seismic program’s secret. Server-side only — never expose this to a client.
The authorization code from
GET /v1/oauth/authorize.The token to send as
x-access-token on every subsequent request.Long-lived token (valid 30 days). Reserved for a future refresh endpoint — for now, re-run the two-step OAuth flow to get a new access token when yours expires.
Validity window in seconds. Default is
86400 (24 hours).Unix timestamp (seconds) when the token was issued.
Accounts
Create a sub-account
POST /v1/accounts/register
Create a sub-account for a new user under your top-level partner account. Each sub-account holds the user’s USD Wallet and card programs.
Send an
Idempotency-Key: <uuid> header so that network retries don’t create duplicate accounts.Display name for the sub-account (typically the user’s full name).
User’s email. Must be unique within your
parentAccountId.E.164 format with
+ (e.g. +15551234567). Optional but recommended for fraud scoring.Your top-level partner account UUID.
The new sub-account UUID. Store this — you’ll pass it to nearly every subsequent request.
The internal user identifier associated with the account.
Find an account by email
GET /v1/accounts
Look up an existing sub-account by email address. Returns at most one result per email per parentAccountId. Use this to de-duplicate retries before calling register again.
The email address to search for.
Submit KYC
POST /v1/accounts/{accountId}/kyc
Submit identity verification data for a sub-account using a Sumsub share token. The KYC decision typically arrives within 2 minutes via the KYC.UPDATED webhook.
The sub-account UUID.
KYC provider. Use
"sumsub" for Sumsub-sourced verification.Verified Sumsub share token (format:
_act-sbx-jwt-...).User’s real IP address. Improves fraud scoring accuracy.
Occupation code (e.g.
"11-1011").Annual salary with currency (e.g.
"75000 USD").Intended use of the account (e.g.
"Living Expense").Expected monthly spend with currency (e.g.
"1000 USD").Get KYC / CDD status
GET /v1/accounts/cdd/detail/{accountId}
Poll the KYC status of a sub-account, or use this to confirm the status before initializing the account.
The sub-account UUID.
One of:
| Value | Meaning |
|---|---|
NONE | No KYC submitted. |
PENDING | Under review. |
APPROVED | Cleared. You can now initialize the account and issue cards. |
REJECTED | Failed. Inspect caseId and resubmit with corrected data. |
The KYC case identifier. Include this when contacting support about a rejection.
Initialize the account
POST /v1/accounts/{accountId}/init
Provision the user’s USD Wallet and unlock card issuance. Call this once per user, immediately after KYC status becomes APPROVED.
The sub-account UUID.
Cardholders
Create a cardholder
POST /v1/cardholders
Create a cardholder profile for a user. You should create exactly one cardholder per user — reuse its id for every card you issue to that user. The cardholder status starts as PENDING and transitions to APPROVED within seconds; listen for the CARDHOLDER.UPDATED webhook.
The
Idempotency-Key header is required. Use a UUID v4 unique to this creation attempt.The user’s sub-account UUID.
UUID of the BIN to associate with this cardholder. Retrieve available BINs from
GET /v1/card/bins.Use
"B2C_GATEWAY" for consumer card programs.Your unique identifier for this cardholder (e.g.
yourapp-ch-{userId}). Must be globally unique across your program.A–Z letters only. Combined with
lastName (including the space) must be ≤ 23 characters.A–Z letters only.
User’s email address.
Country calling code, digits only — no
+. For example, use "1" not "+1".Phone number without the country code, up to 15 digits.
List cardholders
GET /v1/cardholders
Return all cardholder profiles under a sub-account. Use this to check whether a cardholder already exists before retrying a failed creation.
The sub-account UUID.
Request
Get a cardholder
GET /v1/cardholders/{cardholderId}
Fetch a single cardholder by ID.
The cardholder UUID returned when you created the cardholder.
The sub-account UUID.
Update a cardholder
PATCH /v1/cardholders/{cardholderId}
Update mutable fields on an existing cardholder. Include only the fields you want to change — accountId is always required.
The cardholder UUID.
The sub-account UUID.
New email address. Supported on BB / BZ BINs only.
New country calling code. Supported on non-BB / non-BZ BINs.
New phone number without country code.
Updated first name, if supported by your BIN.
Updated last name, if supported by your BIN.
Updated address. Address changes have limited BIN support — contact support if you receive error
010002.Request
BINs
List available BINs
GET /v1/card/bins
Return the BINs your program is authorized to issue cards on. Use the id from this response when creating cardholders and cards.
The sub-account UUID.
BIN UUID. Pass this as
binId when creating cardholders or cards.The 6-digit BIN prefix.
BIN type:
| Value | Meaning |
|---|---|
0 | Budget BIN. Cards spend from a linked budget. |
1 | Prepaid BIN. Cards spend from a balance attached directly to the cardholder. |
Supported currencies (e.g.
["USD"]).Card network (e.g.
"VISA").Whether this BIN can be used to issue physical cards.
Budgets
Create a budget
POST /v1/budgets
Create a budget that acts as a spending pool for one or more cards. Fund the budget before or after issuing cards — cards can only spend what the budget holds.
The
Idempotency-Key header is required. Use a UUID v4 unique to this creation attempt.The sub-account UUID.
Internal label for the budget (e.g.
"Q2 Marketing").Currency code. Currently only
"USD" is supported (default).Get a budget
GET /v1/budgets/{budgetId}
Fetch a budget’s current balance and status.
The budget UUID.
The sub-account UUID.
Request
POST /v1/budgets, with the current balance.available value.
Fund a budget (transfer-in)
POST /v1/budgets/{budgetId}/transfer-in
Move funds from the user’s USD Wallet into a budget. The balance becomes immediately available for card spending.
The budget UUID to fund.
Your idempotency key for this transfer. UUID v4 recommended.
USD amount to transfer, up to 2 decimal places (e.g.
"100.00").The sub-account UUID.
Withdraw from a budget (transfer-out)
POST /v1/budgets/{budgetId}/transfer-out
Pull funds back from a budget into the user’s USD Wallet.
The budget UUID to withdraw from.
Your idempotency key for this transfer. UUID v4 recommended.
USD amount to withdraw, up to 2 decimal places.
The sub-account UUID.
Request
Transfers
Transfer between accounts
POST /v1/business/transfer/external
Move funds between two USD Wallets — for example, from your master merchant account to a user’s account to top up their wallet before funding budgets.
The
Idempotency-Key header is required. Use a UUID v4 unique to this transfer.Your idempotency key for this transfer. UUID v4 recommended.
USD amount to transfer.
List wallets / USD Wallet balance
GET /v1/cards/wallets
List the wallets for a sub-account and check their current balances. Use the wallet id as the from.id or to.id in inter-account transfers.
The sub-account UUID.
Wallet type:
| Value | Meaning |
|---|---|
0 | USD Wallet — use id as from.id / to.id in inter-account transfers. |
Cards
Issue a virtual card
POST /v1/budget-card
Issue a virtual (or physical) card and link it to a budget. The card is immediately active and can be charged against the budget’s available balance.
The
Idempotency-Key header is required. Use a UUID v4 unique to this card issuance attempt.The user’s sub-account UUID.
UUID of the BIN to issue from. Must be
type: 0 (Budget BIN)."VIRTUAL_CARD" or "PHYSICAL_CARD".UUID of the user’s approved cardholder.
UUID of the budget that backs this card.
Your unique identifier for this card. Must be globally unique across your program.
Display name for the card (e.g.
"Travel"). Maximum 50 characters.Free-form tag for internal reporting.
Required when
cardMode is "PHYSICAL_CARD".Get card details
GET /v1/card-list
Fetch a card by ID. Returns a paginated list — filtering by cardId returns at most one record.
The sub-account UUID.
The card UUID.
Get card sensitive data (server-side)
GET /v1/cards/{cardId}
Return the full card number, expiry date, and CVV for a card.
The card UUID.
The sub-account UUID.
Get card access token (for the PCI widget)
GET /v1/cards/{cardId}/private-info/access-token
Return a short-lived JWT (valid for approximately 5 minutes) to bootstrap SeismicWidget.js in a client browser or mobile WebView. Your server fetches this token and passes it to your client — the client then uses it to initialize the widget without your server ever touching the raw card data.
The card UUID.
The sub-account UUID.
Update card label
PUT /v1/cards/{cardId}
Change the display label on a card.
The card UUID.
The sub-account UUID.
New display label for the card (e.g.
"Travel card").Request
Set velocity control
PUT /v1/cards/{cardId}/velocity-control
Apply a per-card spending limit. Only one limit type is active at a time — calling this endpoint replaces any existing limit.
The card UUID.
The sub-account UUID.
The period over which the limit applies. One of:
TRANSACTION, DAY, WEEK, MONTH, QUARTER, YEAR, LIFETIME, NA.USD spending limit, up to 2 decimal places (e.g.
"500.00").Periodic limits (
DAY, WEEK, MONTH, etc.) reset at 00:00 GMT+8. Use LIFETIME for an absolute cap that never resets.Request
Freeze a card
POST /v1/cards/{cardId}/freeze
Temporarily decline all future authorizations on a card. This does not affect transactions that have already settled.
The card UUID.
The sub-account UUID.
Unfreeze a card
POST /v1/cards/{cardId}/unfreeze
Restore a frozen card to active status.
The card UUID.
The sub-account UUID.
Request
Delete a card
DELETE /v1/cards/{cardId}
Permanently close a card.
The card UUID.
The sub-account UUID.
Request
Card transactions
List card transactions
GET /v1/cards/transaction-list
Return authorizations, settlements, refunds, and reversals for a card. Results are paginated and sorted by most recent first. By default the query covers the last 180 days.
The sub-account UUID.
The card UUID.
Page number (1-indexed).
Results per page. Maximum is
100.Filter by a single transaction UUID.
Filter by your client transaction ID.
Transaction type code (e.g.
"1" for Consumption).Filter by status:
PENDING, CLOSED, or FAIL.Lower bound as a Unix timestamp in milliseconds. Default is 180 days ago.
Upper bound as a Unix timestamp in milliseconds. Default is end of today.
Total number of matching transactions across all pages.
Transaction status:
| Value | Meaning |
|---|---|
PENDING | Authorization placed; not yet captured. |
CLOSED | Settled (captured). Money has moved. |
FAIL | Declined. |