Card brand changes: December 2020

As your payments partner, we are committed to keeping you up-to-date with industry changes and card scheme developments. There are nine updates and reminders included here. Please scroll to ensure you act upon all that are relevant to you and your payments processing.

Mastercard - Identity check (eCommerce) authentication changes

To support PSD2 regulations and issuer authentication options, Mastercard is adding new leading indicators to the Accountholder Authentication Value (AAV) generation.

The new indicators will be based on how the issuer authenticates transactions. Issuers will be able to increase approval rates by communicating authentication data from authentication platforms to authorisation platforms. Mastercard is creating two new leading indicators for the AAV to define when authentication is occurring based upon merchant whitelisting (frictionless flow) or decoupled authentication (challenge flow):

• Merchant whitelisting will be identified with a leading indicator of kR
  
• Decoupled authentications will be identified with a leading indicator of kS

Customer action:

None required, beyond awareness. Elavon asks its Service Providers and partners to ensure these new values are supported for eCommerce customers.

...................

Mastercard - Cardholder True Name

Mastercard introduced the True Name feature in 2019 and it can be enabled on any Mastercard or Maestro card product.  Designed to address a serious pain point for members of the transgender and non-binary communities, the True Name feature allows cardholders chosen name, not their former name, to appear on their card without the requirement of a legal name change.

Merchants choosing to request a form of identification when a card is presented for payment should be aware that the True Name feature may result in the name on the card differing from the name on identification provided by the cardholder.

Reminder

Mastercard does not require verification of the cardholder name. You must not refuse to accept a Mastercard on the sole basis that the name displayed does not match the name on the cardholder’s identification.

...................

Visa - OCT expiration date and CVV2 requirement change

An Original Credit Transfer (OCT) is a one-off credit transaction type that must be used when sending funds to a card account in scenarios where the funds are not a return/refund of a previous debt amount that was taken.  Typical uses are for pay-outs of winnings or insurance premiums, for example.

From 1 April 2021, an OCT will not require the presence of either the expiration date or CVV2 data. Visa will require that issuers do not decline OCTs solely due to the absence of either the expiration date or CVV2. It will be optional for originating entities to send these fields; however, when provided, the data must be accurate and not expired. 

...................

Visa - Update to CAVV / exceptions to reuse in Europe

Travel booking agents who may have multiple merchants related to the same booking and merchants who split the shipment of a customer order into multiple authorisations require a Cardholder Authentication Verification Value (CAVV) for each transaction, if the merchants wish to maintain fraud liability protection or to process the transaction without further authentication.

A CAVV is a cryptogram that indicates in the authorisation that authentication has been completed, albeit in a frictionless way in some cases, and provides fraud liability protection for up to 90 days.

If longer than 90 days has elapsed between the original authentication date and when the authorisation takes place, then the CAVV will not provide liability protection. In this situation, from a regulatory perspective, to avoid doing Strong Customer Authentication (SCA) again, the original CAVV is needed and can still be used - but without liability protection. A new CAVV can be obtained through the 3DS protocols (see below) to refresh the liability protection if desired.

To allow the ecosystem more time to prepare for the enablement of EMV® 3D Secure (3DS) 2.2 and the full support of 3DS Requestor Initiated (3RI) transactions, Visa is amending the rule that permits the reuse of the CAVV up to five times for split shipment scenarios and by travel agencies within the Europe region.

The existing rule was due to have expired by now, but Visa is extending the expiration date to 1 September 2022.

...................

Visa - Secure rules authentication for non-payment transactions

Non-Payment Authentication (NPA) requests were introduced in EMV 3DS to enable an eCommerce merchant to submit authentication requests when the transaction is initiated for a non-payment use case such as adding a card to a merchant’s website, modifying stored cardholder information, or issuer identification and verification of a cardholder during Visa token provisioning.

Effective immediately, when a merchant sends an NPA Authentication Request (AReq), the Visa Secure EMV 3DS platform supports the processing of NPA transactions in the following ways:

• If the transaction was successfully authenticated with a challenge, the Results Request (RReq) must contain an electronic commerce indicator (ECI) value of 05 and a Cardholder Authentication Verification Value (CAVV).
• If the transaction is authenticated without a challenge (i.e., frictionless), the ECI and CAVV are not required.
• If a merchant sends an NPA as part of a 3DS Requestor Initiated (3RI) authentication request (e.g., a merchant initiated authentication request when the cardholder is not available) and the transaction is successfully authenticated, the ECI and CAVV are not required.
• If a 3DS Server sends an NPA AReq with 3DS Requestor Authentication Indicator of “06 = Cardholder Verification as part of EMV token ID&V” an issuer must respond with a challenge request and the 3DS Server must proceed with initiating the challenge.

