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

## Overview {#overview}

This use case explains the internal process of automatic card renewal. The situation applies when you must renew virtual and physical cards for a cardholder because their expiry date is close.

The automatic renewal process is managed by Mastercard Processing CMS and can be defined during onboarding configuration. If configured, the CMS will automatically renew cards in `Active` status with a `cardExpiryDate` in less than 30 days.

## Sequence diagram {#sequence-diagram}

Diagram renew-with-vc-pc-new

### Explanation {#explanation}

1. The server sends a `POST` request to the `/cards/{card_contract_id}/plastics` endpoint by passing the `RENEW_D` value in the `reissueType` field in the request body.
2. The API sends a response with the `newCardExpiryDate`, `plasticId`, and `newSequenceNumber` values of the newly created virtual card. Note: After the virtual card is renewed, you can retrieve card data. Refer to [Display a 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. In this situation, you do not set the PIN for the new card. The PIN is transferred from the old card.
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.
4. The API sends a response to the server with the `newCardExpiryDate`, `plasticId`, and `newSequenceNumber` values confirming that the physical card production has been requested. 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.
5. The CMS changes the `productionStatus` field 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.
6. The CMS generates an encrypted personalization file and uploads it to the SFTP of the personalization bureau.
7. The personalization bureau downloads the personalization file from the Mastercard Processing SFTP.
8. The personalization bureau produces a physical card based on the personalization file.
9. The personalization bureau generates a report in a response to the received personalization file. The report is sent to Mastercard Processing and uploaded to the SFTP in your dedicated directory.
10. You can download the personalization report from your dedicated SFTP. The sensitive data in the report is 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.
11. The physical card is delivered to the cardholder. Tip: The cardholder must activate the new card once it is delivered. 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 more information. Before activation, the `plasticId` of newly created physical card is in `Locked` status to prevent unauthorized card use. Refer to [Sandbox testing](https://developer.mastercard.com/mastercard-processing-core/documentation/sandbox-testing/card-lifecycle-management/renew-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`