Switching Products with Set Account Feature

This guide contains instructions for changing the product ID of an account to another product ID—and optionally reissuing the card—with the Set Account Feature endpoint. This guide also contains instructions for setting the reissue-related product parameters.

Use this method when:

• You need to switch a savings account to another savings product.
• You are an established Galileo client, and you are already set up for switching products in this manner.
• You want to use batch processing to switch products, and you need to set the parameters to control card reissue.
• You do not want to reissue a card with a new PAN.

Do not use this method to switch products when:

• You want to control reissue behavior on a per-switch basis; instead, use the Switch Product endpoint. See Switching Products for instructions.
• You want to issue a net-new card (new PAN and expiry) with a product switch; instead, use the Switch Product endpoint, as above.
• The old and new products have different BINs; instead, see the Switching Products with Different BINs guide.

When using the Set Account Feature endpoint to switch a product, you have the option of reissuing a card with the product switch, as long as you have set product parameters correctly. With this method you can determine whether to generate a new expiry date with the reissue, but the PAN will remain the same in all cases.

Because the reissue behavior is controlled by product parameters, the behavior happens every time product A is switched to product B with Set Account Feature—it cannot be customized on a per-switch basis.

📘

Note

Before using this product-switch method, review Prerequisites for switching products in the Switching Products guide.

Use cases

You can skip directly to the use cases below or you can continue reading to see how to use Set Account Feature with featureType: 3.

• Use case 1: Virtual to physical card with same expiry — Account switches from a virtual card product to a physical card product. The virtual card is reissued as a physical card with the same expiry.
• Use case 2: Product switch for physical cards with new expiry — Account switches from a physical card product to another physical card product. The card is reissued with a new expiry.
• Use cases 3 and 3a: Product switch between products with and without new expiry — Accounts switch between two products. When switching from the first product to the second, the card is not reissued, but when switching from the second product to the first, the card is reissued with a new expiry.
• Use case 4: Product switch without reissue — When switching from one product to another the card is never reissued.

Result of calling Set Account Feature

When Set Account Feature with featureType: 3 has been successfully called, the following are true:

• The account has a new product ID.
• If product parameters specify that the card be reissued, the card is flagged for reissue with either a new expiry date or the same expiry date. (A new card record with a new CAD is not created because a new PAN is not generated.)
• If product parameters specify that the card have a new expiry date, the card is flagged for a new expiry and CVV.
• If a reissue fee (REI) is configured, the fee is assessed.

Because the new expiry date and CVV are generated by the emboss process, they are not returned in the Set Account Feature response.

According to your arrangements with Galileo, Galileo sends event webhooks to notify when the product switches, 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.

Product-switch reissue product parameters

These product parameters control card-reissue and card activation behavior in the context of a product switch that is made using Set Account Feature with featureType: 3.

📘

Note

When product-switching in the CST, STOCK and NOISS may also be consulted, depending on your arrangements with Galileo.

Product switch with reissue decision tree

This process first determines whether there should be a reissue, then determines whether the expiry should be the same or new.

1. You send the Set Account Feature call with these values:
   • featureType — 3
   • featureValue — New product ID
2. Galileo compares the STOCK values for the old and new products.
   • If the values match, the reissue process is not triggered.
   • If the values do not match or are not set on both products, NOISS for the new product is compared with STOCK for the old product.
   • If the old STOCK is present in the new NOISS, the reissue process is not triggered.
   • If the old STOCK is not present, Galileo consults the NNEXP value for the new product.
     • Y — The card is reissued with the same expiry as the old card.
     • N — The card is reissued with a new expiry.
     • M — Galileo compares the OTNXP value for the new product with the product otype of the old product.
       • If the old otype is present, the card flagged for reissue with the same expiry as the old card.
       • If the old otype is not present, the card is flagged for reissue with a new expiry.
3. Galileo switches the account to the new product.

After the endpoint response

If the old card is virtual and the new card is physical, and the physical card has the same PAN and expiry date as the virtual card, you must protect the physical card while it is in transit. After getting the response to Set Account Feature, call it again with these values, according to your use case. Both of these options permit mobile-wallet and AVS transactions:

• accountNo — PAN or CAD (do not use PRN)
• Block card-present and card-not-present transactions:
  • featureType: 20
  • featureValue: Y
• Block card-present transactions only:
  • featureType: 21
  • featureValue: Y

📘

Note

If both the old card and the new card are physical, and the expiry is the same, setting account feature 20 or 21 will also affect the old card. Galileo strongly recommends that you set a new expiry date when both old and new cards are physical.

