Offline PIN

A personal identification number is an anti-fraud measure that helps authenticate a cardholder at physical points of sale and ATMs. PIN validation requires the cardholder to input the PIN on a card reader's PIN pad, and the card reader compares the input with the PIN that was set for the card. When the PINs match, the cardholder is assumed to be the authorized user, and the transaction can continue from there.

Card readers can compare the input PIN to the card's PIN in one of two ways:

• Online PIN — The card reader passes the PIN to the issuer in the authorization request, and the issuer validates the PIN.
• Offline PIN — The PIN is encoded in the embedded EMV chip. The card reader compares the PIN that the cardholder inputs with the PIN encoded on the EMV chip. If the PIN matches, the card reader sends the validation results to the issuer in the authorization request.

The offline PIN method was developed for two primary reasons:

• In some areas, card readers are attached to networks with intermittent connectivity, or they are not connected to a network at all.
• A PIN that is sent over the card network risks being intercepted. Validating the PIN on the chip reduces that risk.

In the U.S. and Colombia, the online method is preferred, whereas in Canada and the rest of Latin America the offline method is preferred. If you are located outside of the U.S., or if you want to expand your business outside the U.S., you will probably need to implement offline PINs, depending on the regulations in each jurisdiction. Galileo can help you determine which regions require offline PINs.

Initial PIN setting

You can initially set an offline PIN using one of two methods:

• Write the PIN to the chip when the card is embossed.
• Run a script to write the PIN to the chip during the first transaction after emboss.

Write the PIN at emboss

For this method, Galileo sends an encrypted PIN in the emboss file that is sent to the embosser with the card production information. The embosser decrypts the PIN and writes the PIN on the EMV chip. This PIN can be either a random PIN that Galileo generates or it can be a PIN provided by the cardholder during the account-creation process. This method requires development work between Galileo and the emboss vendor, as well as a mechanism for the cardholder to securely obtain the PIN that is agreeable to the sponsoring bank, such as the PIN Retrieval Service (PRS), the welcome packet, or a separate letter.

Write the PIN using a script

For this method, the cardholder does not set the PIN prior to embossing. The embosser writes a random PIN on the chip, so when the cardholder attempts to use the card for the first time, the attempt fails because the cardholder does not know the correct PIN. Galileo recommends that the card holder be instructed to first go to an ATM and set their PIN as soon as they receive their card. If they do not, at the point of sale, after three failed attempts the card reader goes online to contact Galileo, and Galileo runs a script that writes a PIN to the chip. The transaction is attempted again and it is approved. The cardholder can retrieve the PIN to use in future transactions with the PIN Retrieval Service.

Changing the PIN

The cardholder changes the PIN using the direct render or direct POST PIN-set procedure, and Galileo stores the changed PIN until the next time the cardholder attempts to make a transaction. When the card reader attempts to validate the PIN on the chip, it fails because the new PIN that the user inputs is not the same as the PIN on the chip. After the transaction fails three times, the card reader contacts Galileo, and Galileo runs a script that writes the new PIN to the chip. The transaction is then approved.

Resetting the PIN-try count

For each card product, you specify how many times a cardholder can input an erroneous PIN before the PIN locks, and then the card cannot be used where a PIN is required (default: 3).

To reset the PIN after it is locked, cardholders have these options:

• Request a new PIN — The cardholder requests a new PIN according to the method you've set up.
• Go to an ATM to reset the PIN-fail count — Mexico only. This method requires that you set up macro commands with Galileo, which will automatically reset the PIN-fail count when the cardholder enters the correct PIN at an ATM.

📘

Note

Other methods to reset the PIN-fail count—waiting for the lock to expire, resetting in the CST, or using the Program API—are not valid for offline PIN.

Improving the user experience

Forcing the cardholder to attempt a transaction three times before it succeeds is not an ideal user experience. To make things a bit easier, you can use these methods:

