Introduction

This guide gives you all the information you need to use for bank cardholder authentication with 3-D Secure during online transactions. It details the merchant (your) roles and responsibilities, the payment service provider (PayU) roles and responsibilities and some key information by supported card schemes.

The following card scheme authentication services are offered by us and covered by this procedure guide:

• Verified by Visa (Visa)

• SecureCode™ (MasterCard)

Note: PayU will only process authentication transactions submitted by the above schemes, and for services that we have mutually agreed with you. More may be added by issuers and will be added as it becomes available.

What is 3-D Secure?

As more consumers shop online, new risks are exposed. The anonymity of the internet poses the danger of unauthorised credit card purchases as there is no way of establishing if the shopper is in fact the authorised holder of the card used for payment. In light of these increasing risks to online merchants, the card issuers realised that reducing chargeback risk is important in order for the industry to grow.

3-D Secure was introduced in an effort to authenticate the shopper’s identity, reduce online fraud risk, and safeguard credit card payment transactions. Cardholders are being enrolled for 3-D Secure in order to be authenticated as the legitimate cardholder. The authentication provides an extra security step during the cardholder’s online transaction with you. Merchants enrolled for 3-D Secure will have their chargeback risk reduced by shifting the responsibility of the transaction chargeback risk to the issuing bank of the cardholder.

PASA (Payments Association of South Africa) are requiring all South African acquiring banks to enrol their merchants on the 3-D Secure program.

MasterCard brand their system “MasterCard SecureCode” (MCSC), while Visa call theirs “Verified by Visa” (VbV).

Verified by Visa and MasterCard SecureCode are based upon technical specifications called Three-Domain Secure or 3-D Secure. These protocols use SSL encryption to protect payment card information and details transmitted over the Internet. These three domains are comprised of:

• Issuer Domain:  The Issuer of the payment vehicle maintains the responsibility of determining the validity of the identity of the cardholder as well as the validity of the account being used to complete the transaction.
• Acquirer Domain:  The Acquirer maintains the responsibility of defining the procedures to ensure that the Merchants originating the transactions are operating in accordance with the agreement they have with the Acquirer and with the Verified by Visa and MC SecureCode business rules and technical requirements.
• Interoperability Domain:  Maintained by the payment networks, transaction data is exchanged using 3-D Secure and the common protocol.

3-D Secure Authentication Information

You should ensure that you are familiar with how authentication works before using any of these services. It is important that you understand the 3-D Secure protocol supporting authentication.

The Key Benefit of Authentication: Liability Shift

As indicated above, Internet transactions (Card not present transaction) have historically carried a higher risk because neither the cardholder nor the card can be positively identified at the time of purchase.

If your Acquirer receives a chargeback for a transaction processed by you, you are requested to provide evidence to support the validity of the transaction. In most cases evidence can be provided that the card was used, but not that the genuine cardholder was using the card. In this scenario, the Card Issuer would charge the transaction back to you (a chargeback), resulting in the loss of goods/services plus the cost of the transaction.

The introduction of 3-D Secure cardholder authentication means that you will now have the ability to prove that the cardholder used their card at the time of the transaction.

Cardholder authentication helps reduce chargebacks where cards are used fraudulently, or where the cardholder denies using the card. The liability shifts from the merchant, back to the card Issuer.

Minimising the risk of fraud is essential and 3-D Secure Internet Authentication should be used in conjunction with and not instead of any other fraud checks that you should have in place and it is important that you maintain your existing fraud checks. Failure to maintain existing fraud checks could result in you receiving chargebacks. Please refer to Appendix A for our ‘Best Practice’ on managing internet fraud.

Chargeback Reason Codes Included

You must be aware that each card scheme uses a different “reason code” to charge a transaction back. If you are using any automated risk tools you should ensure you cater for each scheme reason code where applicable.

Visa:

MasterCard:

Note: You may be asked to provide supporting information to the banks to defend a transaction, this information can be found in the PayU merchant portal under the transaction summary selection. 