These steps happen when the product parameters are configured to reissue the card:

1. The emboss process:
   • Generates a new expiry date and new CVV.
   • Creates a new emboss record in status Y.
   • Includes the card entry in a batch file to send to the embosser.
   • Sends the SHIP: card_shipped event webhook.
   • If the reissue (REI) fees is configured:
   • Assesses the reissue fee.
   • Sends the BFEE: fee event message.
2. The embosser 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. Galileo sends the BACT: card_activated event webhook.
5. If the new card has a new expiry, then the old card is deactivated.
6. Because the card does not have a new PAN, the PIN does not need to be reset.

📘

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 Set Account Feature endpoint reference to see how to build the API request and to see the response schema.

View the new product ID

The Set Account Feature endpoint returns the new product ID in the feature_value field. You can also retrieve the new prod_id with the Get Account Cards or Get Card endpoint.

View the new card information

Because the emboss process generates new PANs, CADs, expiry dates and CVVs after the Set Account Feature endpoint is called, the Set Account Feature endpoint cannot return that data. After you receive the SHIP: card_shipped event webhook, you can retrieve the new information using Get Account Cards or Get Card. You can see the new PAN, CVV and expiry only if you are PCI compliant.

Set Account Feature status codes

These status codes are related to endpoint calls with featureType: 3. See the Set Account Feature endpoint reference for all status codes.

Use case 1: Virtual to physical card with same PAN and expiry

If you want to offer a virtual version of a card that cardholders can use until the physical version of the card is shipped, use Digital First cards instead.

In use case 1, the cardholder signs up for card A, a product with a physical card; however, the card stock for that card is on backorder and cannot be immediately issued. Instead, you issue a product that is a virtual version of card A, card A1, which the cardholder can use until the stock for card A becomes available.

When the stock becomes available, you switch the account to card A, and the embosser sends card A with the same PAN, expiry date and CVV as card A1.

📘

Note

You can use this same setup any time an existing virtual card customer wants to upgrade to physical.

Use case 1 setup

For use case 1, the product parameters should be set up so that the following are true:

• The STOCK values do not match.
• NOISS for card A does not contain STOCK for card A1.
• The NNEXP value for card A is M.
• The product otype for card A1 is present in OTNXP for card A.

Use case 1 example values

Use case 1 process

1. The cardholder signs up for card A (prod_id: 3333).
2. Your logic specifies that when cardstock for prod_id: 3333 is unavailable, a card A1 account (prod_id: 5555) is created, which issues a virtual card to the cardholder.
3. The embosser later notifies you that card A stock is available.
4. You call Set Account Feature with these parameters:
   • featureType: 3
   • featureValue: 3333
5. Galileo performs the following checks:
   • Do the STOCK values match? — No
   • Is the STOCK value of prod_id: 5555 present in the NOISS value of prod_id: 3333? — No
   • What is the NNEXP value of prod_id: 3333? — M
   • Is the otype of prod_id: 5555 present in the OTNXP value of prod_id: 3333? — Yes
6. Galileo changes the prod_id to 3333 and sends the PSWC: prod_switch event webhook.
7. Because the physical card has the same PAN, expiry date and CVV as the virtual card, you must protect the physical card while it is in transit. Right after calling Set Account Feature the first time, call it again with these values, according to your use case. Both of these options permit mobile-wallet and AVS transactions:
   • accountNo — PAN or CAD of card
   • Block card-present and card-not-present transactions:
   • featureType: 20
   • featureValue: Y
   • Block card-present transactions only:
   • featureType: 21
   • featureValue: Y
8. Galileo's emboss process:
   • Creates an emboss record for prod_id: 5555 in status: Y.
   • Retains the PAN and expiry from prod_id: 3333.
   • Includes the emboss record in the batch file for the embosser, changes the card status to Y, and sends the SHIP: card_shipped event webhook.
9. The cardholder receives card A in the mail and activates it.
10. When you receive notification that the card is activated (BACT: card_activated event webhook), call Set Account Feature again to remove the block.

Use case 2: Product switch for physical cards with new expiry

The cardholder already has card C (physical card) but wants to upgrade to card D (physical card), because card D has more desirable terms. The cardholder requests the upgrade, and the embosser mails card D with the same PAN as card C but with a new expiry date. When the cardholder activates card D, card C becomes inactive.

Use case 2 setup

For use case 2, the product parameters should be set up so that the following are true:

• The STOCK values do not match.
• NOISS for card D does not contain STOCK for card C.
• The NNEXP value for card D is M.
• The OTNXP value for card D does not contain the otype for card C.

Use case 2 example values

