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, follow 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>.

## Reissue for card expiry

The most common use case for reissuing a card is <a href="doc:setting-up-a-card-program#card-expires" target="_blank">card expiry</a>.

### Automated reissue

Before a card reaches its expiry date, you can arrange for Galileo to automatically reissue and ship a new card to ensure that the cardholder does not have any disruption in their purchasing ability. Typically, cards that are within 30 calendar days of the expiry date are reissued, but you can change that interval. As soon as the reissued card is activated, the original card is set to `status: C`.

Galileo's automated reissue process verifies that the following are true before reissuing a card:

  • Account is active (`status: N`).

  • Card is in `status: Y` or `status: N` or in a status specified in RISCS (if set).

  • The expiry date is within the specified number of days (DAYSOUT) from the current date.

  • The following product parameters have these settings:

    • RIXCL is not `Y` (when RIXCL is `Y`, automatic reissue is blocked).

    • Account balance is greater than 0.00, or RIZBL is set to allow reissue regardless of balance.

    • The card has made at least one transaction within the period specified by MDSLU, if set.

  • Card has not already been reissued during the DAYSOUT period.

### Manual reissue

If you would rather reissue expiring cards yourself, follow the instructions in [Use case 1: Reissue card with same PAN and new expiry](🔗). You can arrange with Galileo to send you the <a href="ref:api-reference-events-api-card-expiring" target="_blank">`RBEX: card_expiring`</a> event message to notify you that a card is expiring. When you set up this event, you specify how many days before the expiry date the event message is sent and how many times the event is sent. The event message can be sent once per card, or you can specify that the event be sent daily, weekly, or any other interval.

For example, if a card's expiry date is 8/25, you could specify that the `RBEX: card_expiring` event be sent on 15 Aug 2025 (15 days out) and then again on 29 Aug 2025, or you could specify that the event be sent only once, 30 days out.

### Virtual card expiry

In the case of an expiring virtual card, ask Galileo to send you the <a href="ref:api-reference-events-api-card-expiring" target="_blank">`RBEX: card_expiring`</a> event message to notify you that a card is expiring. When you receive the message, use <a href="ref:post_addcard" target="_blank">Add Card</a> to create the replacement virtual card. A virtual card cannot be reissued, and so a net-new card with a new PAN, CVV, and expiry is generated.

## How to reissue or replace

Galileo provides two methods to manually 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`. Galileo recommends the Reissue Card endpoint, because it provides granular control per reissue.

## 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.

Note

When reissuing a Digital First card, the card is not automatically activated. See <a href="doc:setup-for-digital-first#reissuing-digital-first-cards" target="_blank">Reissuing Digital First cards</a> in the _Setup for Digital First_ guide for details.

### Card reissue parameters

These program parameters are related to card-activation behavior when using the Reissue Card endpoint.

ParameterDescription
CANCSUsed in conjunction with CANOC, it specifies the status that a card must be in to be canceled when a new card is activated. Default: `N,X,Y,W`
CANOCWhen this parameter is set and the new card (new PAN) is activated, other cards in the statuses specified in CANCS and belonging to the same cardholder are canceled (`status: C`):<br><br><li>`Y` — Cancel all cards regardless of `prod_id`.<li>`Prod` — Cancel only the cards with the same `prod_id`.<br><br>When this parameter is not set, other active cards are not canceled. If you set `oldCardStatus` to `C` or `D`, this parameter is not checked.

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.

ParameterDescription
`accountNo`The PRN, PAN or CAD of the card to reissue. If more than one card is associated with the PRN, use the PAN or CAD.
`newPan`Pass `Y` to generate a new PAN for the card. When this parameter is `Y` then `newExpiryDate: Y` is required. Default: `N`
`newExpiryDate`Pass `Y` to generate a new expiry date for the new card. Always set this parameter to `Y`, because otherwise it leaves the reissued card unprotected in transit. Default: `N`
`emboss`Pass `Y` to send the reissued card to the embosser. The `N` value is not currently supported, because virtual cards cannot be reissued. Default: `Y`
`oldCardStatus`Specify the status for the card that is being replaced. This parameter is valid only when `newPan Y`. The status is applied by the emboss process, shortly after reissue. Use `D` for disabled or `C` for canceled. Leave blank for the old card to be usable until the new card is activated. Default: Blank

#### Valid parameter combinations

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

Use case`newPan``newExpiryDate``emboss``oldCardStatus`
[1: Reissue](🔗)`N``Y``Y`Blank
[2: Replace](🔗)`Y``Y``Y``C`, `D` or blank

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, according to your setup. See <a href="doc:setting-up-a-card-program#card-activation" target="_blank">Card activation</a> in _Setting Up a Card Program_ for information about activation options.

  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. In this case, you have not set up a reissue fee (REI). 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.