Card Issuance is a configuration-driven capability that must be enabled before you can begin issuing cards.

Once enabled, your platform supports a unified issuance flow across card types—allowing you to issue both Debit and Prepaid cards through a single integration, manage lifecycle actions such as freezing or replacing cards, apply spend controls, and enable digital wallet provisioning.

How it Works

Before diving into APIs, here’s a quick overview of how card issuance comes together:

• Configure Card Program → Define rules, limits, and controls
• Prepare Cardholder → Ensure eligible individual or business user
• Issue Card → Use APIs to issue Debit or Prepaid cards

All underlying rules such as spend controls, restrictions, and validations—are automatically enforced based on your Card Program configuration.

Scenarios

Card issuance setup involves three main steps: configure your card program, prepare cardholders (if business), and verify eligibility. All rules and controls are enforced by your Card Program configuration.

sequenceDiagram
    participant App as Your Application
    participant AM as Account Management
    participant PCE as PCE

    App->>AM: Request Card Issuance enablement
    AM-->>App: Capability enabled + Card Program configured
    App->>PCE: POST /cardProgram/list (list available programs)
    PCE-->>App: Available Card Programs
    App->>PCE: GET /cardProgram/id/{id} (inspect config)
    PCE-->>App: Program limits, controls, rules
    opt Business Customer
        App->>PCE: POST /authorizedUser (create cardholder)
        PCE-->>App: Authorized User created
    end
    App->>App: Verify customer eligibility (CIP, active account)
    Note over App: Ready to issue cards

Before you begin (all scenarios)

• Card Issuance capability is enabled for your account.
• At least one Card Program is configured.
• Customer has completed identity verification (CIP).

Scenario 1: List Available Card Programs

Use this scenario to retrieve all card programs configured for your account before issuing cards.

Business Context: A fintech platform wants to offer both consumer debit cards and corporate expense prepaid cards.

You'll also need: Card Issuance capability enabled, at least one Card Program configured.

Request

POST /v1/issuance/cardProgram/list

{
  "criteria": {
    "filters": [
      {
        "key": "subType",
        "operator": "EQ",
        "values": ["PLASTIC"]
      }
    ]
  }
}

Use the returned program IDs when issuing cards.

Scenario 2: Retrieve Card Program Details

Use this scenario to inspect a specific card program's configuration, including limits and controls.

You'll also need: Card Program id from the list response.

Request

GET /v1/issuance/cardProgram/id/2567

Review the program's limits (dailySpend, perTransaction, atmDaily) and controls (international, ATM, online) before issuing cards.

Scenario 3: Create Authorized User for Business

Use this scenario to create an authorized user under a business customer before issuing them a card.

You'll also need: Customer is BUSINESS type and ACTIVE, authorized user details (name, DOB, SSN).

Request

POST /v1/customer/id/{customerId}/authorizedUser

{
  "firstName": "John",
  "lastName": "Smith",
  "dateOfBirth": "1985-06-15",
  "ssn": "123-45-6789",
  "email": "[email protected]",
  "phone": "+1-555-123-4567",
  "address": {
    "addressLine1": "100 Main Street",
    "city": "San Francisco",
    "state": "CA",
    "zip": "94102"
  }
}

Store the returned authorizedUser.id — you'll need it when issuing a card to this user.

Scenario 4: Retrieve Authorized Users

Use this scenario to list all authorized users under a business customer when you need to find a cardholder ID.

You'll also need: Customer is BUSINESS type, at least one authorized user exists.

Request

GET /v1/customer/id/{customerId}/authorizedUser

From the response, identify the correct user and extract the authorizedUser.id for card issuance.

Card Program Configuration

Card issuance is governed by a Card Program, which acts as the foundation for how your cards operate.

Each program defines the rules that every issued card will inherit, such as spending limits, merchant restrictions, and compliance requirements. This ensures consistency across your portfolio without requiring repeated configuration at the time of issuance.

Once your program is set up, you can list out the available card programs to understand what configurations are active for your account.

Use the POST /v1/issuance/cardProgram/list endpoint to filter and list out programs. When retrieving card programs, you can refine results using the following filters:

To inspect a specific card program, including its limits and controls, use the GET /v1/issuance/cardProgram/id/{id}. This step is typically performed before issuance to ensure you are using the correct program with the expected configuration.

Cardholder Eligibility

Before issuing a card, it’s important to ensure that:

• The customer has successfully completed identity verification
• A valid physical mailing address is be available (PO Boxes not supported)
• Issuance rules apply at the account level (for example, one physical debit card per user per account)

Supported Cardholders

Cards can be issued to both individual and business customers, depending on your use case. The cardholder represents the user who will use the card, even when the account belongs to a business.

1. Individual Customers

For individual customers, the account holder themselves is the cardholder.

Note: Only Debit cards (type = DEBIT) are supported for individual customers.

Once the customer is onboarded and meets all eligibility requirements, you can directly proceed with card issuance using their existing customer.id.

You can retrieve it using either of the following methods:

• Use the GET /v1/customer/externalId/{externalId} endpoint if you have an external reference ID; or
• Use the POST /v1/customer/list endpoint to search for the customer using filters such as externalId, individual.firstName, individual.lastName or individual.ssnLast4.

2. Business Customers

For business customers, cards are not issued to the business entity directly. Instead, they are issued to the owners or the authorized users that are associated with the business.

These users must first be created and linked to the business before issuing a card.

Supported cardholder roles include:

• Beneficial Owners: Users who own or control the business
• Authorized Users: Authorized to operate the account

Before issuing a card, these users must be created and linked to the business.

Preparing Cardholders for Business Customers

Issuing a card for a business involves identifying the specific user who will use the card and ensuring their details are available in the system.

Step 1: Create the cardholder

Depending on the type of user:

• Use the POST /v1/customer/id/{id}/authorizedUser API to create a new Authorized User associated with the business.
• Use the POST /v1/customer/id/{id} API to add or update beneficial owner details within the customer.

Step 2: Retrieve the cardholder ID

If you do not already have the required identifier:

• For Authorized Users, use the GET /v1/customer/id/{id}/authorizedUser API to retrieve all authorized users associated with the customer. From the response, identify the correct user and extract the authorizedUser.id.
• For Beneficial Owners, use the GET /v1/customer/id/{id}/beneficialOwner API to retrieve all linked individuals and obtain the corresponding beneficialOwner.id.

Step 3: Use the ID during card issuance

When issuing a card, pass the appropriate identifier to link the card to the correct user:

• cardholder.authorizedUser.id → for Authorized Users
• cardholder.beneficialOwner.id → for Beneficial Owners