Card brand changes: September 2021

Mastercard will be introducing the PCI Software Security Framework (SSF) into Site Data Protection (SDP) Program Standards in Q1 2021. This means all merchants and service providers that use third party-provided payment applications or payment software must either validate that each one is compliant with the PCI Payment Application Data Security Standard (PA-DSS) or the PCI Secure Software Standard, as applicable. It is also strongly recommended that you and your service providers only use software vendors that comply with the PCI Secure Software Lifecycle (Secure SLC) Standard.

What you need to do:

It is strongly recommended that you and your service providers only use software vendors that comply with the PCI Secure Software Lifecycle (Secure SLC) Standard. Click for more on the position Visa and Mastercard take regarding PA-DSS and SSF.

Mastercard is communicating the final steps to complete the transition from 3DS 1.0 to EMV 3DS (2.0). These steps are designed to promote higher CNP approval rates, lower CNP fraud, and to allow enough time for customers to complete their transition to EMV 3DS (2.0).

Mastercard is undertaking the following steps to ensure a successful decommission of the Attempts Server for 3DS 1.0 processing:

• After October 1, 2021, the Mastercard Directory Server will respond with a ‘VERES = N’ with no accountholder authentication value (AAV) for any unenrolled account range.
• Access Control Server (ACS) providers may still provide attempts responses to merchants during this time.
• Mastercard will be enabling caching capability, as per the 3DS 1.0 specification, to help the Merchant Plug-In (MPI) providers determine whether an account range is eligible for authentication.
• Merchants that receive a ‘VERES = N’ after October 1, 2021, have three options:
  • Resubmit to EMV 3DS with liability shift (preferred)
  • Proceed to authorisation without liability shift
  • Cancel the transaction
• Mastercard has been asking all merchants to stop sending their Attempts Transactions to the 3DS 1.0 network since July 1, 2021 to prepare for the October 1, 2021 Attempts decommission date.

What you need to do:

If you are using an Elavon gateway, you have no action to take as we look after this for you. If you are using a third party gateway you should contact your gateway provider to ensure that they are ready for decommission of the Attempts Server for 3DS 1.0 processing.

Mastercard has revised its rules around acceptance of quasi-cash and manual cash disbursements in a face to face environment to alleviate concerns relating to the physical exchange of a card or personal identification between you and your customers.

Mastercard have made the following checks optional as opposed to mandated:

• Requesting personal identification with the cardholder’s signature, the cardholder’s photograph or both.
• Checking whether the signature, if present on the personal identification, appears to match the signature on the Mastercard card (if the card has a signature panel and has been signed).
• Comparing the photograph on the personal identification, if present, with the person presenting the Mastercard card.

It is no longer allowed to record information from the personal identification on the transaction receipt. 

What you need to do:

Familiarise yourself and point of sales team with these changes.

Mastercard allows for the offline processing of chip transactions for merchants with no fixed location (for example, aboard a plane, train or ship). Mastercard is now revising the list of card acceptor business codes (MCCs) for which this special procedure is allowed.

The rules currently stipulate that they apply for three MCCs only:

• MCC 4111 (Transportation-suburban and local commuter passenger, including ferries)
• MCC 4112 (Passenger railways)
• MCC 5309 (Duty-free stores)

This MCC list is changing as outlined below:

• MCC 4111 (Transportation—suburban and local commuter passenger, including ferries)
• MCC 4112 (Passenger railways)
• MCC 4411 (Cruise lines)
• MCCs 3000 through 3350 and 4511 (Air carriers, airlines)
• MCC 5811 (Caterers)

NOTE: Duty-free purchases are no longer covered by this rule.

What you need to do:

You should contact your service provider to ensure you only process offline chip transactions for the business types above.

Mastercard is revising the rules for contactless transaction acceptance at Mastercard contactless-enabled transit agency merchants. The revised rules provide clarification that an open payments enabled transit merchant is not obliged to accept contactless, non-reloadable prepaid products at contactless-only points of entry for access to transportation modes (turnstiles and bus contactless readers, for example).

What you need to do:

Transit agencies that accept Mastercard accounts at their entry points, and that do not accept non-reloadable prepaid products at the point of entry, must have suitable means (ticket offices, ticket vending machines, and so on) for the cardholder to purchase a suitable travel entitlement using their non-reloadable prepaid product. Non-reloadable prepaid card programs include certain product types like gift, corporate incentive, and rebate programs.
 

You must have clear and comprehensive customer communication on the types of contactless product that are blocked for acceptance at points of entry, and information on sales channels where the products can be used.

