Tokens, their role when a card expires or its number changes

It is essential to understand what a token is, and what role it plays in storing payment card information.

What is a Token?

A token is a string of letters and numbers representing a credit card and its expiration date. Most importantly, a token is not a credit card and, thus, does not carry the burden of PCI regulations surrounding storing credit card information. AMS only stores tokens, never credit cards. Not storing credit cards is how the winery reasonably complies with PCI regulations.  If AMS were to store card numbers, the winery would be subject to strict regulations like those for banks and retail stores, ostensibly making it impractical/impossible to comply with PCI.

Token Example:

Take example VISA number 4027840017481466 which expires 03/19.  After tokenization, the resulting token is 1466dwt1tmt93dz2

• The last four digits of the card become the first four digits of the token. The rest of the token is randomized.
• The card's expiration date is stored as part of the resulting token, not separately. That is why you cannot update a card's expiration date in AMS without recollecting the entire card number.

When you use a card on file, AMS passes the token to Shift 4 as part of the request. Shift 4, in turn, associates the token with the actual card data and send the request along.

Token Life Time

Credit Cards expire. So do tokens. A token does not last forever. In fact, the moment a token is generated, a timer starts ticking. How long that timer ticks depends on the configuration of your specific account at Shift 4, over which AMS has no control. There are several configuration options, but as a standard, we request that customers set the token lifetime to 24 months (the maximum value). If you have administrative access to your Shift 4 account, you will find the "Token Storage Duration" setting on the "Token Store Settings" menu.

When a token's clock runs out, the token becomes invalid and cannot be used again. If you try to process a charge in AMS and receive the error below, you most likely have used an expired token. 

Unique Identifier (1466dwt1tmt93dz2) not found for Merchant 00012345 ENGINE03A1

How the token refresh process from a card update works

The Card Brands' Role:

All card updater services, no matter who offers them, use the same underlying features provided by the card brands: VISA, Master Card, AMEX, etc.

Visa's VAU Program: https://usa.visa.com/dam/VCOM/global/run-your-business/documents/vau-merchants.pdf

MasterCard ABU Program: https://www.mastercard.us/content/dam/mccom/en-us/issuers/Documents/Mastercard-Automatic-Billing-Updater-Merchant-Global-2017.pdf

Shift 4's Role:

Once per week, Shift 4 sends card information off to the card brands; a few days later, Shift 4 will receive and process the results of the card brand's updates.

AMS's Role:

For AMS to make use of the updated information, we must make an inquiry to Shift 4 for every stored token, one at a time, making a note of any updated information. Currently, AMS runs our update code once a week on Sundays after the close of regular business.

There are three possible results of an inquiry about a token.

1. The token has no new information.
2. The token does have new information.
3. The token is invalid/expired.  Not to be confused with the card being expired.

Case 1: The token has no new information

In this case, no new information is recorded. A new token is generated as part of the process, renewing the token life timer.

No record of this action is recorded to the customer's account.

Case 2: The token does have new information

In this case, the Shift 4 response has supplied updated card information.  AMS stores this information and makes records a contact to the customer's profile.

In the example below, we can see that this was the primary card on file, and the expiration date was updated.

The following Shift4 credit card token was found to be the customer's primary payment card and has been updated.

Prior Token Info: Visa ending in ....6635

Token: 6635rnzvw6vexwp6    

Expiration Date: 02/21

New Token Info: Visa ending in ....6635

Token: 6635wyq8qsv3t0rb    

Expiration Date: 02/23

In the example below, we can see the customer card number was updated.

The following Shift4 credit card token was found to be the customer's primary payment card and has been updated.

Prior Token Info: MasterCard ending in ....7428

Token: 7428vpwbx99e5vjk    

Expiration Date: 05/19

New Token Info: MasterCard ending in ....0570

Token: 0570dyw0t0vexjdm    

Expiration Date: 05/22

Case 3: The token is invalid/expired.

Tokens most commonly expire from non-use.  That is customers who make a purchase and do not follow up for two or more years after that.  However, tokens can be expired before their normal life timer, if say the card account is closed, or the card expires, and no new information is available.

If Shift 4 responds that the token is invalid or expired, the card will be removed from the customer's account and a contact booked.

In the example below, the card updater service returned that the token was invalid.  Looking more deeply into the customer's purchase history, we find that the customer used the card several months before in November.  So then, why was this token expired?  It has not been two years.  As it turns out when the card was used in November the expiration date was December of that same year.  When the updater service at Shift 4 ran the card was found to be expired, no new, updated expiration date was found, resulting in the token being invalidated.  The result in AMS is the card being removed and a contact being booked.

The following Shift4 token for the customer's Mastercard ending in ....7958 has been removed because it was invalid/expired.

79582gsg7k4dvpqg    

This was the customer's primary payment card. New payment information should be obtained from the customer prior to next purchase.

Auditing The Updater

Since the updater books contacts as a result of its work, we can use the customer contact screen in AMS to audit the weekly update runs.  This menu option is PSCUM.MCC, you may search for MCC or start the menu directly via the AMS Command Line

The AMS system uses the contact code "AMSSYS" when booking contacts, a simple filter by this code will yield results.

If desired you may further filter for only successes or failures by a "comment" filter from the first filter box using "*UPDATE" or "*EXPIRED" respectively.