This guide describes developer implementation for the Digital First product. For general information, see Digital First cards in the Choose a Card Strategy guide.
You must provide a digital card template to Galileo, as shown in the Design a Card guide:
- For cards that are provisioned to mobile wallets, see Tokenized card design.
- For other cards, see Digital card design.
For new customers, use the Create Account endpoint. For existing customers, use the Add Account endpoint.
The sequence of events for card creation is slightly different for Digital First cards than for conventional cards. You must also arrange with Galileo to receive the event webhooks:
- You call Create Account or Add Account.
- Galileo creates the account and card records.
- Because the card is active upon creation, Galileo sends the
BACT: card_activatedevent webhook.
- The emboss process places an emboss record in a file to send to the embosser. This process runs once per day.
- When the emboss record is placed in the file, Galileo sends the
SHIP: card_shippedevent webhook.
When using the Create Account endpoint for a Digital First product, the
CAPP: app_completedevent webhook is not sent.
Because the card is in an active state upon creation, there is a risk of the physical card being intercepted and used while in transit to the cardholder. To prevent the physical card from being used before it reaches the cardholder, set a block when the account is created, and then when the cardholder sets the PIN for the physical card, remove the block. (This type of block does not prevent the account from receiving deposits.)
At the time of account creation, call the Set Account Feature endpoint. According to your use case, choose one of two types of block:
- If you do not provide your cardholders with the PAN immediately, set Feature 20 so that the physical card cannot be used online or at physical points of sale. However, push-provisioning a card to a mobile wallet and mobile wallet transactions are permitted, as well as card loads.
- If you provide the PAN to your cardholders to use immediately, set Feature 21, which prevents the physical card from being used at physical points of sale but does not block card loads. This setting permits card-not-present and mobile wallet transactions.
Account Features 20 and 21 are mutually exclusive—only one can be set to
Yat a time.
Your next steps depend on how the PIN was set:
- If your cardholders use the IVR to set the PIN, Feature 20 or 21 will be automatically set to
N, and you will receive the
PINC: PIN_changed event. Your IVR process must specifically be configured for Digital First for this automation to work.
- If your cardholders use another method besides the IVR to set the PIN, you will receive notification of the PIN set through the Account Events webhook, by arrangement with Galileo. When you receive notification that the PIN has been set, call the Set Account Feature endpoint again with these parameters, depending on which one you set previously:
Choose one of these options:
- To provision the digital card to a mobile wallet, follow the Setup for Mobile Wallets guide.
- To retrieve a digital image of the physical card, see Digital card image procedure in the Retrieving Card Information guide.
With cards in the Digital First program, the lost/stolen process is the same as with other cards, with one variation—the physical replacement card is activated at the same time it is created, and then it is sent to the embosser. The digital version of the card is created at the same time, which can be used until the physical card arrives. When the lost or stolen card is in a mobile wallet, the replacement card is not automatically updated in the wallet—the cardholder must input it manually or you can push-provision it.
See the Lost, Stolen, or Damaged Cards guide for the default lost/stolen processes.
When you report a physical card as lost or stolen, call the Set Account Feature endpoint and set feature 20 or 21, as you did at the time of account creation. When the cardholder sets the PIN for the physical card, remove the block.
If a cardholder reports a mobile wallet as lost or stolen, you can call Set Account Feature to set feature 22 to
Y, which blocks all mobile wallet transactions but permits card-present and card-not-present transactions.
When a cardholder reports the physical card as damaged, you can reissue the card using the same reissue process as for other card types:
A reissued Digital First card is not activated upon creation, and so there is no need to set account features to protect the reissued card in transit. No digital version of the reissued card is created, because the existing card is usable in mobile wallets and online until the reissued card is activated. See Activating a Card for more information.
When a Digital First card is about to expire, Galileo automatically reissues the card. The number of days before expiration is configurable, with a default of 30 days. There is no need to protect the physical card while in transit and no digital version of the card is created.
These internal product parameters must be set at Galileo.
|FEMBO||Y||Forces cards to be embossed regardless of card status after account creation.|
|CHITR||Y||Set when the Digital First card is to be provisioned to a mobile wallet.|
|NNEXP||Y||Prevents a new expiration date from being generated by the card-emboss process, so that the digital and physical cards have the same expiry.|
|XAACT||YNN||Activates both the card and the account immediately after calling the Create Account endpoint. Bypasses the standard account/card setup processes to create a digital card that is active and ready to use immediately.|
Updated 21 days ago