One of the critical success factors of the authentication schemes is to remove chargebacks from the system. Each of the card issuers are adding edits to ensure, wherever possible, that you are not charged back for a transaction that was authenticated.

There are certain scenarios where you may not benefit from liability shift. This is typically due to regional variations in card scheme rules and is detailed under Liability Shift Rules.

Please note: You do not benefit from liability shift for any other chargeback reason codes other than those defined in this document above.

Card Enrolled for 3-D Secure VS Card Not Enrolled for 3-D Secure

Card issuers are in the process of enrolling all cards issued to cardholders to participate in 3-D Secure. At the start of a transaction, PayU checks with the issuing bank if the card is enrolled or not and then processes the transaction based on the guidelines of VISA and MasterCard for the card type and enrolment status. This first step is referred to as the Card Verification Request (VEReq) to scheme directory server (DS) and will receive a Card Enrolment Response (VERes).

The following status can be returned during the Card Enrolment Request.

Card Enrolled = Y:  If the card is enrolled for 3-D Secure the issuer responds with “Y” and the cardholder authentication process begins. VERes status = “Y”. No financial transaction will be attempted by PayU at this stage, next step is cardholder authentication..

Card Not Enrolled = N:  Not enrolled cards respond with “N” and the transaction can be processed. VERes status = “N”. The chargeback liability is with the issuer for not enrolled cards provided that the merchant is enrolled and card was correctly checked for enrolment. Whether or not a liability shift to issuer takes place will depends on the card type and the card issuer region. Some exceptions may exist for international issued cards. PayU will process financial transaction based on the PayU merchant risk configuration.

Card Enrolled Status Unavailable= U:  In some cases the issuer cannot provide the status and the response is “U”. Visa and MasterCard have different guidelines around liability shift.

Visa guideline: should the merchant elect to process the transaction, it will be at the merchant’s risk. PayU could process financial transaction based on the PayU merchant risk configuration.
MasterCard guideline: the risk is with the issuer and processing can proceed. VERes status = “U”. PayU could process financial transaction based on the PayU merchant risk configuration.

Please note: The following exceptions apply. Should you elect to process the transaction, you will not be able to claim liability shift and the chargeback remains with you:

- All non-enrolled Visa and MasterCard cards issued in the United States of America
- All non-enrolled Visa and MasterCard issued commercial returns VERes = “U” (corporate, business and purchasing) cards.

Note: VERes does not include distinguishing information regarding local or international issued cards.

3-D Secure Authentication

Once the Card Enrolment check is complete and the card is enrolled(VERes = Y), PayU will then redirect the shopper's browser to an external bank hosted page for cardholder authentication. After the shopper entered a one-time pin/password the browser is redirected back to PayU, PayU will then process a 3-D Secure Authentication Request (PAReq) and receive an Authentication Response (PARes).

The following status can be returned by the Card Authentication Request:

Full Authentication  = Y:  This occurs when the card issuer, cardholder, merchant and acquirer all correctly process a 3-D Secure authentication transaction. The cardholder successfully authenticated himself or herself (through a browser pop up or in-line window) with their card issuer. Chargeback risk resides at the card issuer. 

The card issuer will provide a Cavv (Cardholder Authentication Verification Value) to indicate authentication took place. Visa refers to this value as AAV (Authentication Verification Value), while MasterCard uses UCAF (Universal Cardholder Authentication Field). This value is passed to acquiring bank in the authorisation process as proof of authentication. PARes status = “Y”. PayU will process financial transaction.

Unable to Complete Authentication = U:  Authentication requests sent but is unable to be completed. PARes status = “U”. PayU could process financial transaction based on the PayU merchant risk configuration and card issuer guidelines.

Successful Attempted Authentication = A:  Authentication request sent successfully but the cardholder could not be authenticated. PARes status = “A”. PayU could process financial transaction based on the PayU merchant risk configuration and card issuer guidelines.

