Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

« Previous Version 2 Next »

Introduction

The AMS portion of the account updater will run even if you are not using the service from Shift 4.  In this case the house cleaning aspects of the feature will function per usual, meaning expired tokens will be removed, and contacts booked in those cases.

 

At the time of writing this document Shift 4 is in early beta with their credit card updater service with no current ETA on completion and roll out. (07/2019)

This service promises to reduce decline rates and labor costs for staff to contact customers to collect updated payment information.

Cards can be updated due to expiration date changes, or entirely new card numbers in the case of fraud where the card is replaced.

Please see below for details on the update process and what to expect.

Table of Contents

Articles Referenced in this Article

Articles that Reference this Article

Central Table References

 

 

Tokens, their role in card updater

It is important that we start with an understanding of how card updates work, but first, we must understand what a token is, and what role it plays in storing cards.

What is a Token?

A token is a string of letters and numbers that represent a credit card. Importantly a token is not a credit card and thus does not carry the burden of PCI regulations surrounding storing credit cards.  AMS only stores tokens, never credit cards.  Not storing tokens is how the winery is able to comply with PCI regulations in a reasonable manner.  If AMS were to store card numbers the winery would be subject to the same strict regulations as major banks and retails stores, ostensibly making it impractical/impossible to comply with PCI.

Token Example:

Take an example VISA number 4027840017481466, expires 03/19.  Once tokenized the resulting token is, 1466dwt1tmt93dz2

  • The last four digits of the card are the first four digits of the token.  The rest of the token is randomized.
  • The expiration date is stored as part of the resulting token, not separately, this is why you cannot update the 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, can associate the token with the real card data and sends the request along.

Token Life Time

Tokens don't 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 (AMS has no control).  There are several options, but by standard, we request that customers set the lifetime to 24 months (the maximum value).  If you have administrative access to your Shift 4 account the setting can be found on the "Token Store Settings" menu under "Token Storage Duration".

When a tokens clock runs out the token becomes invalid and cannot be used again.  If you are trying to process a charge in AMS and have revived the error below, you have most likely tried to use a token that has expired.

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

How the card update process works

The Card Brands Role:

All card updater services no matter who they are provided by all use the same underlying features provided by the card brands. That is 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:

In order for AMS to make use of the updated information, we must make an inquiry to Shift 4 for every token stored, 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 normal 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.

  • No labels