Issue & Activate a Physical Card

Physical cards differ from virtual cards in two important ways: they require a cardType selecting a design slot, and they arrive in issuerCardStatus = 4 (Not Activated) — the cardholder must activate the card before it can be used for spending. This guide walks through issuance, the delivery window, activation, and initial PIN setup.

Prerequisites

The cardholder must have status = 1 (Approved).
The Program must have at least design slot 0 approved (designStatus = 1). No physical cards can be issued until a default design is approved — see Card Programs & Card Designs.
If issuing to a specific non-default design slot, that slot's design must also be approved.

Step 1: Issue the physical card

POST /cards/assign/{cardholderId}

Request fields

Field	Required	Type	Constraints	Notes
`nameOnCard`	Yes	string	1–26 chars	Name embossed or printed on the physical card during personalization — typically `FIRSTNAME LASTNAME` in uppercase
`cardType`	Yes	integer enum	`0`–`5`	Selects the card design slot. `0` = the Program's default design (and the default value if omitted). Slots `1`–`5` require that design slot to have `designStatus = 1` (Approved).
`alias`	No	string	—	Internal display alias for distinguishing between multiple cards
`transactionLimit`	No	integer	Decimal-implied; cannot exceed cardholder's limit	Card-level spending ceiling
`callingCode`, `countryCallingCode`, `phoneNum`, `cellNum`, `emailAdr`	No	—	—	Card-level contact details; defaults to cardholder's if not set

Example request

{
  "nameOnCard": "JORDAN REYES",
  "cardType": 0,
  "alias": "Primary Card",
  "transactionLimit": 200000
}

transactionLimit: 200000 = $2,000.00 in a USD-denominated Program.

Response

{
  "status": "success",
  "cardId": 9104,
  "type": "physical",
  "maskedCardNumber": "************5678",
  "cryptoAddresses": [
    { "chain": "evm",     "address": "0xA3f8d5Bc6534C0412925a9b7D3C8Z8e..." },
    { "chain": "bitcoin", "address": "bc1pxy3kgdygjrsqtzq2n0yrf249..." },
    { "chain": "solana",  "address": "9FqRdEVLxntMjTnxHhq2p0RwQ..." }
  ]
}

The card is now in cardStatus = 1 (Approved) and issuerCardStatus = 4 (Not Activated). Physical fulfillment begins immediately — the card will be personalized and shipped by Axys's fulfillment partner.

📘
Crypto deposit addresses are live immediately. Even though the card cannot be used for spending until activated, its cryptoAddresses are active from this moment. A cardholder can fund a physical card via crypto deposit before the card physically arrives.

Step 2: The delivery window

While the card is in transit (issuerCardStatus = 4):

You can query the card's status with GET /cards/{cardId}/status — it will return issuerCardStatus: 4 until the cardholder activates it.
The card cannot be used for point-of-sale, ATM, or online transactions.
The card can receive digital-asset deposits via its cryptoAddresses.
You can apply a bank-rail deposit via trace notification if the cardholder funds it before arrival.

Typical delivery timelines depend on the cardholder's country and the Program's fulfillment configuration — confirm with your Axys account team.

Step 3: Activate the card

PUT /cards/{cardId}/activate

The cardholder presents the details printed on their physical card, plus chooses a new PIN:

Field	Required	Type	Constraints	Notes
`cardNumber`	Yes	string	16 digits	The full PAN from the physical card
`expMonth`	Yes	string	`MM` format	Expiry month printed on the card
`expYear`	Yes	string	Year	Expiry year printed on the card
`cvv`	Yes	string	3 digits	CVV/CVC printed on the reverse
`newPin`	Yes	string	4 digits	The PIN the cardholder is setting

Building an activation flow

Design your activation UX to gather these five fields from the cardholder directly (e.g., a mobile or web form). The PAN/expiry/CVV serve as proof that the cardholder has physical possession of the card.

🚧
Handle activation inputs on the client, not the server, where possible. PAN, CVV, and PIN are the most sensitive fields in the entire API. If your architecture routes the activation form through your own backend, that backend is in-scope for PCI-DSS. Consider whether a direct client-to-API pattern (with the mTLS certificate held server-side but the sensitive fields collected client-side and transmitted directly) reduces your compliance surface. Discuss with your QSA.

Response

{
  "status": "success",
  "newStatus": 1
}

newStatus: 1 confirms the card is now issuerCardStatus = 1 (Active) and ready for use.

❗️
Activation is one-way. There is no "undo" — a card cannot be returned to issuerCardStatus = 4 (Not Activated) after activation. To temporarily suspend a card, use PUT /cards/{cardId}/status with newStatus = 2 (On Hold). To permanently close a card, see Manage the Card Lifecycle.

Step 4: Verify the card is active

GET /cards/{cardId}/status

{ "issuerCardStatus": 1 }

The card is now Active. The cardholder can use it immediately for point-of-sale and online transactions, subject to the card's balance and transaction limits.

Comparing virtual and physical card issuance

	Virtual (`POST /cards/virtual/{cardholderId}`)	Physical (`POST /cards/assign/{cardholderId}`)
`cardType` required?	No	Yes
Immediately active?	Yes	No — `issuerCardStatus = 4` until activated
Activation step?	None	`PUT /cards/{cardId}/activate` required
Crypto deposit addresses live immediately?	Yes	Yes
Physical fulfillment?	None	Personalized and shipped
PIN set at issuance?	No	No — set during activation

Prerequisites

Step 1: Issue the physical card

Request fields

Example request

Response

Step 2: The delivery window

Step 3: Activate the card

Building an activation flow

Response

Step 4: Verify the card is active

Comparing virtual and physical card issuance

What's next