In 2017, the International Organization for Standardization (ISO) announced a revision to the length of an issuer identification number (IIN) from six to eight digits. As previously communicated, Visa, Mastercard, American Express, and Discover will move to eight-digit BIN structures in the coming years. Elavon is aware of the impacts to the numerics used in the card brand payments systems and has taken the steps
to support the migration to an eight-digit IIN (BIN). Full implementation for all card brands is targeted for April 2022.
New commercial credit products introduced in Canadian region
With the April 2020 Regulatory release, implemented in July 2020, Mastercard introduced five new commercial credit products (MBA–Mastercard B2B Product 2, MBG–Mastercard B2B Product 3, MBH–Mastercard B2B Product 4, MBI–Mastercard B2B Product 5, and MBJ–Mastercard B2B Product 6) to the Mastercard Enterprise Solution Wholesale Travel Program for the U.S. In October 2020 Mastercard will introduce these commercial credit products in the Canadian region. The new products will have unique interchange rates. Elavon will build new charge types to support the new rates.
Mastercard introducing new consumer credit interchange programs
Effective October 16, 2020 Mastercard is introducing 10 new consumer credit, small-ticket interchange programs in the US region. There will be 5 for card present transactions and 5 for card not present transactions. These transactions must have a value of USD $5.00 or less. Elavon will build new charge types to support the new programs and rates.
Changes to Visa response source/reason code and authorization source code fields
The Response Source/Reason Code field in the Visa authorization response message and the Authorization Source Code field in settlement message identify if and how a transaction was authorized. To uphold the integrity of the payment system and to better protect cardholders, merchants, issuers, and acquirers from evolving fraud trends, Visa is enhancing the response source/reason code and authorization source code information to indicate the source of an authorization code. Visa will implement changes which will specify if an authorization code was obtained through VisaNet in the authorization response message. If the authorization code is not obtained thru VisaNet, acquirers are required to indicate the source of the authorization code and provide it in the clearing record by using the enhanced authorization source code values. In October 2020, issuers and acquirers must be able to support
the new values. In a future release Visa will be mandating the value received in the authorization response message must be captured and returned in the settlement. Elavon will be updating the EGSF (Elavon Global Settlement File) to support this change. In addition, if it is determined the Visa TC33 will contain this information, Elavon will also update the authorization matching process to include this field. Additional information will be shared as it becomes available.
Enhancements to business-to-business virtual payments product offering
On October 16, 2020, Visa will be expanding the existing Visa B2B Virtual Payments product offering to include deferred debit and prepaid products. In addition Visa is introducing a new global product-specific interchange fee program. Elavon will build a new charge type to support the new program and make changes to existing logic to support the addition of deferred debit and prepaid products to the existing B2B interchange program.
Enhancing decline code management and authorization consistency
While the majority of authorizations are approved, there are circumstances when an issuer may decline a transaction, for example due to a negative account status, unsupported transaction type or authentication failure. Some declined transactions will never be approved if reattempted, while others may be approved if the decline condition changes
or correct authentication is supplied. To help issuers and acquirers clearly identify the action to be taken following a decline, Visa will reposition existing decline response codes and group them into categories.
- Category 1 – Issuer will never approve
- Category 2 – Issuer cannot approve at this time
- Category 3 – Issuer cannot approve with these details
- Category 4 – Generic response code
Please be aware that streamlined rules for these categories and fees could be incurred in the future for those not following the proper declined authorization procedures. Merchants should never manipulate data on a declined transaction with intentions of reattempting to gain authorization. Visa will update their rules to allow more flexibility to merchants related to decline retries and the new rules do allow for 15 reattempts in a 30 day period, except Category 1 declines as these should never be retried. Elavon will provide additional details about these decline code mandates prior to fees being passed along where merchants are not properly managing their declined authorizations
Authorization mandate for credit/return transactions
Reminder: Visa has updated acceptance rules to require merchants to authorize credit/return transactions. Obtaining an authorization for a credit/return transaction is optional for airline transactions with an airline MCC. Airline transactions with non-airline MCCs are required to support authorizing credit voucher/merchandise return transactions. If a non-airline MCC credit/return transaction does not have an authorization it will be subject to an authorization processing integrity fee.
Visa force post restrictions
Reminder: Visa requires controls be in place to prevent force posted transactions from entering their network. A force posted transaction bypasses the authorization process and does not have a valid authorization that has been obtained from their card issuer. As such, merchants should not force transactions when a valid authorization code has not been obtained. Elavon will work with merchants that are forcing transactions without a valid authorization code to determine how to best resolve force post risks. Please note that transactions submitted without a valid authorization code may not be processed and settled by Elavon.:
All Card Brands
Multiple card brands support of 3D secure 2.0
EMV 3DS (3-D Secure 2.0) facilitates the exchange of data between the merchant and the card issuer to better authenticate a cardholder to the card issuer. The objective is to benefit each party by providing the ability to authenticate cardholders during an e-commerce purchase, reducing the likelihood of fraudulent usage of payment cards. Merchants using a third-party 3DS solution provider should contact their vendors for more information on product availability. Merchants not supporting EMV 3DS by August 2020 could have additional liability exposure with disputes. Additionally, Mastercard requires merchants in regulated markets, outside of Europe, to have a minimum safety and security requirement to request authentication on every eCommerce transaction using EMV 3DS to mitigate additional liability exposure with disputes. Merchants should be aware of this exposure and be prepared to work with their 3DS Service provider to implement EMV 3DS. Clients utilizing EMV 3DS should also be aware that CAVV (Cardholder Authentication Verification Value) Version 7 is required effective October 2020.
All information within this communication is subject to changes from the card associations.