Use case 2 process

1. The cardholder signs up for card C (prod_id: 2222) and is issued card C.
2. Later, the cardholder requests an upgrade to card D (prod_id: 4444).
3. You call Set Account Feature with these parameters:
   • featureType: 3
   • featureValue: 4444
4. Galileo performs the following checks:
   • Do the STOCK values match? — No
   • Is the STOCK value of prod_id: 2222 present in the NOISS value of prod_id: 4444? — No
   • What is the NNEXP value of prod_id: 4444? — M
   • Is the otype of prod_id: 2222 present in the OTNXP value of prod_id: 4444? — No
5. Galileo changes the prod_id to 4444 and sends the PSWC: prod_switch event webhook.
6. Galileo's emboss process:
   • Creates an emboss record for prod_id: 4444 in status: Y.
   • Retains the PAN from prod_id: 2222.
   • Includes the emboss record in the batch file for the embosser, changes the card status to Y, and sends the SHIP: card_shipped event webhook.
7. Because the expiry date is new, you do not need to protect the card in transit.
8. The cardholder receives card D in the mail and activates it.
9. You receive notification that the card is activated: BACT: card_activated event webhook.

Use cases 3 and 3a: Product switch between products with and without new expiry

In these two scenarios switching from card E to card G results in different behavior than switching from card G to card E. When switching from card E to card G the card is not reissued, but when switching from card G to card E the card is reissued with a new expiry.

Use case 3

In use case 3, the cardholder has card E and wants to change to card G. The cardholder requests the change and the account is switched to the new product. The card is not reissued—the cardholder continues to use the same card as before.

Use case 3 setup

For use case 3, the product parameters should be set up so that the following are true:

• The STOCK values do not match.
• NOISS for card G contains STOCK for card E.

Use cases 3 and 3a example values

Use case 3 process

1. The cardholder signs up for card E (prod_id: 7777) and is issued card E.
2. Later, the cardholder requests to change to card G (prod_id: 9999).
3. You call Set Account Feature with these parameters:
   • featureType: 3
   • featureValue: 9999
4. Galileo performs the following checks:
   • Do the STOCK values match? — No
   • Is the STOCK value of prod_id: 7777 present in the NOISS value of prod_id: 9999? — Yes
5. Galileo changes the prod_id to 9999 and sends the PSWC: prod_switch event webhook.
6. Galileo's emboss process does not send a card order to the embosser.

Use case 3a

The cardholder has card G and wants to change to card E. The cardholder requests the change, the account is switched to the new product, and the card is reissued with a new expiry.

Use case 3a setup

For use case 3a, the product parameters should be set up so that the following are true:

• The STOCK values do not match.
• NOISS for card E does not contain STOCK for card G.
• The NNEXP value for card E is N.

Use case 3a process

1. The cardholder signs up for card G (prod_id: 9999) and is issued card G.
2. Later, the cardholder requests to change to card E (prod_id: 7777).
3. You call Set Account Feature with these parameters:
   • featureType: 3
   • featureValue: 7777
4. Galileo performs the following checks:
   • Do the STOCK values match? — No
   • Is the STOCK value of prod_id: 9999 present in the NOISS value of prod_id: 7777? — No
   • What is the NNEXP value of prod_id: 7777? — N
5. Galileo changes the prod_id to 7777 and sends the PSWC: prod_switch event webhook.
6. Galileo's emboss process:
   • Creates an emboss record for prod_id: 7777 in status: Y.
   • Retains the PAN from prod_id: 9999.
   • Includes the emboss record in the batch file for the embosser, changes the card status to Y, and sends the SHIP: card_shipped event webhook.
7. Because the expiry date is new, you do not need to protect the card in transit.
8. The cardholder receives card E in the mail and activates it.
9. You receive notification that the card is activated: BACT: card_activated event webhook.

Use case 4: Product switch without reissue

You offer three cards to your customers: card H, card J and card K. When a cardholder changes from any of these products to any other, the card is not reissued.

Use case 4 setup

For use case 4, the product parameters should be set up so that the following is true:

• All STOCK values match

Use case 4 example values

Use case 4 process

1. The cardholder signs up for card H (prod_id: 1111) and is issued card H.
2. Later, the cardholder requests to change to card J (prod_id: 6666).
3. You call Set Account Feature with these parameters:
   • featureType: 3
   • featureValue: 6666
4. Galileo performs the following checks:
   • Do the STOCK values match? — Yes
5. Galileo changes the prod_id to 6666 and sends the PSWC: prod_switch event webhook.
6. Galileo's emboss process does not send a card order to the embosser.

---