Account Updater Models

on Oct27

Written by

James Davis

Senior Technical Writer
at United Thinkers

Author of the Paylosophy blog, a veteran writer, and a stock analyst with extensive knowledge and experience in the financial services industry that allows me to cover the latest payment industry news, developments, and insights. Read more

Reviewed by

Katherine Pensatori

Reviewed by Katherine Pensatori

Product Specialist at United Thinkers

Product specialist with more than 10 years of experience in the Payment Processing Industry. I help payment facilitators and PSPs solve their various payment processing issues. Read more

In our previous articles we referred to account updater mechanisms in different contexts. However, there was never a post particularly addressing account updater logic. This article is dedicated exclusively to description of account updater models.

As we mentioned in our previous articles, account updater mechanism is intended for getting updated cardholder information. Account updater functionality is extremely relevant in recurring billing and bill payment contexts.

The information that can be updated includes card expiration date, and, in some cases, card numbers. A new card number is required, for example, in the case when the card got lost or stolen and was replaced with a new one having a different number.

There are three basic models, according to which account updater can function:

File-based model. A merchant sends a file with card numbers and gets a response file with respective updates after some time. Account updater systems of Visa and MasterCard associations follow this model.
Subscription-based model. A merchant sends a file with accounts it wants to get updates for and subscribes to receive updates for them. After that, on a regular (say, weekly) basis, the merchant can download files with updates for the accounts it subscribed for. The mechanism is similar to “notice of change” used for ACH transaction processing. Sometimes, this model is called account refresher. It is used by American Express.
Integrated model. A merchant sends transactions for processing. During processing, the system gets updated information from the issuer. It uses this information for transaction processing (in order to maximize the chances of approval). Then it includes additional updated information in the response to a specific transaction when it is sent to the merchant. This model is used by many payment gateways.

Example

In order to show how the three models function, let us consider an example of a file, containing ten transactions. For four of these transactions updates are already available, while for two of these transactions updates will become available in a week.In the first case (file-based model) the merchant sends the file and (next day) receives another file, listing the four accounts and respective updated information on them. After that the merchant has to decide, whether he should process the file at once, or wait until other updates become available.

In the second case (subscription-based model) the merchant sends the file, receives acknowledgement, and the file with four updates. He can process it at once and then, in a week, when two more updates become available, process it again.

In the third case (integrated model) the merchant sends the file to be processed and gets the update for four transactions. He gets the two remaining updates when he sends the file next time.

Conclusion

If you have a recurring billing system and you need to implement account updater mechanism, you should check in advance, which model is used by the system you are going to get updates from, and build the architecture on your end, accordingly. The recommendation is especially relevant if you need to combine two different systems, such as, for example, Visa and American Express, which use different account updater models.