After initially issuing a card to a customer, you might need to manually reissue them a new card.

### When to reissue

You reissue a card in circumstances such as these:

• A physical card has been reported damaged, and you want to send a new card to the cardholder.

• Your product settings do not automatically reissue expiring cards, so you want to reissue manually.

• You want to reissue or replace a card with the same product ID for other reasons.

### When not to reissue

In some similar cases, reissuing a card is not the right course of action, for example, when:

• You want to reissue a virtual card as a physical card; instead, use <a href="doc:choose-a-card-strategy#digital-first-cards" target="_blank">Digital First cards</a> for new products or the <a href="doc:switching-products" target="_blank">Switching Products</a> guide for existing virtual cards.

• A physical card is about to expire and product settings specify automatic reissue; instead, allow the automatic process to run.

• You want to reissue a virtual-only card that is about to expire; instead, use <a href="ref:post_addcard" target="_blank">Add Card</a> to create a replacement virtual card.

• A card has been reported lost or stolen; instead, use the <a href="doc:lost-stolen-or-damaged-cards" target="_blank">Lost, Stolen, or Damaged Cards</a> guide.

• The reissue is the result of the account switching from one product ID to another product ID; instead, use the <a href="doc:switching-products" target="_blank">Switching Products</a> guide.

## Reissuing vs. replacing

When you reissue a card, you can specify whether to reissue or replace it:

• To _reissue_ a card is to make a new version of the card that is associated with the original card account.

  • The <<glossary:PRN>>, <<glossary:PAN>>, and <<glossary:CAD>> stay the same, but a new emboss record with a new expiry date and <<glossary:CVV>> are created.

  • If you have configured a reissue fee (REI), that fee is applied.

  • Performed when a card is about to expire or when a card is reported damaged.

• To _replace_ a card is to issue a net-new card.

  • A new card record is created with the same PRN but a new PAN, CAD, expiry, and CVV.

  • If you have configured a replacement fee (REP), that fee may be applied, depending on which reissue method you use.

  • Performed for lost or stolen cards or other times when providing a net-new card for the same product is desired. For lost or stolen cards use the <a href="doc:lost-stolen-or-damaged-cards" target="_blank">Lost, Stolen, or Damaged Cards</a> guide instead of the replacement methods described in this guide.

📘

Note

Virtual cards cannot be reissued; instead, you must replace them by using <a href="ref:post_addcard" target="_blank">Add Card</a>.

## How to reissue or replace

Galileo provides two methods to reissue and replace cards: using the <a href="ref:post_reissuecard" target="_blank">Reissue Card</a> endpoint and using the <a href="ref:post_modifystatus" target="_blank">Modify Status</a> endpoint with `type: 12`.

## Using the Reissue Card endpoint

This section explains how to use the Reissue Card endpoint to reissue or replace cards.

### Result of calling Reissue Card

When Reissue Card has been called successfully, the reissue process is initiated. Depending on how the endpoint parameters are set, the card is set to be embossed with either a new PAN and expiry or the old PAN and new expiry.

• When the PAN is new, a new card record is created with a new CAD, and a new emboss record is created with a new expiry date and CVV.

• When the PAN is not new, a new emboss record is created with a new expiry date and CVV.

• Because new PANs and expiries are generated by subsequent backend processes, the new PAN and expiry are not available in the response to this endpoint call.

According to your arrangements with Galileo, Galileo sends event webhooks to notify when the emboss record is created, when the fee is assessed and when the card is activated. There is no event webhook for card reissue or replacement.

### Card reissue product parameters

This product parameter affects card-reissue and replacement behavior when using the Reissue Card endpoint.

📘

Note

The Reissue Card endpoint does not check the RISCS parameter, which controls which card statuses are eligible for reissue when using Modify Status to reissue cards.

### Endpoint parameters

This table explains the parameters that are specific to the Reissue Card endpoint. See the <a href="ref:post_reissuecard" target="_blank">Reissue Card</a> endpoint reference for details.

#### Valid parameter combinations

Only these parameter combinations are valid. See [Use cases](🔗) for instructions on using these combinations.

🚧

Warning