The card schemes differ with their support of “U” and “A” responses regarding liability shift.

For Visa:

The definition of an attempted authentication (“A”) for Visa cards is when both the online merchant (you) and the acquirer (your bank) support authentication and can confirm that everything has been integrated correctly. The attempt to authenticate must be successful. The card issuer must return a response confirming the attempt. If the card issuer is unable to confirm the attempt (e.g. the system went down), then you are unable to claim attempted authentication.

A successful attempt for Visa includes:

• Confirmation that the Issuer is not participating, from the Visa Directory
• Confirmation that the cardholder is not participating or has not yet enrolled
• A 3-D Secure response of “A” in the PARes status and ECI 06.

Visa card issuers must send an AAV (Cavv) for successfully authenticated transactions and may optionally send an AAV for a successfully attempted authentication.

For MasterCard:

The definition of an attempted authentication (“U” & “A”) for MasterCard cards is when both the online merchant (you) and the acquirer support authentication and can confirm that everything has been integrated correctly. The attempt to authenticate must be successful. The card issuer must return a response confirming the attempt. The term for this is “Merchant UCAF” (Cavv) which simply means that you are participating in the SecureCode™ scheme.

The merchant can claim attempted authentication on a MasterCard SecureCode™ transaction when making an attempt to authenticate the cardholder. Ideally, you should receive a 3-D Secure message response from the card issuer confirming the attempt but if not, you can still claim liability shift as long as you have correctly integrated the SDK and successfully sent the authentication request.

This means that liability shift may be offered for MasterCard in the following instances:

• You receive confirmation that the Issuer is not participating, from MasterCard Directory Server
• You receive confirmation that the cardholder is not participating or has not yet enrolled
• The cardholder pop up or in-line window does not appear due to Issuer/Cardholder error
• The issuer service is not responding to your authentication request (i.e. the Authentication fails, but the transaction is authorised by the card Issuer).

MasterCard issuers do not currently send an UCAF for a successfully attempted authentication. PARes status = “A”

Failed Authentication:  In the event that the cardholder fails authentication by not entering the correct verification details and PayU will not process the financial transaction. PARes status = “N”. 

Authentication Failure

Typically, if a cardholder is registered for authentication they will be familiar with the process to correctly authenticate on the 3-D Secure authentication screen. There may, however, be occasions where the cardholder does not follow the correct process, or where a card is being used fraudulently.

The following scenarios may occur:

Scenario 1: The cardholder may fail to key in their correct password or one-time pin (maximum of three attempts), or

Scenario 2:

1. The cardholder may cancel the pop up or in-line window, or
2. The cardholder may close the pop up or in-line window, or
3. The pop up or in-line window may time out, or
4. The content of the window may be corrupt due to an issuer error
5. The cardholder browser may suppress the pop up.

The above scenarios can be described as:

• Failed Authentication (scenario 1)
• Error during Authentication (scenarios 2).

Visa and MasterCard:

If authentication fails (scenario 1), you will receive an “N” response within the PARes message. PayU RPP and API Services will decline the transaction automatically and stop further processing because the cardholder could not authenticate themselves.

In all of the scenario 2 cases the transaction will time out, not be processed and will have to be re-initiated. Typical transaction lookup responses may include “Timeout”, “MPI Pending”, or “Secure3D Processing”.

Error Conditions

In the unlikely event that you experience an error condition whilst using cardholder authentication, the merchant need to ensure that you can handle the responses.

Scheme Directory Server Unavailable (VEReq Failure)

You may see an error where the PayU Payment platform cannot connect to the relevant scheme directory. If this is the case, you will be sent a corresponding error message, which must be interpreted and handled appropriately.

If the directory server is unavailable, this is considered a “break” in the authentication process as neither a positive (success) or negative (failure) message can be supplied. As such, different liability shift rules apply:

Visa:

You can continue with the transaction, but an ECI 07 will be passed to the bank as this was a non-authenticated transaction. You will not benefit from liability shift to the issuer and therefore not receive any chargeback protection.

