# Replace a Card with New Virtual and Physical Cards
source: https://developer.mastercard.com/mastercard-processing-core/documentation/use-cases/card-lifecycle/replace-vc-with-pc/index.md

## Overview {#overview}

This use case describes the process for a cardholder to replace the lost or stolen card.

## Sequence diagram {#sequence-diagram}

Diagram replace-vc-with-pc-new1

### Explanation {#explanation}

1. The cardholder requests to replace the current stolen or lost card with new virtual and physical cards.
2. The mobile application or e-banking service sends a request to the server to replace the card.
3. The server sends a `PUT` request to the `/cards/{card_contract_id}/status` endpoint by passing the `statusCode` field in the request body with the value that reflects the reason for blocking the card. Refer to [Card Contract Status](https://developer.mastercard.com/mastercard-processing-core/documentation/guides/status-changes/index.md#card-contract-status) for more information.
4. The API returns a response with information about the successful card status change.
5. The server sends a `POST` request to the `/cards/{card_contract_id}/plastics` endpoint by passing the `REPLACE_D` value in the `reissueType` field in the request body. Note: Refer to [Card Lifecycle Overview](https://developer.mastercard.com/mastercard-processing-core/documentation/guides/card-lifecycle/index.md) for more information.
6. The API returns a response with the newly generated `newCardContractId`, `newCardContractNumber`, `newCardExpiryDate`, `newSequenceNumber`, and `plasticId` values.
7. The server sends a response to the mobile application or e-banking service.
8. The mobile application or e-banking service notifies the cardholder that the current card has been blocked and a new virtual card has been created. Note: Once the virtual card has been created, you can retrieve the card details. 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) for more information. The PIN must be set for the card. Refer to [Set a PIN for a Full PAN Issuer](https://developer.mastercard.com/mastercard-processing-core/documentation/use-cases/pin-management/set-pin-full-pan-issuer/index.md) and [Set a PIN for a PAN-less Issuer](https://developer.mastercard.com/mastercard-processing-core/documentation/use-cases/pin-management/set-pin-pan-less-issuer/index.md) for more information. If the PIN is not set, then step 9 will fail.
9. Once the PIN for the new card is set, the server sends a `POST` request to the `/cards/{card_contract_id}/plastics` endpoint to issue a physical card. You must pass the new `cardContractId` parameter (from step 6) and the `REISSUE` value in the `reissueType` field in the request body.
10. The CMS changes the `productionStatus` of the card contract to `Marked`. 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.
11. The API sends a response to the server with the new `plasticId`, `cardExpiryDate`, and `sequenceNumber` values confirming that physical card production has been requested.
12. The server sends a response to the mobile application or e-banking service confirming that physical card production has been requested.
13. The mobile application or e-banking service notifies the cardholder that the physical card has been ordered.
14. The CMS generates an encrypted personalization file and uploads it to the SFTP of the personalization bureau.
15. The personalization bureau downloads the personalization file from the Mastercard Processing SFTP.
16. The personalization bureau produces the physical card based on the personalization file.
17. 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 dedicated directory.
18. You can download the personalization report from the dedicated SFTP. The report has the sensitive data masked. Note: Refer to [Personalization Process](https://developer.mastercard.com/mastercard-processing-core/documentation/guides/issuing-card/index.md#personalization-process) to learn more about the personalization file and report.
19. The physical card is delivered to the cardholder. Tip: The cardholder must activate the card once it is delivered. 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. Before the new physical card is activated, the status of the `plasticId` for the new physical card is set to `Locked` to prevent unauthorized card use. Refer to [Sandbox testing](https://developer.mastercard.com/mastercard-processing-core/documentation/sandbox-testing/card-lifecycle-management/replace-card/index.md) for information on how to execute the use case in the Sandbox environment.

## Endpoints {#endpoints}


API Reference: `PUT /cards/{card_contract_id}/status`


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

<br />