> ## Documentation Index > Fetch the complete documentation index at: https://imprint-b3c5d5af-partner-docs-latest.mintlify.site/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. Imprint will not cancel existing virtual cards, as doing so would disrupt active customer spending patterns. * Existing virtual cards will naturally expire at their expiration date. Imprint will not reissue expired virtual cards for programs that have migrated to unified card issuance. * When an existing customer's physical card expires and is reissued, the replacement will be a unified card that can be used immediately for both online and in-store transactions. ### Example: Physical card reissuance after migration When an existing customer's physical card is reissued after the program has migrated to unified card issuance, you will receive two webhooks: **Webhook 1:** The old physical card is canceled. ```json theme={null} { "object": "PAYMENT_METHOD", "data": { "payment_method_id": "DCBFC736-2286-42DD-897D-160DCA80AED2", "customer_id": "2EE24580-B97B-4949-A65C-929CCB9B9B8D", "partner_customer_id": "PARTNER_USER_456", "card_type": "PHYSICAL", "previous_status": "ACTIVE", "new_status": "CANCELED", "created_at": "2025-02-13T19:08:07.000Z", "updated_at": "2026-07-24T14:30:00.000Z" } } ``` **Webhook 2:** A new unified card is created in `ACTIVE` status. ```json theme={null} { "object": "PAYMENT_METHOD", "data": { "payment_method_id": "A1B2C3D4-5678-90EF-GHIJ-KLMNOPQRSTUV", "customer_id": "2EE24580-B97B-4949-A65C-929CCB9B9B8D", "partner_customer_id": "PARTNER_USER_456", "card_design_id": "3b9c1f3e-52a0-44c1-b131-a7ab0099a214", "card_type": "UNIFIED", "new_status": "ACTIVE", "created_at": "2026-07-24T14:30:00.000Z", "updated_at": "2026-07-24T14:30:00.000Z" } } ``` The customer's existing virtual card remains active and unaffected. It will expire naturally at its expiration date and will not be reissued. After migration, you should expect to receive `PAYMENT_METHOD` webhooks with `card_type: "UNIFIED"` for new customers and for reissued cards. 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 | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.