If you set both `newPan` and `newExpiryDate` to `N`, you create an identical copy of the current card. When such a card is mailed to the cardholder, it is active and therefore vulnerable to interception. If you were to set account feature 20 or 21, you would also disable the old card. For this reason, Galileo strongly recommends that you always set `newExpiryDate: Y`.

## Reissue Card workflow

1. Populate the <a href="ref:post_reissuecard" target="_blank">Reissue Card</a> endpoint and send.

2. Galileo performs these checks:

   • If the card is virtual, the endpoint returns `status_code: 589-01`.

   • If there are pending reissue records for this card, the endpoint returns `status_code: 589-09`.

   • If you try to reissue a card that is in status `L` or `S`, the endpoint returns `status_code: 589-12`.

   • If there is a reissue fee, Galileo checks the available balance. If there are insufficient funds, the endpoint returns `status_code: 589-07`.

     • Galileo attempts to process the reissue fee. If processing the fee is unsuccessful, the endpoint returns `status_code: 589-08`.

   • Galileo attempts to retrieve the data associated with the account and card. If it is unsuccessful, the endpoint returns `status_code: 589-05` or `status_code: 589-06`.

3. Galileo checks the value of `newPan`:

   • `Y` — Galileo checks the value of `newExpiryDate`:

     • `Y` — Galileo sets a flag for a new PAN for a net-new card.

     • `N` — The endpoint returns `status_code: 590-11`

   • `N` — Galileo assigns the old PAN to the reissued card.

4. Galileo checks the value of `newExpiryDate`:

   • `Y` — Galileo sets a flag for a new expiry date for the reissued card.

   • `N` — This value is not recommended.

5. Galileo checks the value of `oldCardStatus`.

   • `C` or `D` — Galileo checks the value of `newPan`:

     • `Y` — Galileo sets a flag for the old card status to change

     • `N` — The endpoint returns `status_code: 590-04`

   • Blank — The old card is not flagged for a status change.

6. If the card-reissue process fails, the endpoint returns `status_code: 589-10`; otherwise, the endpoint returns `status_code: 0`.

📘

Note

The `expiry_date` and `card_security_code` (CVV) that are returned by the endpoint are not the new values. The new values are generated later by the emboss process, as shown in the next section.

### After the endpoint response

These steps happen after the endpoint call is successful. The emboss process runs once per day in <<glossary:Production>> for most clients and every 15 minutes in <<glossary:CV>>.

1. The emboss process:

   • Generates a new card record with a new CAD and PAN if `newPan: Y`.

   • Generates a new expiry date and CVV.

   • Generates a new emboss record in `status: Y`.

   • Includes the emboss record in a batch file to send to the embosser.

   • Sends the <a href="ref:api-reference-events-api-card-shipped" target="_blank">`SHIP: card_shipped`</a> event webhook.

   • If `newPan: Y` and `oldCardStatus` is `C` or `D`, changes the old card to that status.

   • If applicable, assesses the reissue (REI) fee and sends the <a href="ref:api-reference-events-api-fee" target="_blank">`BFEE: fee`</a> event message.

2. The emboss vendor creates the card and mails it to the cardholder.

3. The cardholder activates the new card in one of these ways, according to your setup:

   • IVR (automated phone system)

   • <a href="ref:post_activatecard" target="_blank">Activate Card</a> endpoint

   • <<glossary:CST>>

4. You receive notification that the card has been activated (<a href="ref:api-reference-events-api-card-activated" target="_blank">`BACT: card_activated`</a> event webhook).

5. If the card has a new PAN, then the PIN must also be reset using your preferred method.

6. If `newPan: Y` and `oldCardStaus` was blank and CANOC is not `Y`, then the old card is still active. Perform this step:

   • Call <a href="ref:post_modifystatus" target="_blank">Modify Status</a> with these parameters:

     • `accountNo: ` CAD or PAN of old card; do not use PRN

     • `type: 5`

📘

Note

A reissue is represented in the <<glossary:CST>> on the _Card Info_ screen under **Reissued Card History** and **Emboss History**.

### Sample endpoint request and response

Consult the <a href="ref:post_reissuecard" target="_blank">Reissue Card</a> endpoint reference to see how to build the API request and to see the response schema.

