Cards
Issue virtual and plastic cards against the corporation wallet, link them to employees, and manage them.
Before You Start
Read the following guides before proceeding:
| Guide | Why |
|---|---|
| Getting Started | Platform overview and setup |
| Api Basics | Required headers and request configuration |
| Authentication | How to obtain the corporation token |
| Capabilities | Card issuance is capability-gated |
| Employees | Cards are linked to employee records |
Corporate cards are issued against the corporation wallet and spend from its token balances. Two formats
are available — Virtual, issued instantly, and Plastic, shipped to an address and activated on
arrival. Metal cards are not issued by the Corporate API.
Each card can be linked to an employee at issuance. The link decides three things at once: who can see
the card, whose name is embossed on it, and which billing address the processor receives. It cannot be
added or changed afterwards.
Issuance may carry a fee, depending on your company configuration. When fees are enforced there are two
settlement flows — pay the fee on-chain yourself and pass the transaction hash, or take a delivery_id
invoice and let Wirex debit at issuance. When fees are not enforced, the fee endpoints return 400 and
the issuance call is made directly.
A corporation may hold at most 30 virtual and 15 plastic cards. At the ceiling the capability turns
NotAvailable and issuance is refused until a card is closed.
Card Issuance Flow (Simplified)
Detailed documentation available in Issuing a Card,
Card Details and Managing a Card.
sequenceDiagram
participant App as Your App
participant Corp as Wirex Corporate API
App->>Corp: 1. GET /api/v1/corporations
Corp-->>App: capabilities[] — VisaVirtualCard Active
App->>Corp: 2. GET /api/v1/cards/{type}/fees/{country}
Corp-->>App: order_fee, or 400 if fees not enforced
App->>Corp: 3. POST /api/v2/cards/{type}/fees/{country}/payment
Corp-->>App: delivery_id
App->>Corp: 4. POST /api/v2/cards/virtual
Corp-->>App: card id
Corp->>App: POST /v2/webhooks/cards — status Requested
Corp->>App: POST /v2/webhooks/cards — status Active
App->>Corp: 5. POST /api/v1/confirmation/signature/verify
Corp-->>App: action_token
App->>Corp: 6. POST /api/v1/cards/{cardId}/details
Corp-->>App: card_number, expiry_date
| Step | Action | Description |
|---|---|---|
| 1 | GET /api/v1/corporations | Confirm the card capability is Active |
| 2 | GET /api/v1/cards/{type}/fees/{country} | Decide whether the fee flow applies |
| 3 | POST /api/v2/cards/{type}/fees/{country}/payment | Create the fee invoice and take delivery_id |
| 4 | POST /api/v2/cards/virtual | Issue the card and link it to an employee |
| 5 | POST /api/v1/confirmation/signature/verify | Exchange a wallet signature for an action token |
| 6 | POST /api/v1/cards/{cardId}/details | Read PAN and expiry |
Card Status Lifecycle
Requested → NotActivated → Active
↓
Blocked ←→ Active
↓
Closed
A virtual card goes straight from Requested to Active. A plastic card stops at NotActivated until
PUT /api/v1/cards/{cardId}/activate is called with the digits printed on the card.
Guides
| Guide | Description |
|---|---|
| Issuing a Card | Fee flows, issuance calls, employee linking and delivery |
| Card Details | Listing cards, visibility rules, and reading PAN, CVV and PIN |
| Managing a Card | Activate, block, unblock, close, rename and re-limit |
| 3DS Authentication | Approving and declining 3D Secure challenges |
Updated 20 days ago

