Reissuing Cards

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 Digital First cards for new products or the Switching Products 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 Add Card to create a replacement virtual card.
• A card has been reported lost or stolen; instead, follow the Lost, Stolen, or Damaged Cards guide.
• The reissue is the result of the account switching from one product ID to another product ID; instead, use the Switching Products 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 PRN, PAN, and CAD stay the same, but a new emboss record with a new expiry date and 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 Lost, Stolen, or Damaged Cards guide instead of the replacement methods described in this guide.

📘

Note

Virtual cards cannot be reissued; instead, you must replace them by using Add Card.

Reissue for card expiry

The most common use case for reissuing a card is card expiry.

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 RBEX: card_expiring 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 RBEX: card_expiring event message to notify you that a card is expiring. When you receive the message, use Add Card 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 Reissue Card endpoint and using the Modify Status 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 Reissuing Digital First cards 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.

📘

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 Reissue Card 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 Reissue Card 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 Production for most clients and every 15 minutes in 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 SHIP: card_shipped 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 BFEE: fee 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 Card activation in Setting Up a Card Program for information about activation options.
4. You receive notification that the card has been activated (BACT: card_activated 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 Modify Status with these parameters:
   • accountNo: CAD or PAN of old card; do not use PRN
   • type: 5

📘

Note

A reissue is represented in the CST on the Card Info screen under Reissued Card History and Emboss History.

Sample endpoint request and response

Consult the Reissue Card 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 SHIP: card_shippedSHIP: card_shipped event webhook, you can retrieve the new information using Get Account Cards or Get Card. 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 SHIP: card_shipped event webhook, you can call Get Account Cards or Get Card 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 Reissue Card 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 SHIP: card_shipped event webhook.
3. The embosser mails the cards to the cardholders, who activate them. Galileo sends the BACT: card_activated 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 Reissue Card 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 SHIP: card_shipped event webhook.
   • If oldCardStatus is populated, change the old card status to C or D.
   • Assesses the 5.00 reissue fee and sends the BFEE: fee event message.
3. The embosser mails the card to the cardholder, who activates it. Galileo sends the BACT: card_activated 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 Modify Status with these parameters:
   • accountNo: CAD or PAN of old card; do not use PRN
   • type: 5

Status codes

Consult the Reissue Card endpoint to see status codes and next steps.