MasterCard

If you have correctly integrated the PayU RPP or Direct API service and get this error, you can claim Merchant UCAF and still receive liability shift (subject to the conditions in 3.4).

Please note: The PayU Payment platform will always process financial transactions based on your 3-D Secure Risk setting and in-line with scheme rules.

Authentication Service Unavailable (PAReq Failure)

If we are unable to authenticate transactions because the Hosted Authentication service is not operating, this is also perceived as a “break” in the process but has a different outcome. Transactions will not be authenticated if this service is down. You can continue with the transaction, but PayU will pass an ECI 07 for Visa or ECI 0 for MasterCard as this was a non-authenticated transaction. You will not benefit from any chargeback protection for either card scheme.

If the PayU Payment platform detects that the Hosted Authentication service is down it will process or fail transactions based on the PayU merchant risk configuration.

3-D Secure Authentication Capture Screen

When 3-D Secure Internet Authentication was first launched, most solutions used a browser pop up window to display the card issuer authentication page. Research has been undertaken by the card schemes to identify any problems relating to cardholders closing the window in the belief that it contained advertising. There was also the risk that the cardholder’s browser may have built in pop up killers/blockers to stop the window appearing.

As an alternative to pop up windows, PayU suggests using an in-line redirect to allow the card issuer details capture screen to appear in a full frame page. The full details of all the in-line options available to merchants are provided in the PayU Integration Guide. Never place this authentication screen in an iframe as some browsers view this as a security risk and this will result in poor user experience.

Please note: the PayU RPP (Redirect Payment Pages) use an in-line window and control the display of the window automatically on your behalf. This cannot be altered or customised.

How Do I Use the Service?

The PayU Payment platform is a transaction processing and fraud management engine. It offers a set of features that are available via two integration methods: an API direct integration (API DI) method (Enterprise service) or an API redirect payment pages (API RPP) method (Business or EasyMerchant service). Both of these integration methods are available via the PayU API set in order to facilitate the merchant's 3-D Secure authentication request, response call handling and transaction processing.

Please consult our website ( www.payu.co.za) for more information in regarding benefits of our Enterprise, Business and other services offered.

Please Note:

• Bank acquired merchants: 
  • You must have a valid Internet merchant relationship with us and be a PayU supported Acquirer to take full advantage of the service.
  • You must be registered with us to use cardholder authentication services and have integrated the authentication software into your chosen payment solution if required. Unless you specifically request an alternative, we will assume you wish to use authentication for all participating card schemes supported by us.

The following options are available to you:

• Use our integrated 3-D Secure Hosted Authentication service and PayU Enterprise Service (Direct API integration)
• Use our integrated 3-D Secure Authentication service and PayU Business or EasyMerchant Services (making use of PayU redirect payment page)

PayU Enterprise API Service

You must read this section if you are using the PayU Enterprise API Service with integrated 3-D Secure cardholder authentication. If you want to make use of the PayU Enterprise API Service, you will have to integrate additional software for cardholder authentication.

You must ensure that:

• If you have your own acquiring contract with a PayU supported acquirer (for clarification - all non PayU acquired merchants) that your processing account has been configured by your Acquirer to 3-D Secure Secure Internet Authentication.
• Your software supports redirecting the shopper to the card issuer and submitting a second API call to complete the payment.

Once you have successfully applied for the service we will activate the API Service to perform 3-D Secure authentication on all relevant transactions. Please note that your bank may instruct us to activate 3-D Secure that will result in process failures if the correct integration is not in place.

You must ensure that you have correctly integrated the PayU API in line with the instructions provided to you. Failure to do this may result in incorrect transaction processing.

Your Responsibilities

We control the authentication process within the PayU Enterprise API and will ensure that you have minimal disruption to your current transaction processing.

You must:

