Issuing a card through the Seismic API takes three phases. The first time you onboard a user you work through all three phases. Every subsequent card for that same user is a single API call — Phase C only. This guide walks you through the complete flow.Documentation 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.
Before you start, make sure you have a valid
accessToken (see Authentication), your parentAccountId, your defaultBinId, and the user’s legal name, email, phone number, date of birth, and full address. Your webhook endpoint should also be registered in the Seismic dashboard.Phases at a glance
| Phase | Steps | Frequency |
|---|---|---|
| A. User onboarding | Create sub-account → KYC → Initialize | Once per user |
| B. Resource provisioning | Create cardholder → Create and fund budget | Once per user |
| C. Card issuance | Issue the card | Every card |
Phase A — User onboarding
Create a sub-account
Every end user gets their own Seismic sub-account. The sub-account is the legal envelope that owns the user’s cardholder, budget, and cards.Request bodyResponse (200)Save
Full legal name of the end user.
User’s email address. Must be unique within the same
parentAccountId.Phone number in E.164 format, including country code (e.g.
+15551234567).Your partner account UUID. This is the merchant account that owns all sub-accounts.
accountId to your database — you’ll attach it to every subsequent call for this user.If you call
register with an email that already exists for the same parentAccountId, you’ll receive error 40001 email already exists. Look up the existing account via GET /v1/accounts?email=... before retrying.Submit KYC
Cards cannot be issued until the user has passed KYC. Seismic supports two flows: bring your own KYC (submit a verified Sumsub share token) or hosted KYC via the dashboard. This guide shows the Sumsub flow.Request bodyThe KYC submission is asynchronous. Seismic fires a
KYC provider. Use
sumsub for the Sumsub share-token flow.The share token issued by Sumsub after the applicant completes your KYC flow.
IP address of the end user at the time of submission. Improves fraud scoring accuracy.
Occupation code (SOC 2018 format, e.g.
11-1011).Annual salary with currency, e.g.
"75000 USD".Purpose of the account, e.g.
"Living Expense", "Business".Expected monthly spend with currency, e.g.
"1000 USD".KYC.UPDATED webhook when the result is available — typically within two minutes. You can also poll the status endpoint.Get KYC status
Poll this endpoint or rely on the Response while in reviewResponse when approvedKYC status values
KYC.UPDATED webhook to know when to proceed.status | What it means |
|---|---|
NONE | No KYC submitted yet. |
PENDING | Under review — wait for the webhook. |
APPROVED | KYC passed. Continue to the next step. |
REJECTED | KYC failed. Inspect caseId in your KYC dashboard, collect new documents from the user, and resubmit. |
Phase B — Resource provisioning
List available BINs
Before creating a cardholder, confirm which BINs your account has access to. Budget cards require a Response (200)BIN type reference
Save the
type: 0 BIN.type | Meaning |
|---|---|
0 | Budget BIN — required for POST /v1/budget-card. |
1 | Direct-load BIN — funded per card rather than via a shared budget. |
id of your preferred BIN as binId — you’ll use it when creating the cardholder and when issuing the card.Create a cardholder
A cardholder is the persistent identity behind every card a user owns. Create exactly one per user and reuse the same Request bodyResponse (200)Save
cardholderId for all subsequent cards.UUID of the user’s sub-account from Step 1.
UUID of the BIN from the list endpoint. Must be a
type: 0 BIN.Use
B2C_GATEWAY for consumer cards.Your stable internal identifier for this cardholder (e.g.
yourapp-ch-{userId}). Used to detect duplicates on retry.First name. Letters A–Z only — no accents, hyphens, or punctuation. Combined with
lastName, must be 23 characters or fewer including the space.Last name. Same character constraints as
firstName.User’s email address.
Digits only — no
+. Use 1 for the US, not +1.Local phone number. Validated against Google
libphonenumber — 555 test numbers fail.Billing address for the cardholder.
data.id as the user’s cardholderId. The cardholder transitions from PENDING to APPROVED within seconds. Subscribe to the CARDHOLDER.UPDATED webhook to be notified.Create a budget
A budget is the USD pool that backs your user’s cards. Cards spend from the budget; if the budget balance reaches zero, authorizations decline.Request bodyResponse (200)Save
UUID of the user’s sub-account.
Human-readable name for this budget, shown in the merchant portal.
Currency code. Use
USD.data.id as the user’s budgetId.Fund the budget
A budget starts at $0.00. Move USD into it from your master merchant account before the user can spend.Step 1 — Top up the user’s USD Wallet from your master merchant poolUse Step 2 — Transfer from the USD Wallet into the budgetResponse (200)Verify the balance by fetching the budget:
POST /v1/business/transfer/external to move funds from your master merchant account into the sub-account’s USD Wallet. See API Reference → Inter-account transfers for the full parameter reference.You can check the sub-account’s USD Wallet balance at any time:Your unique identifier for this transfer. Use a UUID. Re-using this ID returns the original response without creating a duplicate transfer.
Amount in USD as a decimal string, e.g.
100.00.UUID of the user’s sub-account.
Phase C — Card issuance
Issue the virtual card
This is the only call you repeat for each new card. Pass the Request bodyResponse (200)Key response fields
accountId, binId, cardholderId, and budgetId from the previous steps. The card is created instantly in ACTIVE status, ready for online purchases.UUID of the user’s sub-account.
UUID of the BIN. Must be a
type: 0 (Budget) BIN.VIRTUAL_CARD for a digital-only card. PHYSICAL_CARD for mailed plastic — requires additional onboarding; contact your account manager.UUID from the create-cardholder step.
UUID from the create-budget step.
Your globally unique identifier for this card. Must be unique across all cards. Re-using one fails with error
40001. Recommended format: {your-prefix}-{userId}-{timestamp}.Human-readable card name shown in the merchant portal. Up to 50 characters.
Free-form tag for reporting, e.g.
Online advertising, Travel.The Seismic card UUID. Persist this as
cardId — you’ll use it to show card details, freeze/unfreeze, and look up transactions.Last 4 digits of the PAN. Safe to display in your UI.
First 6 digits of the PAN. Safe to display.
ACTIVE, INACTIVE, CONTROL, PENDING, or FROZEN.Velocity limits on the card. Empty by default. Call
PUT /v1/cards/{cardId}/velocity-control to add limits by day, month, or lifetime.What’s next?
The card is nowACTIVE and ready for online purchases. Here are the most common next steps:
Show card details
Display the full PAN, CVV, and expiry in your app without touching raw card data using the PCI Widget.
Receive spend events
Subscribe to
CARD_TRANSACTION.CREATED and CARD_TRANSACTION.UPDATED for real-time authorizations and settlements.API reference
Freeze/unfreeze cards, set velocity controls, pull transaction history, and more.
| Goal | Endpoint |
|---|---|
| Set per-card spending limits | PUT /v1/cards/{cardId}/velocity-control |
| Freeze or unfreeze the card | POST /v1/cards/{cardId}/freeze / unfreeze |
| Pull transaction history | GET /v1/cards/transaction-list?cardId={cardId}&accountId={accountId} |
| Top up the budget | POST /v1/budgets/{budgetId}/transfer-in |
| Cancel the card permanently | DELETE /v1/cards/{cardId}?accountId={accountId} |