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

## Overview {#overview}

This use case describes the process to order a physical to an existing virtual card when the issuer's personalization bureau processes the physical production of the card.

Note: The PIN must be set for a 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-is-pb-new

### Explanation {#explanation}

1. The cardholder requests a physical card in addition to the existing virtual card.
2. The mobile application or e-banking service sends the request to the server to order the 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` value to `Marked` in the card contract. Refer to [Card Contract Production Status](https://developer.mastercard.com/mastercard-processing-core/documentation/guides/status-changes/index.md#card-contract-production-status) for more information.
5. The API sends a response to the server confirming that the 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 the 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 your 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 server downloads the personalization file.
10. The server sends the personalization file to the issuer personalization bureau.
11. The issuer personalization bureau produces a physical card based on the personalization file received.
12. 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. Tip: Once a card is delivered, the cardholder must activate the card. Refer to the [Activate a Card](https://developer.mastercard.com/mastercard-processing-core/documentation/use-cases/card-lifecycle/activate-a-card/index.md) use case for details.

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`