• Correctly integrate the PayU Enterprise API Service in line with instructions provided at sign up
• Read and understand how the PayU Enterprise API Service handles authenticated transactions – this information is provided in the integration guides
• Request Activation of the PayU Enterprise API 3-D Secure authentication service
• Advise us immediately if you cease using the PayU Enterprise API Service
• Request us to configure “3-D Secure Risk Options” within PayU appropriately to suit your risk policy **

Our Responsibilities

We will:

• Provide you with the PayU Enterprise API Service integration guide
• Configure PayU Enterprise API Service to allow your transaction process to 3-D Secure authenticated transactions
• Control the processing of 3-D Secure authentication transactions
• Adhere to relevant card scheme policies
• Process transactions accordingly for “failure” scenarios in line with your configuration requirements for the PayU Enterprise API Service
• Maintain a full audit trail and provide transaction evidence to the card issuer in the event of a chargeback where we believe authentication was correctly performed and where liability shift is available
• Ensure the correct authentication values are attached to both the authorisation and clearing message where appropriate.

PayU Redirect Payment Page (RPP) Services

You must read this section if you are using the PayU Redirect Payment pages (RPP) with integrated cardholder authentication. The RPP is a fully hosted payment and authentication service and typically available with PayU Business or EasyMerchant Service offerings.

If you use the RPP service you will not have to integrate any additional software for cardholder authentication. Once you have successfully applied for the service we will activate the RPP to perform 3-D Secure authentication on all relevant transactions.

Although the RPP service requires no specific authentication integration, you must ensure that you have correctly integrated the RPP service in line with the instructions provided to you. Failure to do this may result in incorrect transaction processing.

Your Responsibilities

We control the authentication process within the RPP service and will ensure you have minimal disruption to your current transaction processing.

You must:

• Correctly integrate the PayU RPP service in line with instructions provided at sign up
• Read and understand how the PayU RPP service handles authenticated transactions – this information is provided in the integration guide
• Request us to configure “3-D Secure Risk Options” within the PayU RPP service to suit your risk policy **
• Request Activation of the PayU RPP service
• Advise us immediately if you cease to use the PayU RPP service
• Check to ensure that the correct Authentication values are associated with your transactions

Our Responsibilities

We will:

• Provide you with the PayU RPP integration guide
• Control the processing of 3-D Secure authentication transactions
• Adhere to relevant card scheme policies
• Process transactions accordingly for “failure” scenarios in line with your configuration requirements for the PayU RPP service **
• Maintain a full audit trail and provide transaction details to you and acquirer with evidence in the event of a chargeback where we believe authentication was correctly performed and where liability shift is available.
• Ensure the correct authentication values are attached to both the authorisation and clearing message where appropriate.

High Level Overview of 3-D Secure Transaction Process

The following diagram illustrates the communication between all parties involved in the 3-D Secure transaction flow. This example assumes that the cardholder is already enrolled.

3D Secure Transaction Process Diagram:

3-D Secure Transaction Flow:

When a shopper submits an order at a participating online shop, the following process is triggered:

Step 1: A cardholder (Shopper) browses the merchant site, adds items to the shopping cart and finalizes his/her purchase.

Step 2: The Merchant invokes PayU API web service call with the required transaction data to start the 3-D Secure transaction process. The transaction details that are provided depend on the integration method used:

i. PayU Enterprise Service (API Direct Integration Method): Payment card details including card number captured on merchant software and sent through to PayU Payment platform as part of API call.

ii. PayU Business/EasyMerchant (API Redirect Page Method) Merchant Software redirects cardholder to the PayU hosted payment page. The cardholder then enters payment card details (including card number) on the PayU hosted payment page.

Step 3: The PayU Payment platform verifies if the merchant is 3-D Secure enabled. If the Merchant is 3-D Secure enabled, the PayU Payment platform performs a 3-D Secure Verify Enrollment Request (VEReq) by sending the relevant transaction data (including the card number) to the 3-D Secure Directory Server.

Step 4: If the card number is in a participating card range, the Directory Server queries the appropriate Issuer Access Control Server (ACS) to determine whether the card number is enrolled or not.