• ATM first — ATMs in all regions are always online, so when the cardholder swipes the card and inputs an incorrect PIN, the ATM immediately contacts Galileo, and Galileo synchronizes the PIN on the card with the PIN in Galileo's system. In your welcome packets you can advise cardholders to use an ATM right after setting or changing a PIN.
• PIN Retrieval Service — Securely retrieve and present the PIN on your app or website or present it as a prompt before changing the PIN.
• FTPAM and FTPDY parameters — Setting these parameters permits transactions to be approved without offline PIN validation immediately following a PIN change. FTPAM specifies the maximum amount for a transaction to be approved without offline PIN validation, and FTPDY specifies the number of days since the PIN change to not require offline PIN validation. At the time that this first transaction is approved, Galileo runs a script to write the PIN to the chip. Keep in mind that using this method increases your fraud risk even as it improves user experience.

Cardholder verification method (CVM)

Depending on the region, a card must specify the order in which the various types of card authentication should be attempted. If one method fails, the next method is attempted. These are the options:

• Online PIN — Contact the issuer over the network connection
• Offline PIN — Verify the PIN on the EMV chip; up to three attempts
• Signature — No PIN validation; merchant authenticates the card with signature or other method
• No CVM — No card authentication

PIN-set scenarios

These scenarios explain how to set up and execute various PIN-set methods.

• Scenario 1: Cardholder sets PIN during card creation — Not for instant-issue cards. Valid for personalized cards when the cardholder is present at account creation. Not valid in Mexico.
• Scenario 2: Cardholder sets PIN during card activation — For instant-issue and personalized cards when the cardholder is not present at account creation. Valid in Mexico.
• Scenario 3: PIN set by issuer script at first transaction — Not valid in Mexico or other jurisdictions where a PIN must be written to the chip during emboss.

Scenario 1: Cardholder sets PIN during card creation

During account enrollment, the cardholder is prompted to provide a PIN. The card is not sent to emboss until after the cardholder sets the PIN. The PIN is written to the card when it is embossed, and the cardholder can securely retrieve the PIN before the first transaction if necessary.

This scenario is valid only when the cardholder is present at the time the account is created, such as when signing up for a card in an app. Do not use this method for instant issue cards; instead, go to Scenario 2. This scenario is not valid in Mexico.

Setup

• Set these parameters:
  • XAACT: YNO
  • EMVOP: Y
  • EMBFL: PINBLOCK
• The cardholder verification method (CVM) should be set in this order:
  • PIN online
  • PIN offline
  • Signature
  • No CVM
• PIN retry counter typically set to 3

Workflow

Steps

1. Call Create Account to create the account. Capture the card_id (CAD).
2. The card is in status: O (letter O; operational hold).
3. Present the cardholder with a PIN entry form.
4. Follow the direct render or direct POST PIN-set procedure, using the CAD for the API calls.
5. When you receive the PNCH: system_pin_change event, call Modify Status with type: 22 to set the card status to X (ready to emboss).
6. The emboss process picks up the card along with the PIN and writes the encrypted PIN block to the emboss file.
7. The card is changed to status: Y and Galileo sends the SHIP: card_shipped event.
8. The embosser writes the PIN block on the EMV chip and mails the card to the cardholder.
9. The cardholder receives the card in the mail. Optionally, you can include the PIN in the card mailer, or you can send a letter containing the PIN.
10. The cardholder goes to your app to activate the card. See Card activation in Setting Up a Card Program for activation options.
11. The cardholder attempts to make the first transaction.
    • If the cardholder inputs the correct PIN, the transaction is approved.
    • If the cardholder does not remember the PIN, launch the PIN Retrieval Service to present the PIN to the cardholder.

Scenario 2: Cardholder sets PIN during card activation

The chip receives a randomly generated PIN during emboss. When the cardholder receives the card and activates it, the cardholder is prompted to keep the random PIN or to change it. If the cardholder changes the PIN, the PIN is written to the chip during the first transaction. This method can be used for instant-issue cards, when the cardholder is not present at the time of account creation, or it can be used for personalized cards.

Setup

• Set these parameters:
  • EMVOP: Y
  • EMBFL: PINBLOCK
  • SRPEL: Y (Mexico only)
  • KPPIN: Y (Mexico only)
