# Order a Virtual Card
source: https://developer.mastercard.com/mastercard-processing-core/documentation/use-cases/card-lifecycle/order-a-virtual-card/index.md

## Overview {#overview}

This use case describes the "digital first" card approach, where a new cardholder requests a virtual card. Before you send a request to create a virtual card, you must create the basic object structure (client and account contract) in the Mastercard Processing CMS.

## Sequence diagram {#sequence-diagram}

Diagram order-virtual-card-new

### Explanation {#explanation}

1. The cardholder signs up for and signs into the mobile application or e-banking service and orders a virtual card.
2. The mobile application or e-banking service sends a request to the server to create a virtual card for the new cardholder.
3. The server sends a `POST` request to the `/clients` endpoint through the Mastercard Processing API to create a `Client` in the CMS. You must pass the required fields `clientNumber` and `clientType` from your CBS in the request body. Note: The value of the `clientType` field must be agreed with Mastercard Processing during the onboarding process.
4. The `Client` is created in the CMS.
5. The CMS generates a unique `clientId` number and returns it to the server. Tip: The operationId `createClient` does not require a phone number or embossing data.  
   However, these fields are required by some operations:
   * Phone number is used for transaction authentication.  
   * Embossing data is used in requesting physical card production.  

   This setup was designed to enable creation of a client object even when the customer's phone number is not known or present. You can update the client object according to your needs later.
6. The server sends a `POST` request to the `/accounts` endpoint to create an account contract in the CMS. You must pass the required fields (`accountContractNumber` from the CBS, `clientId`, and `productCode`) in the request body. Note: The `productCode` defines the unique configuration of the account contract linked with certain parameters (for example, account contract category debit or credit) and account contract type (for example, client-owned or issuer-owned contracts). You can only use the value preconfigured in the CMS according to your requirements.
7. The account contract for the `Client` is created in the CMS.
8. The CMS generates a unique `accountContractId` number and returns it to the server. Note: The CMS also saves the `accountContractNumber` generated by the CBS. The number is preceded by a three-letter prefix that corresponds to your company name. The prefix is configured during the onboarding process, allowing Mastercard Processing to maintain a unique CBS number for each company in the CMS. Refer to [Object Identifiers](https://developer.mastercard.com/mastercard-processing-core/documentation/guides/card-management-system/index.md#object-identifiers) for more information.
9. The server sends a `POST` request to the `/cards` endpoint to create a card contract in the CMS. You must pass the required fields (`accountContractId` and `productCode`) in the request body. Tip: If you are a full PAN customer, you can generate and pass your PAN number in the `cardContractNumber` field. Otherwise, the CMS will generate the PAN number on your behalf based on the onboarding configuration with BIN ranges for the `productCode` related to this card contract. Note: The card contract `productCode` defines the unique configuration of the card contract linked with specific parameters (for example, card category debit or credit), and the card type (for example, virtual, physical, or both). You can use the `productCode` with the value preconfigured in the CMS according to your requirements. Alert: If you have not sent `embossedData` in the `createClient` request, you must send them in the `createCardContract` request even though you want to create a digital-first card. Otherwise, the request will be rejected.
10. The card contract and the first `Plastic` object are created for the account contract and the `Client`.
11. The CMS generates a unique `cardContractId` number and returns it to the server. Note: During the onboarding process, you can decide whether the newly created cards should be automatically enrolled in the Automatic Billing Updater (ABU) and Access Control Server (ACS) vendor for 3-D Secure authentication purposes.
12. The server sends a `success` response to the mobile application.
13. The mobile application or e-banking service notifies the cardholder that the virtual card is enrolled. The virtual card is activated and ready to use in e-commerce transactions.

You should now share the newly created virtual card details with the cardholder. For more information, refer to [Display Card Details to the Cardholder](https://developer.mastercard.com/mastercard-processing-core/documentation/use-cases/card-lifecycle/disp-card-det-to-crdholder/index.md).

After you execute this use case, a simple structure is created in the Mastercard Processing CMS:

* The client has one account contract, and the account contract has one card contract
* The same client owns the card contract as the account contract ![](https://static.developer.mastercard.com/content/mastercard-processing-core/uploads/simple-structure.png) Note: Mastercard Processing solution is flexible and allows you to create complex, multi-layer account structures. The CMS allows to create a structure of objects with different lengths and levels of hierarchy. For example, you can create many sub-accounts to sub-account under the top account contract.  
  When you create a top account contract, you must pass the `clientId` in the `POST` request to the `/accounts` endpoint, and the `clientId` subsequently becomes the account contract owner.  
  When you create a sub-account, it must be linked to a parent account contract that is not required to be a top account. Each request for sub-account creation requires to provide `parentAccountContractId` instead of the `clientId` in the request body. Tip: Account contracts can also be linked using `AccountContractLiability` object to indicate how an Open-To-Buy amount will be checked when the transaction is performed. For example, the link between account contracts is created to indicate one corporate headquarters account and many corporate branch accounts. Refer to the `AccountContractLiability` object in [Endpoints](https://developer.mastercard.com/mastercard-processing-core/documentation/use-cases/card-lifecycle/order-a-virtual-card/index.md#endpoints) for more information. Refer to [Sandbox testing](https://developer.mastercard.com/mastercard-processing-core/documentation/sandbox-testing/card-lifecycle-management/order-virtual-card/index.md) for information on how to execute the use case in the Sandbox environment.

## Endpoints {#endpoints}


API Reference: `POST /clients`


API Reference: `POST /accounts`


API Reference: `POST /cards`

<br />