Step 5: ACS responds to Directory Server with 3-D Secure Verify Enrolment Response (VERes), indicating whether the card number is enrolled and if authentication is available for the card number.

Step 6: Directory Server forwards VERes response to PayU Payment platform.

Step 7a: Card Not Enrolled VERes = N or 3-D Secure Not available VERes = U

i. PayU Enterprise Service (API Direct Integration Method): PayU’s Payment platform process the transaction to the Acquirer based on the 3-D Secure risk setting and returns the transaction result via API to the Merchant software.

If the online merchant 3-D Secure risk is set to:

• • • Process fully authenticated transactions only, the transaction ends and is not processed for funds authorisation. Result = Failed
    • Process all transactions:, the transaction process continues and the transaction is sent to bank for funds authorisation.

ii. PayU Business/EasyMerchant (API Redirect Page Method): PayU’s Payment platform redirects back to the Merchant software via a redirect post. The Merchant software is required to perform a PayU API get transaction call to obtain a transaction result set.

If the online merchant 3-D Secure risk is set to:

• • • Process fully authenticated transactions only, the transaction ends and is not processed for funds authorisation. Result = Failed
    • Process all transactions, the transaction process continues and the transaction is sent to the bank for funds authorisation.

Step 7b: Card Enrolled

i. PayU Enterprise Service (API Direct Integration Method):  PayU’s Payment platform responds to the Merchant software with a 3-D Secure Javascript code snippet containing two fields which are specific to the 3-D Secure process: <PAReq> and <AcsUrl>.

The merchant software invokes a Secure Javascript code snippet that sends an HTTP POST Payment Authentication Request (PAReq) to the cardholder, which invokes an inline window in the cardholder's browser. Included in the message is a third field called <TermUrl>, which points back to PayU where the Issuer will later sends the Payment Authentication Response (PARes) message to.

ii. PayU Business/EasyMerchant (API Redirect Page Method): PayU’s Payment platform invokes a Secure Javascript code snippet that sends an HTTP POST Payment Authentication Request (PAReq) to the cardholder, which invokes an inline window in the cardholder's browser. Included in the message is a third field called <TermUrl>, which points back to PayU where the Issuer will later send the Payment Authentication Response (PARes) message to.

Step 8: The cardholder's browser redirects the PAReq message to the issuer's Access Control Server (ACS) which authenticates the cardholder. The cardholder's browser sends an HTTPS request to the ACS. The server parses the data and either invokes;

i. Login page in the cardholder's browser (pop up or inline window). The cardholder now enters a password in the browser window and returns the data to the ACS; or

ii. One-Time-Pin (OTP) page in the cardholder's browser (pop up or inline window). The cardholder now enters the OTP that was sent to the cardholders registered mobile device in the browser window and returns the data to the ACS.

Step 9: Having received the data, the ACS authenticates the cardholder's password or OTP, constructs the Issuer Authentication Value (IAV), and creates an SSL-encrypted and digitally signed Payer Authentication Response (PARes). Encryption and signature ensures that the cardholder cannot modify the content of the message on its way to the merchant.

ACS sends a copy of the PARes to the Authentication History Server.

Step 10: The Payment Authentication Response (PARes) is posted by the ACS to the PayU web address (<TermUrl>) via the cardholder's browser.

Step 11a: Payer successfully authenticates:

The PayU Payment platform processes the transaction to the Acquirer containing the 3-D Secure data elements (PARes Status, Signature Verification and IAV).

Step 11b: 3-D Secure attempted PARes = A or 3-D Secure Not available PARes = U

If the online merchant’s 3-D Secure risk is set to:

• • Process fully authenticated transactions only, the transaction ends and is not processed for funds authorisation. Result = Failed
  • Process all transactions, the transaction process continues and the transaction is sent to the bank for funds authorisation.

Step 11c: Failed authentication PARes = N. Transaction failed and not processed.