• The cardholder verification method (CVM) should be set in this order:
  • PIN offline
  • PIN online
  • Signature
  • No CVM
• PIN retry counter typically set to 3

Workflow

Steps

1. Call Create Account to create the account. Capture the card_id (CAD).
2. The card is in status: X (ready to emboss).
3. The emboss process picks up the card along with the randomly generated PIN and writes the encrypted PIN block to the emboss file.
4. The card is changed to status: Y and Galileo sends the SHIP: card_shipped event.
   • Mexico only. The Program Manager generates a waybill, and then calls Update Account to put the name of the waybill in id2, with idType2: 14. Use the CAD for accountNo.
5. The embosser writes the encrypted PIN block to the EMV chip.
6. The cardholder receives the card, either in person or through the mail. Optionally, you can include the PIN in the card mailer, or you can send a letter containing the PIN.
7. The cardholder goes to your app to activate the card. See Card activation in Setting Up a Card Program for activation options.
8. Launch the PIN Retrieval Service to display the current PIN, with an option to change the PIN.
   • If the cardholder decides not to change the PIN, the cardholder inputs the displayed PIN in the card reader for the next transaction.
   • If the cardholder decides to change the PIN, go to PIN-change procedure.

Scenario 3: PIN set by issuer script at first transaction

No PIN is set by the embosser. When the cardholder attempts the first transaction, it fails the specified number of times and then contacts Galileo online. Galileo runs a script that pushes a randomly generated PIN to the card reader. Do not use this method in regions where a PIN must be written on the chip during emboss, such as Mexico.

Setup

• Set these parameters:
  • EMVOP: Y
• The cardholder verification method (CVM) should be set in this order:
  • PIN offline
  • PIN online
  • Signature
  • No CVM
• PIN retry counter typically set to 3

Workflow

Steps

1. Call Create Account to create the account. Capture the card_id (CAD).
2. The card is in status: X (ready to emboss).
3. The emboss process changes it to status: Y and sends the SHIP: card_shipped event.
4. The embosser writes 0000 to the chip.
5. The cardholder receives the card in the mail.
6. The cardholder activates the card. See Card activation in Setting Up a Card Program for activation options.
7. The cardholder attempts to make a first transaction, which launches the Issuer script procedure to write a randomly generated PIN on the chip.
8. The cardholder can view the new PIN with the PIN Retrieval Service and then complete the transaction.

PIN-change procedure

The cardholder changes an existing PIN using your interface.

1. The cardholder changes the PIN using the direct render or direct POST PIN-set procedure.
2. Galileo stores the changed PIN and sends the PNCH: system_pin_change event.
3. Now the PIN on the chip and the PIN in Galileo's system do not match. You have two options:
   • Use the PIN Retrieval Service to display the new PIN to the cardholder.
   • Use the issuer script procedure, as shown in the next section, the next time the cardholder attempts a transaction.

Issuer script procedure

The cardholder attempts to make a transaction with a new PIN. After at least one failed transaction attempt, the card reader contacts Galileo, which sends a script to synchronize the PIN.

1. The cardholder does one of the following:
   • Inserts the card into an ATM and inputs the new PIN. The ATM contacts Galileo online.
   • Goes to a point of sale and attempts to make a transaction. After failing to verify the PIN for the configured number of times, the card reader contacts Galileo online.
2. Galileo sends a script to write the new PIN on the chip. (Optionally, you can use the PIN Retrieval Service to display the new PIN to the cardholder).
   • Mexico-based clients can request to receive the PCIS: pin_changed_by_issuer_script event message, which notifies whether the script successfully changed the PIN on the chip.
3. If the script is successful, the next transaction attempt is successful when the cardholder inputs the new PIN.
4. If the script is unsuccessful, Galileo checks the number of days in the FTPDY parameter.
   • If FTPDY days have not expired, then the script is sent again until it is successful.
   • If FTPDY days have expired, the transaction is denied.

Galileo setup

These internal parameters are set at Galileo according to your use case.

See the Offline PIN parameters table for the full list of product parameters to be configured at Galileo.