# Order or Reissue a Physical Card through the Mastercard Processing Personalization Bureau
source: https://developer.mastercard.com/mastercard-processing-core/documentation/use-cases/card-lifecycle/order-through-mc-pb/index.md

## Overview {#overview}

This use case describes the process when a cardholder orders a physical card to an existing virtual card that is produced by the personalization bureau provided by Mastercard Processing.

Note: A PIN must be set for the card. If you are issuing a physical card to an existing virtual card, you must invoke the PIN set first. Otherwise, your request will be rejected. Tip: The same steps in this use case are applicable in case of reissuing an existing damaged card that is still in the cardholder's possession.

<br />

## Sequence diagram {#sequence-diagram}

Diagram order-through-mc-pb-new

### Explanation {#explanation}

1. The cardholder requests to have a physical card in addition to their existing virtual card.
2. The mobile application or e-banking service sends the request to the server to order a physical card for the cardholder.
3. The server sends a `POST` request to the `/cards/{card_contract_id}/plastics` endpoint by passing the `REISSUE` value in the `reissueType` field in the request body. Note: Refer to the [Expiry Date Rule](https://developer.mastercard.com/mastercard-processing-core/documentation/guides/card-renewal/index.md#expiry-date-rule) to learn about how the expiry date is calculated by the CMS if you do not pass it in the request.
4. The CMS changes the `productionStatus` field to `Marked` status for the requested `cardContractId`. For more information, refer to [Card Contract Production Status](https://developer.mastercard.com/mastercard-processing-core/documentation/guides/status-changes/index.md#card-contract-production-status).
5. The API sends a response to the server confirming that physical card production has been requested with newly created `newCardExpiryDate`, `plasticId`, and `newSequenceNumber` values.
6. The server sends a response to the mobile application or e-banking service confirming that physical card production has been requested.
7. The mobile application or e-banking service notifies the cardholder that the physical card has been ordered.
8. The CMS generates an encrypted personalization file and uploads it to the SFTP. Note: Refer to [Personalization Process](https://developer.mastercard.com/mastercard-processing-core/documentation/guides/issuing-card/index.md#personalization-process) for more information.
9. The personalization bureau downloads the personalization file from the Mastercard Processing SFTP.
10. The personalization bureau produces a physical card based on the personalization file.
11. The personalization bureau generates a report in response to the received personalization file. The report is sent to Mastercard Processing and uploaded to the SFTP in your directory.
12. You can download the personalization report from your dedicated SFTP. The report masks the sensitive data.
13. The physical card is delivered to the cardholder. Note: After physical card production, the `productionStatus` of the card contract is changed to `Locked`. The status is used to prevent unauthorized card use during delivery to the cardholder. After the card is delivered, the cardholder must activate the card. Refer to [Activate a Card](https://developer.mastercard.com/mastercard-processing-core/documentation/use-cases/card-lifecycle/activate-a-card/index.md) use case for more information.

Refer to [Sandbox testing](https://developer.mastercard.com/mastercard-processing-core/documentation/sandbox-testing/card-lifecycle-management/order-phy-card-to-virtual-card/index.md) for information on how to execute the use case in the Sandbox environment.

## Endpoint {#endpoint}


API Reference: `POST /cards/{card_contract_id}/plastics`