Mastercard is creating a new decline reason code for authorisations. This service will help ensure issuers properly use transaction decline codes, and provide merchants and acquirers better insight on the decline. Today the issuers often use a default or generic decline reason code (such as response code 05- Do Not Honor). The Decline Reason Code service is limited to card-not-present (CNP) declines, excludes mail and telephone order. Mastercard will map a subset of sensitive decline reasons on behalf of the issuer into three categories. Three new decline response codes will be introduced: Life Cycle (response code 79), Policy (response code 82), and Fraud/Security (response code 83).  

What you need to do:

You need to be aware that you will stop receiving certain decline codes that are not technical or financial in nature for CNP declines. Some examples of such decline codes include

• 04 (Capture Card)
• 14 (Invalid Card Number)
• 41 (Lost Card)
• 43 (Stolen Card)
• 54 (Expired Card)
• 57 (Transaction Not Permitted)
• 62 (Restricted Card)
• 63 (Security Violation)

From October 15, 2021, Mastercard will prohibit POI currency conversion (also known as dynamic currency conversion (DCC)) on Mastercard Wholesale Travel Programme (MWP) products.

What you need to do:

Elavon will make the necessary changes to block DCC on the transactions from this date. You do not need to make any changes but, if you support DCC, you should be aware that you will likely note a drop in volumes of DCC transactions. 

Deferred authorisation occurs when a merchant cannot complete an authorisation at the time of the transaction due to connectivity, systems issues or other limitations, and completes the authorisation later. We advised you recently that Visa had created a new indicator to be included in all deferred authorisation requests. Mastercard is now requiring all acquirers to support deferred authorisations from October 15, 2021. This is to inform the issuer that the authorisation request was sent on a deferred basis, which may account for any discrepancy regarding the time the transaction occurred and the time the authorisation request was received.
 

What you need to do:

If you are using an Elavon gateway, you have no action to take as we look after this for you. If you are using a third party gateway and process delayed authorisations, you should contact your service provider to ensure they support deferred authorisation. Processing delayed authorisations without the deferred authorisation flag will likely result in unnecessary declines.

Visa rules require that token cryptograms are new and unique for each authorisation request, and must not be stored beyond the authorisation request. This is to ensure the integrity of cryptograms as a key token domain control and prevent fraud. Effective January 30, 2022, a resubmitted or stale token authentication verification value (TAVV) or dynamic token verification value (DTVV) will result in a declined authorisation request.

What you need to do:

To avoid declined authorisation requests, you should contact your gateway provider to ensure they comply with the following processing rules regarding TAVV and DTVV cryptograms for cardholder-initiated, token based Credential on File and eCommerce transactions, including in-app eCommerce:

• The TAVV and DTVV cryptograms must be new and unique for each authorisation request.
• The TAVV and DTVV cryptograms are one-time use.
• The TAVV and DTVV must not be stored beyond the authorisation request.

Visa is re-emphasising the importance of using authorised and current BIN tables. Using incorrect or outdated BIN tables to represent select products may result in incorrect application of services, unnecessary declines, rejections or misrouting as well as increased reconciliation costs.

What you need to do:

To avoid processing issues you should not use bin tables purchased on the internet and refrain from using hard-coded BIN values to represent select products. Elavon receives account range information from the various schemes and uses this information internally to create an account range definition table format which can be delivered to point of sale (POS) devices, integrated point of sale (IPOS) systems, and specified third parties. If you don’t already use this account range definition table and you wish to, contact Elavon through your relationship manager or our customer service channels.

On April 1, 2021, Visa issued a reminder that PCI PIN entry devices (PED) v3.0 security approval would expire on April 30, 2021. After April 30, 2021, the affected PCI PIN Transaction Security (PTS) v3.0 devices were removed from the approved point of interaction (POI) devices list on the PCI SSC website and listed separately alongside the previously expired PTS v1 and PTS v2 devices here.
 

While the approval of PTS v3 PED devices did indeed expire on April 30, 2021, it does not prohibit you from continuing to use v3 devices purchased before the expiry date.
 

Hardware terminal picklists created from the PCI list of approved PTS devices are regularly updated; therefore, if you’re continuing to use your PCT PTS v3 devices after the April 2021 expiration date you will find the hardware terminal is no longer listed and will need to be manually added (if that function is available).

What you need to do:

If you’re continuing to use your PCI PTS v3 devices after the April 2021 expiration date, you will find your hardware terminal is no longer listed. It will need to be manually added (if that function is available)