> ## Documentation Index > Fetch the complete documentation index at: https://docs.imprint.co/llms.txt > Use this file to discover all available pages before exploring further. # Card issuance > Understand how unified and distinct card issuance modes work, and what to expect from webhooks and card behavior ## Overview When a customer accepts their credit offer, Imprint issues their initial card(s). This guide covers how initial card issuance works depending on your program's configuration. A card's details consist of its PAN (Primary Account Number, i.e. the 16-digit card number), CVV, and expiration date. These details together identify the card for transactions. ### Card issuance modes Imprint supports two card issuance modes for your program: | Mode | Description | | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Distinct cards** | The customer receives a distinct virtual card and physical card, each with their own PAN, CVV, and expiration date. | | **Unified card** | One set of card details is issued when the customer accepts their credit offer. The same PAN, CVV, and expiration date are used for both online and in-store transactions. | Your card issuance mode is configured per program. Contact your Imprint team to confirm or update your program's configuration. ### Card types | Card Type | Description | | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `VIRTUAL` | A digital-only card issued for online transactions. Always created in `ACTIVE` status. Issued in distinct cards programs at offer acceptance. | | `PHYSICAL` | A card tied to a physical form factor mailed to the customer. Created in `INACTIVE` status and requires activation after delivery. Issued in distinct cards programs after customer accepted offer and selected a card design. | | `UNIFIED` | A single card that serves both online and in-person use cases. Issued in unified card programs. The customer receives one set of card details regardless of whether they use it online or with the physical card. | The `card_type` field in `PAYMENT_METHOD` webhooks indicates the type of card issued. ## Distinct cards experience In the distinct cards model, you receive two payment methods: 1. **Virtual card** — Created immediately when the customer accepts the credit offer. Always created in `ACTIVE` status so that customers can use the card number for online purchases immediately. 2. **Physical card** — Created when the customer selects a card design (or when a default design is auto-assigned). Created in `INACTIVE` status and must be activated by the customer after receiving the physical card. You will receive two `PAYMENT_METHOD` webhooks — one for each distinct card. For the full `PAYMENT_METHOD` webhook payload and field descriptions, see the [Payment Method Event Notification](https://docs.imprint.co/api-reference/webhooks/payment-method-event-notification) reference. ## Unified card issuance experience In the unified card model, customers receive a single payment method with one set of card details. The card is created in `ACTIVE` status immediately when the customer accepts the credit offer and selects a card design. The customer can use the card number for online purchases right away, even before receiving the physical form of the card in the mail. **What you receive:** * One `PAYMENT_METHOD` webhook with `card_type: "UNIFIED"` and `new_status: "ACTIVE"` **Customer experience:** * Card is immediately usable for online and in-store transactions * Customer receives in the mail a physical form of the card with the same card number. * Customer can see full card numbers in Imprint applications. * No activation step required after receiving the physical card. Customer can start using the physical form of the card for in-person transactions immediately upon receiving the card. For the full `PAYMENT_METHOD` webhook payload and field descriptions, see the [Payment Method Event Notification](https://docs.imprint.co/api-reference/webhooks/payment-method-event-notification) reference. ## Migration from distinct cards to unified card If your program migrates from distinct cards to unified card issuance: * **New customers** who accept their credit offer after the migration will receive a single unified card. * **Existing customers** who were onboarded before the migration will retain their separate virtual and physical cards. * When an existing customer reissues their physical card, they will receive a unified card that can be used right away for online transactions. After migration, you should expect to receive `PAYMENT_METHOD` webhooks with `card_type: "UNIFIED"` for new customers. Update your webhook handler to recognize this card type alongside `VIRTUAL` and `PHYSICAL`. ## Summary | | Distinct cards | Unified card | | ---------------------------------------------------- | ------------------------ | ----------------------- | | **Cards issued** | 2 (virtual + physical) | 1 (unified) | | **Webhook count after offer is accepted** | 2 per customer | 1 per customer | | **`card_type` value** | `VIRTUAL` and `PHYSICAL` | `UNIFIED` | | **Physical card activation** | Always required | Configurable by program | | **Online transactions before physical card arrives** | Yes, on virtual card | Yes, on unified card |