Customer action:

ECommerce customers and service providers using NPAs should review and make the necessary changes within transaction identifiers based on the authentication acceptance of the NPA by the Visa issuer.

...................

All card brands - In-app transaction identifiers

The Covid-19 pandemic has seen an acceleration in the use of application-based mobile payment transactions and the usage of this payment type is expanding into additional merchant segments. Application-based mobile payment transactions (also known as in-app) are those transactions where cardholders use their mobile devices to make purchases on merchant applications. This use of this payment type is moving into segments that traditionally contained only card present transactions. To limit unnecessary declines, it’s important that in-app payments are submitted for authorisations with the correct credential-not-present transaction identifiers and follow the stored credential rules and requirements.

• POS Entry Mode represents –
  • Manual Key Entry - used when the credentials are not being stored or when the cardholder is making their purchase and is requesting at the time to store the credentials for future use, OR
  • Credential on File (COF)
• POS Condition Code represents - eCommerce
• Electronic Commerce Indicator represented by the authentication type.

Customer action:

 If you and your service providers are using or developing in-app solutions, you need to review and include the correct identifiers in transactions to minimise the risk of declines.

...................

All card brands - Eight-digit BINs 

A Bank Identification Number (BIN) is a unique reference assigned to an Issuer for the purpose of issuing a card product.  Each BIN is unique to one specific offering that a Bank has in its portfolio, whether credit, debit, prepaid, commercial.  The BIN is currently shown as the first six digits of the long card number on the front of each card product.

Due to a shortage of available numbers, all card brands are now working towards expanding the available ranges by implementing 8-digit BIN codes across their networks, beginning in April 2022.

By this date, all acceptance points will be expected to be able to correctly recognise an 8-digit BIN series, and to process the card accordingly.

Customer action:

Elavon is already working towards this goal with both its internal systems and the products we offer.

If you use BINs to drive your promotions and other solutions, you will need to ensure that your process can handle both 6- and 8-digit BINs in order to correctly identify new card products and most effectively target your promotions.

....................

Multiple card brands - Refund authorisations: requirements and best practices

Visa, Mastercard, and Diners Club International are mandating that refund transactions are submitted online for Issuer authorisation from April 2022.

Exemptions:

• Airline MCCs have been exempted by Visa and Diners Club.
• Mass transit models (commuter travel) are exempt for Visa.

To aid Customers and Partners in their planning, Visa has shared the following points of consideration:

• The primary account number (PAN) and expiration date are the minimum mandatory data requirements for supporting the authorisation request for purchase return transactions. It is good practice to either have the cardholder re-present the card or confirm that the credential on file is still up-to-date to avoid a decline due to account reissue.

Clients that participate in Visa Account Updater (VAU) should include accounts to be refunded in their VAU inquiry batch file.

• Merchants and acquirers should use the POS entry mode that corresponds to the type of merchandise return transaction. If the credential for return is captured with a different method than the original purchase, the POS entry mode from the original purchase should not be retained. For example, in the scenario where the card is not swiped or dipped, or the device is not tapped, a POS entry mode of 01 / key entered is recommended to ensure the PAN and expiration date are sent to the issuer.
• Any authentication or cryptographic data from the original purchase should not be retained, recalled or replayed in the purchase return authorisation messages as this may be seen as a fraudulent use of the original transaction data and may cause the authorisation request to be declined.

Response codes of 00 (approval) or 85 (no reason to decline) must be actioned as an approval response.

• A merchant may process the refund onto a different (alternate) Visa account under the following circumstances:
  • The original account is no longer available or valid (for example, the original card has been replaced due to expiration or being reported lost or stolen, or was a Visa prepaid card that has since been discarded).
  • The authorisation request for the refund transaction was declined by the issuer.

...................

Visa - Enhanced decline codes 

Visa intends to implement new rules and POS prompts to help you and your staff understand the correct actions to take following the receipt of a decline response.  Visa will move all existing decline codes into four 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

You should never manipulate data on a declined transaction with intentions of reattempting to gain authorisation. Visa will update their rules to allow more flexibility and the new rules allow 15 attempts in a 30-day period, except for Category 1 declines which should never be retried.

You should be aware that fees could be incurred in the future where proper declined authorisation procedures are not followed.

Elavon is working with Visa to determine the correct coding values and will provide additional details about the codes, the prompts and the fees prior to their implementation.