Step 12: The Acquirer processes the transaction and responds to the PayU Payment platform with transaction result.

Step 13: The PayU Payment platform redirects back to the Merchant Software via a redirect post.

Step 14: The Merchant Software performs a PayU API get transaction call to obtain the transaction result set. Transaction flow ends.

3-D Secure OTP Screens

The images below depict the typical shopper payment experience with both the cardholder’s card and the merchant enrolled in the 3-D Secure program making use of the OTP authentication process.(not actual screenshots)

The results of all 3-D Secure transactions reflect in PayU’s transaction reports.

Liability Shift Explained

The liability shift is indicated by an Electronic Commerce Indicator (ECI) and indicates the security level applicable to the Card Not Present (CPN) or eCommerce transaction.

Possible ECI values are:

MasterCard:

ECI 01:     MasterCard SecureCode only: This value is set by the merchant in a MCSC authentication when the merchant attempted to authenticate the cardholder using 3-D Secure. The issuer or cardholder is not participating.

ECI 02:     MasterCard SecureCode only: This value is set by the ACS in a MCSC Payer Authentication Response (PARes) message. The cardholder successfully passed 3-D Secure payment authentication.

Visa:

ECI 05:     Verified by Visa only: This value is set by the ACS in a VbV Payer Authentication Response (PARes) message when the cardholder successfully passed 3-D Secure payment authentication.

ECI 06:     Verified by Visa only: This value is set by the merchant in a VbV authentication when the merchant attempted to authenticate the cardholder using 3-D Secure, but the issuer or cardholder is not participating.

ECI 07:     Verified by Visa only: This value is set by the merchant when the payment transaction was conducted over a secure channel (for example, SSL/TLS), but payment authentication was not performed, or when the issuer responded to the PAReq with an "Unable to Authenticate" code (for example, the ACS was unable to match the account ID from the PAReq to the corresponding VEReq, or payment authentication was attempted on an excluded channel or product).

PayU 3-D Secure Risk Setting

The PayU Payment Platform allows for the following 3-D Secure risk settings and indicates the level of fraud risk (chargeback risk) the merchant wants to accept.

Please note:

• Bank acquired merchants: not all risk settings are available with all banks and it is advised to contact your bank if an increased risk setting will be allowed for your merchant account.
• PayU acquired merchants: not all risk settings are available to all merchants and the risk setting will depend on the results of the risk assessment done by PayU.

The columns related to the PayU Risk setting  (Liability Shift Matrix) describe the selected 3-D Secure Risk Setting and outline if the transaction will be processed or declined by the PayU Platform based on the 3-D Secure indicators returned. Where;

• Y = Yes: Transaction will be processed
• N = No: Transaction will not be processed

PayU 3-D Secure Risk Options:

1=Low Risk: Process ONLY FULLY Authenticated Transactions.
This risk setting provides the greatest degree of protection against chargeback risk. The PayU Payment platform will only process fully authenticated 3-D Secure transactions where the liability shifts to the issuer. 

2=Medium Risk: Process transactions as per PASA guideline. (Issuer accepts chargeback risk)
This risk setting will allow all transactions to be processed in line with the card scheme rules. Chargeback liability will remain with the issuer with some exclusions like international BIN as example that might not be subject to issuer risk.

3=High Risk: Process all transactions excluding authentication failures.
With this risk setting the merchant accepts all chargeback liability and is not recommended. Should this risk setting be used it is strongly recommended to combine it with a fraud checking service to mitigate risk. For more information on PayU's fraud risk engine via ReD please contact PayU sales.

Liability Shift Matrix

[1] Please note: In these cases the liability shift is either with you or the issuer. Currently, we are unable to accurately determine if the risk shift will take place or not.

In general, you will not be able to claim liability shift and the chargeback remains with you, should you elect to process the transaction for:

-          All non-enrolled Visa and MasterCard cards issued in the United States of America
-          All non-enrolled Visa and MasterCard issued commercial (corporate, business and purchasing) cards.

E&OE