Because the emboss process generates new PANs, CADs, expiry dates and CVVs after the Reissue Card endpoint is called, the Reissue Card endpoint cannot return that data. After you receive the <a href="ref:api-reference-events-api-card-shipped" target="_blank">`SHIP: card_shipped`</a>`SHIP: card_shipped`</a> event webhook, you can retrieve the new information using <a href="ref:post_getaccountcards" target="_blank">Get Account Cards</a> or <a href="ref:post_getcard" target="_blank">Get Card</a>. You can receive the new PAN, CVV and expiry only if you are PCI compliant.

#### View the reissued card

Because the emboss process generates new PANs and expiry dates, the Reissue Card endpoint does not return the new PAN and expiry. When you receive the <a href="ref:api-reference-events-api-card-shipped" target="_blank">`SHIP: card_shipped`</a> event webhook, you can call <a href="ref:post_getaccountcards" target="_blank">Get Account Cards</a> or <a href="ref:post_getcard" target="_blank">Get Card</a> to see the new card information.

## Use cases

Use the Reissue Card endpoint for these use cases:

• [Use case 1: Reissue card with same PAN and new expiry](🔗)

• [Use case 2: Replace card with new PAN and expiry](🔗)

### Use case 1: Reissue card with same PAN and new expiry

Your product settings do not reissue cards automatically when they are about to expire, so you reissue them manually. There is no reissue fee. The old card is usable until the new card is activated, and then it is disabled.

1. You call <a href="ref:post_reissuecard" target="_blank">Reissue Card</a> with these parameters:

   • `newPan: N`

   • `newExpiryDate: Y`

   • `emboss: Y`

   • `oldCardStatus:` blank

2. The emboss process:

   • Generates a new expiry date and CVV.

   • Creates a new emboss record in `status: Y`.

   • Adds the emboss record to the batch file to send to the embosser.

   • Sends the <a href="ref:api-reference-events-api-card-shipped" target="_blank">`SHIP: card_shipped`</a> event webhook.

3. The embosser mails the cards to the cardholders, who activate them. Galileo sends the <a href="ref:api-reference-events-api-card-activated" target="_blank">`BACT: card_activated`</a> event webhook.

4. Because the card has the same PAN, the PIN does not need to be reset.

5. The old card is deactivated.

### Use case 2: Replace card with new PAN and expiry

The cardholder wants a new card with a new PAN for the same product and account. You charge a $5.00 reissue (REI) fee. (To charge a replacement [REP] fee instead, use the Modify Status endpoint with `type: 19`.)

This scenario has two methods for canceling the old card, depending on the timing that you desire:

• **Cancel shortly after reissuing the card** — Set `oldCardStatus` to `C` or `D`.

• **Cancel when the new card is activated** — Leave `oldCardStatus` blank.

1. You call <a href="ref:post_reissuecard" target="_blank">Reissue Card</a> with these parameters:

   • `newPan: Y`

   • `newExpiryDate: Y`

   • `emboss: Y`

   • `oldCardStatus: C`, `D` or blank

2. The emboss process:

   • Creates a new card record with a new PAN and CAD.

   • Creates a new emboss record in `status: Y` with new expiry date and CVV.

   • Adds the card to a batch file to send to the embosser.

   • Sends the <a href="ref:api-reference-events-api-card-shipped" target="_blank">`SHIP: card_shipped`</a> event webhook.

   • If `oldCardStatus` is populated, change the old card status to `C` or `D`.

   • Assesses the 5.00 reissue fee and sends the <a href="ref:api-reference-events-api-fee" target="_blank">`BFEE: fee`</a> event message.

3. The embosser mails the card to the cardholder, who activates it. Galileo sends the <a href="ref:api-reference-events-api-card-activated" target="_blank">`BACT: card_activated`</a> event webhook.

4. Because the card has a new PAN, the PIN must also be reset, using your preferred method.

5. If you left `oldCardStatus` blank and CANOC is not set, then the old card is still active. Perform these steps to set the old card status to `C` (canceled):

   • Call <a href="ref:post_modifystatus" target="_blank">Modify Status</a> with these parameters:

     • `accountNo: ` CAD or PAN of old card; do not use PRN

     • `type: 5`

## Status codes

Consult the <a href="ref:post_reissuecard" target="_blank">Reissue Card</a> endpoint to see status codes and next steps.