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:

GuideWhy
Getting StartedPlatform overview and setup
Api BasicsRequired headers and request configuration
AuthenticationHow to obtain the corporation token
CapabilitiesCard issuance is capability-gated
EmployeesCards 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
StepActionDescription
1GET /api/v1/corporationsConfirm the card capability is Active
2GET /api/v1/cards/{type}/fees/{country}Decide whether the fee flow applies
3POST /api/v2/cards/{type}/fees/{country}/paymentCreate the fee invoice and take delivery_id
4POST /api/v2/cards/virtualIssue the card and link it to an employee
5POST /api/v1/confirmation/signature/verifyExchange a wallet signature for an action token
6POST /api/v1/cards/{cardId}/detailsRead 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

GuideDescription
Issuing a CardFee flows, issuance calls, employee linking and delivery
Card DetailsListing cards, visibility rules, and reading PAN, CVV and PIN
Managing a CardActivate, block, unblock, close, rename and re-limit
3DS AuthenticationApproving and declining 3D Secure challenges

Did this page help you?