PAYMENT PROCESSING RULES - EUROPE REGION
Mastercard’s Directives: Europe Region
Mastercard's Rules in the Europe Region or specific countries within it have the following modifications:
Acquirer Authorization Requirements
In the Europe Region, the modification to the Rule is as follows:
For any authorization request exceeding zero, the Acquirer must specify whether it is a preauthorization or a final authorization.
The reference to the Single Message System does not apply in the EEA.
Strong Customer Authentication (SCA) Requirements
Authentication Outage Exception
The directives herein pertain to Intra-country and Cross-border Transactions executed within and between SCA Countries.
An Acquirer may, at its discretion, authorize a Merchant to utilize the Authentication Outage Exception flag in the context of authorization request messages. However, it is incumbent upon the Merchant to first endeavor to apply a suitable exemption (subject to the Acquirer's explicit approval) before resorting to the usage of the Authentication Outage Exception.
Ensuring Proper Usage of Authentication Outage Exception
It is vital for the Acquirer to exercise due diligence in preventing any improper exploitation of the Authentication Outage Exception as a means to circumvent authentication requirements. The employment of this exception shall only be considered valid when authentication failure endures for a minimum duration of five minutes, during which all authentication attempts prove futile, rendering no successful attempt responses. Following the resolution of the authentication outage, regular authentication procedures must promptly resume. Should the Corporation request substantiation of the outage, the Acquirer must expeditiously furnish comprehensive and unequivocal evidence.
Restrictions on Authentication Outage Exception Usage
The Authentication Outage Exception may not be used to setup Merchant-initiated Transactions or recurring payment plans, nor may it be used to check the status of an account.
Chargeback Implications for Authentication Outage Exception
Transactions conducted through the utilization of the Authentication Outage Exception do not enjoy immunity from chargebacks stemming from fraudulent activities.
Remote Electronic Transaction Authorization Requirements
In the context of authorizing a Remote Electronic Transaction, adherence to the authentication processes involving EMV 3DS and Identity Check is compulsory, unless an Acquirer exemption to SCA applies, or an alternative SCA compliant methodology is employed (e.g., delegation of an alternative technical SCA solution to the Merchant), or in the event of an exemption under Article 17 of the PSD2 RTS (or corresponding legislation) with explicit acknowledgment from the Merchant.
Obligation to Justify Omitting Authentication
When SCA by the Issuer is deemed unnecessary, delegated, or omitted, the Merchant is obliged to furnish the Acquirer with a detailed justification for omitting authentication (e.g., citing an exemption or exclusion). In the relevant authorization message, the Acquirer must accurately specify the reason for the exemption or exclusion within the designated field as prescribed by its registered switch. Submission of the authorization request without providing the reason for omitting authentication is strictly prohibited.
Enabling TRA Exemption for E-commerce Merchants
Acquirers who permit their e-commerce Merchants to seek a Transaction Risk Analysis (TRA) exemption must duly enable the TRA exemption flag for such Merchants during the enrollment process for the Identity Check Program, as facilitated through the Identity Solutions Services Management (ISSM) tool.
For the purpose of optimizing authorization approval rates for Transactions benefiting from an Acquirer exemption, Merchants are strongly advised to dispatch an EMV 3DS authentication request, duly indicating the Acquirer exemption flag.
The following are the requirements for how Issuers and Acquirers must implement the Acquirer exemption flag in EMV 3DS authentication requests:
EMV 3DS Version Requirements for Challenge Indicator and SCA Exemptions
The Mastercard "Merchant Data" EMV 3DS Message Extension Field 1 (SCA Exemptions) must be set to the value 05/No SCA Requested, Transaction Risk Analysis conducted, and the Challenge Indicator value must be specified as 02/No Challenge in the context of EMV 3DS version 2.1.
The Challenge Indicator value should be set to 05/No SCA Requested; Transaction Risk Analysis conducted as per EMV 3DS version 2.2.
Compliance with Mastercard EMV 3DS Message Extension Flag
Acquirers serving e-commerce Merchants accepting corporate Cards and Issuers issuing such Cards are obligated to uphold the usage of the Mastercard "Merchant Data" EMV 3DS Message Extension flag in EMV 3DS authentication requests. This flag serves as an indicator of whether the conditions for exemption under Article 17 of the PSD2 RTS (or corresponding legislation) are met, thereby enabling the Issuer to apply said exemption. The flag is situated within the Mastercard "Merchant Data" EMV 3DS Message Extension Field 4 (Secure Corporate Payment).
Account Status Inquiry (ASI) Requests:
In the EEA, UK, and Gibraltar, the rule concerning ASI request messages and data fields is modified as follows. References to ASI request messages and data fields should be replaced with the corresponding message type and data fields of the Customer's chosen registered switch.
Stand-In Processing Service:
In the Europe Region, the rule regarding the Stand-In Processing Service is modified as follows. For all Maestro and Cirrus Card Programs, an Issuer must utilize the Stand-In Processing Service. This requirement does not apply if the Issuer started using an alternative authorization service before 17 September 2008, and that service meets the Corporation's performance standards outlined in Rule 2.4.2. For the Maestro and Cirrus Card Programmes, Stand-In Parameters ought to be adjusted at or above the Corporation's default limitations. The necessity of using CVC 1 Verification in the Stand-In service does not apply to Maestro Chip-only Cards, as defined in section 6.11, "Maestro Chip-only Card Programs."
Mastercard Rules:
In the EEA, UK, and Gibraltar, the rule on this matter is altered as follows:
Unless expressly obliged to do so by the registered switch the Issuer has selected, an Issuer is not required to take part in the Stand-in Processing Service.
The chosen registered switch must offer a backup service capable of granting authorization requests on behalf of the Issuer. The Stand-in Processing Service can be utilized for this purpose. The Issuer must configure its parameters in the backup service of its chosen switch, ensuring they are set at or above the default limits established by the Mastercard Corporation for Mastercard, Maestro, and Cirrus Card Programs.
Smart Authentication Stand-In:
In Armenia, Azerbaijan, Belarus, Israel, Georgia, Kazakhstan, Kyrgyzstan, Tajikistan, Russian Federation (excluding domestic authentication processed by NSPK), Switzerland, Turkey, Turkmenistan, or Uzbekistan, it is mandatory for Issuers to participate in Smart Authentication Stand-In. For Issuers in all other European Region countries, participation in Smart Authentication Stand-In or an alternative authentication Stand-in solution is required.
ATM Transaction Requirements for Mastercard Credit Card Issuers:
In the EEA, UK, and Gibraltar, the rule related to this matter is adjusted as follows:
Authorization Responses:
In the Europe Region, the rule concerning this subject is modified as follows:
The "Routing Timer Values" in Chapter 5 of the Authorization Manual describe the authorization response specifications that an Issuer need to follow. The Transaction will expire and be routed through the Stand-In Processing System or, as permitted under Rule 2.2.2, another alternate authorization provider chosen by the Issuer, if the Issuer's answer is not received within the allotted time limit.
Performance Standards—Issuer Requirements
In the Europe Region, the updated Rule for this matter is as follows:
If an Issuer's authorization failure rate exceeds one percent for two months within the six-months, it will be considered substandard performance. However, this calculation is applied only after the Issuer's fourth calendar month of operation or upon processing 5,000 Transactions in a calendar month, whichever comes first. To determine the Issuer failure rate, the sum of ISO 8583 response codes 31—issuer signed off, 82—time out at Issuer host, and 96—system malfunction, is divided by the total number of Transactions processed through the Issuer connection to the Interchange System.
An Issuer identified as having substandard performance will be subject to noncompliance assessments as outlined in Rule 2.4. Additionally, the Issuer will be required to implement the Stand-In Processing Service. For Chip Issuers, the mandate to implement the Stand-In Processing Service will also involve registering for M/Chip Cryptogram Validation in Stand-In.
Pre-Authorizations
In the Europe Region, the revised Rule for pre-authorizations is as follows:
In a dual message environment, the Acquirer must specify each Processed Transaction authorization request as either a preauthorization or a final authorization.
In the EEA, UK, and Gibraltar, the Rule is further modified as follows:
The authorization request must be clearly marked as a preauthorization in the designated field, using the value specified by the registered switch of the Issuer's choice.
Pre-Authorizations —Maestro POS Transactions in the Europe Region are subject to the following modifications:
Pre-authorizations are allowed for Card-not-present Maestro POS Transactions as long as they adhere to the specified requirements. However, for Maestro POS Transactions conducted in a Card-present environment, preauthorizations are generally not allowed, except for certain cases like automated fuel dispenser Transactions, electric vehicle charging Transactions, and Contactless transit aggregated Transactions.
However, this generalization is not always true.
Pre-Authorizations for Maestro POS Transactions in Netherlands and Switzerland
For Maestro POS Transactions carried out in a Card-present environment at vending machines in the Netherlands and Switzerland designated with MCC 5499 (Miscellaneous Food Stores—Convenience Stores, Markets, Specialty Stores), pre-authorizations for an estimated maximum amount are permitted. In such cases, the Acquirer must promptly notify the Issuer of the final Transaction amount using an advice message within 20 minutes of the authorization response message.
In the Netherlands and Switzerland, issuers need to have the capability to receive the advice message and process the transaction to the cardholder's account accordingly, instead of depending solely on the preauthorization response. It's important to mention that for issuers in other countries, supporting Maestro pre-authorizations at vending machines in the Netherlands and Switzerland is optional.
Pre-Authorization for Card-not-present Maestro POS Transaction
To identify an authorization request for a Card-not-present Maestro POS Transaction for an amount greater than zero as a preauthorization, the Acquirer must meet certain criteria. This includes requesting authorization for an estimated amount or when there are possibilities that the Transaction may not be completed due to reasons other than technical failure or lack of full issuer approval. Examples of such situations include when the Cardholder may choose to complete the Transaction with another payment method at a later time (e.g., during hotel check-out or rental car return), when the ordered products may be later discovered to be out of stock, or if the provided mobile phone number for a top-up is found to be non-existent.
It is very important to understand that while deciding whether to classify an authorization as a preauthorization, the risk of technical failures, such as telecommunications or terminal failures, should not be taken into account. Lastly, any Card-not-present Maestro POS Transaction clearing message related to a preauthorization must be presented within seven calendar days from the authorization approval date, and the presented Transaction amount must match the approved amount.
Pre-Authorizations—ATM and Manual Cash Disbursement Transactions
In the Europe Region, the Acquirer is responsible for ensuring that any ATM Transaction or Manual Cash Disbursement Transaction request for an amount greater than zero is categorized as a preauthorization under the following conditions:
It is important to note that technical failures such as telecommunications failure or Terminal failure should not be considered in determining whether authorization should be classified as a preauthorization.
Any ATM Transaction or Manual Cash Disbursement Transaction linked to an approved preauthorization must be presented within seven calendar days from the date of authorization approval, and the Transaction amount presented must match the authorized amount.
Final Authorizations
In the Europe Region, the Acquirer must ensure that any authorization request for an amount greater than zero is denoted as a final authorization when:
In the EEA, UK, and Gibraltar, the Rule regarding this matter is modified as follows:
领英推荐
The authorization request must be explicitly indicated as a final authorization in the designated field and with the value specified by the registered switch of the Issuer's choice.
Message Reason Code 4808 Chargeback Protection Period.
The Rule concerning this matter in the Europe Region has been modified as follows.
The chargeback protection periods for the message reason code 4808 (Authorization-related Chargeback) are as follows for each approved authorization:
Preauthorization of a Mastercard POS Transaction: Thirty calendar days from the date of authorization approval.
Preauthorization of a Maestro POS Transaction, ATM Transaction, or Manual Cash Disbursement Transaction: Seven (7) calendar days from the date of authorization approval.
Final authorization: Seven (7) calendar days from the date of authorization approval.
Multiple Authorizations:
The rule applicable to Mastercard POS Transactions and Maestro POS Transactions in the Europe Region states that upon receiving the Transaction clearing record, the Issuer must use a unique identifier to match the initial approved pre-authorizations with any additional approved pre-authorizations related to the Transaction. In the EEA, UK, and Gibraltar, the rule is further adjusted to require the Acquirer to include a unique identifier from the initial approved authorization of a Transaction in the appropriate field of additional authorizations and the Transaction clearing record, according to the specifications of the registered switch chosen by the Acquirer.
Full and Partial Reversals:
In the EEA, UK, and Gibraltar, the rule regarding Full and Partial Reversals is modified. The customer-selected registered switch's relevant message types are used in place of the references to the Reversal Request/0440 and Acquirer Reversal Advice/0420 messages.
Acquirer Requirements for Full and Partial Reversals in the Europe Region
In the Europe Region, the Rule pertaining to this matter is adjusted as follows.
For the Acquirer of a Merchant located in Italy, identified with an MCC listed in the table below and accepting Mastercard or Debit Mastercard Cards, supporting full and partial reversals performed at the POI is necessary. This is also required whenever, due to technical reasons, the Acquirer is unable to communicate the authorization response to the Merchant for all prepaid Debit Mastercard and prepaid Mastercard Card Account range.
MCC Description
5310 Discount Stores
5311 Department Stores
5411 Grocery Stores, Supermarkets
5541 Service Stations (with/without Ancillary Services)
5542 Fuel Dispenser, Automated
5621 Women’s Ready-to-Wear Stores
5691 Men’s and Women’s Clothing Stores
5732 Electronic Sales
5812 Eating Places, Restaurants
5814 Fast Food Restaurants
5912 Drug Stores, Pharmacies
5999 Miscellaneous and Specialty Retail Stores
Issuer Requirements for Full and Partial Reversals in Italy
In Italy, the Rule on this matter is adjusted as follows:
An Issuer operating in Italy is obligated to enable full and partial reversals for all prepaid Mastercard and prepaid Debit Mastercard Card Account ranges.
Full and Partial Approvals
Regarding the Europe Region, the Rule concerning this topic is modified as follows:
It is necessary to give partial approvals at Merchants marked with MCC 5542 (Fuel Dispenser, Automated) for all Mastercard Account ranges if a client already supports partial approvals for Maestro or any other debit brand, as stated in Rule 4.11.1. Additionally, if a customer supports partial approvals on other brands, even for the same product categories and merchant types, they must also support them on Mastercard and Maestro. If partial approval support is not necessary for other brands, it is also not necessary for Mastercard or Maestro, with the exception of support at merchants identified with MCC 5542, as mentioned in the previous sentence.
Refund Transactions and Corrections
Acquirer Requirements for Refund Transactions
The following changes have been made to the Rule in the EEA, UK, and Gibraltar:
The matching message type of the registered switch selected by the customer is used in place of references to First Presentment/1240 messages.
Issuer Requirements for Refund Transactions
The following changes have been made to the Rule in the EEA, UK, and Gibraltar:
The matching message type and data fields of the registered switch selected by the customer are used in place of the Authorization Request/0100 messages and data fields.
Balance Inquiries
The following modifications to the rule are made in the European Region:
Support for domestic, inter-European, and intra-European balance enquiries made at ATM Terminals is strongly advised for Issuers in the Europe Region.
When an Issuer offers support for balance inquiries at its ATMs for Cardholders, it is likewise required to do so for balance inquiries at the ATMs of other Customers in the Europe Region. Based on each Card's category (such as debit or credit), the Issuer may make distinctions between them.
The Rule on this subject is changed as follows in the EEA, UK, and Gibraltar:
In the message type, field, and value provided by the registered switch set by the customer, a balance inquiry must be conspicuously indicated.
Chip Transactions:
A Chip Transaction involves a Mastercard or Maestro Transaction where the Terminal sends a unique acceptance brand identifier associated with Mastercard or Maestro to the Acquirer. This acceptance brand identifier is transmitted through the Dedicated File Name (DF Name). All terminals capable of handling chip transactions must capture and transmit the DF Name whenever a Chip Transaction involves a Mastercard or Maestro Transaction.
In the case of Mastercard or Maestro Chip Transactions, it is the Acquirer's responsibility to convey the DF Name to the Issuer in the authorization and clearing message. Additionally, the Acquirer must ensure that the chosen registered switch also includes the DF Name during transportation.
In order to distinguish a Chip Transaction from a Mastercard or Maestro Transaction, every Customer is required to keep the DF Name along with other Transaction data and utilize it for identification purposes.
Electronic Commerce Transactions:
Both the acquirer and the merchant rely on the acceptance brand the cardholder chooses in electronic commerce transactions to determine whether the transaction is a Mastercard or Maestro transaction.
Similar to Chip Transactions, for Mastercard or Maestro Transactions in Electronic Commerce, the Acquirer must transport the acceptance brand to the Issuer in the authorization and clearing message. The Acquirer also needs to ensure that the registered switch chosen by them also includes the acceptance brand in the message.
To identify a Transaction as a Mastercard or Maestro Transaction in Electronic Commerce, each Customer must store the acceptance brand along with other Transaction data and rely on it for identification purposes.
#mastercard #europe #directives #rules #acquirer #authorization #sca #strongcustomerauthentication #emv3ds #merchantdata #issuer #accesscontrolserver #authenticationoutageexception #chargebacks #remotetransaction #electroniccommerce #preauthorization #finalauthorization #reversals #balanceinquiries #chipelectroniccommerce #frauddetection #payments #compliance #financialinstitutions #highriskmerchant #subscriptionbusiness #sarsfilings #feesandrevenue
Read More: