payu 3d secure merchant guide

3D Secure™ Merchant Guide

3D Secure™ Merchant Guide | V1.6 Page | 1

Copyright © 2013 PayU Payment Solutions (Pty) Ltd. – Proprietary & Public E&OE

Table of Contents

Table of Contents ........................................................................................................................................ 1

1 Introduction ........................................................................................................................................ 2

2 What is 3D Secure™? .......................................................................................................................... 2

3 3D Secure Authentication Information ............................................................................................... 3

3.1 The Key Benefit of Authentication: Liability Shift .............................................................................. 3

3.2 Chargeback Reason Codes Included .................................................................................................. 3

3.3 Card Enrolled for 3D VS Card Not Enrolled ........................................................................................ 4

3.4 3D Secure Authentication ................................................................................................................. 5

3.5 Authentication Failure ...................................................................................................................... 6

3.6 Error Conditions ............................................................................................................................... 6

3.6.1 Scheme Directory Server Unavailable (VEReq Failure) ................................................................... 7

3.6.2 Authentication Service Unavailable (PAReq Failure) ...................................................................... 7

3.7 3D Secure Authentication Capture Screen ........................................................................................ 7

4 How Do I Use the Service? .................................................................................................................. 8

4.1 PayU Enterprise API Service .............................................................................................................. 8

4.2 PayU Redirect Payment Page (RPP) Services ..................................................................................... 9

5 High Level Overview of 3D Secure Transaction Process .................................................................... 10

5.1 3D Secure Transaction Process Diagram: ........................................................................................ 11

5.2 3D Secure Transaction Flow:........................................................................................................... 11

5.3 3D Secure OTP Screens ................................................................................................................... 13

6 Liability Shift Explained ..................................................................................................................... 14

6.1 Possible ECI values are: .................................................................................................................. 14

6.2 PayU 3D Secure Risk Setting** ....................................................................................................... 14

6.2.1 PayU 3D Secure Risk Options: ..................................................................................................... 15

6.3 Liability Shift Matrix ....................................................................................................................... 15

Glossary & Terminology ............................................................................................................................ 16

Appendix A – Managing Internet Fraud ‘Best Practice’ ............................................................................. 18



1 Introduction

This guide gives you all the information you need to use for bank cardholder authentication during online transactions. It details your roles and responsibilities, our roles and responsibilities and some key information required 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.

2 What is 3D 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.

3D 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 3D 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 3D 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 3D 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 3D 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 3D Secure and the common protocol.

3 3D 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 3D Secure protocol supporting authentication.

3.1 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 3D 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 prevent chargebacks where cards are used fraudulently, or where the cardholder denies using the card. The liability shifts from you, back to the card Issuer.

Minimising the risk of fraud is essential and 3D 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.

3.2 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:

75 Transaction not recognised – when the cardholder advises that they do not recognise an item on their card statement. This does not apply to transactions with an ECI 5 or 6 values.

85 The card was NOT present and a transaction was processed without cardholder permission, or a fictitious (card) account number was used and transaction was not authorised (a fraudulent transaction).

MasterCard:

37 The cardholder denies responsibility for the transaction or the acquirer lacks evidence of a cardholder’s authentication (i.e. signature).



63 When a cardholder claims he or she does not recognise a non-face-to-face transaction (such as an eCommerce transaction). If after being presented with new information, the cardholder asserts that he or she did not authorise the transaction.

Note: You may be asked to provide supporting information to us to defend a transaction (see section on Retrieval Requests). Protection against this reason code may help to avoid a chargeback following such a request.

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.

3.3 Card Enrolled for 3D VS Card Not Enrolled

Card issuers are in the process of enrolling all cards issued to cardholders to participate in 3D 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 3D Secure the issuer responds with “Y” and the cardholder authentication process begins. VERes status = “Y”

Card Not Enrolled = N: Not enrolled cards respond with “N” and the transaction can be processed. Whether or not a liability shift to issuer takes place will depends on the card type and the card issuer region. VERes status = “N”

The chargeback liability is with the issuer for not enrolled cards providing that the merchant is enrolled and card was correctly checked for enrolment. Some exceptions may exist for international issued cards.

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 MasterCard guideline: the risk is with the issuer and processing can proceed. VERes status = “U”

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.



3.4 3D Secure Authentication

Once the Card Enrolment check is complete and the card is enrolled, PayU will then redirect the shopper to an external bank hosted page for cardholder authentication. After entering a one-time pin/password, PayU will process a 3D 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 3D Secured 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”

Unable to Complete Authentication = U: Authentication requests sent but is unable to be completed. PARes status = “U”

Successful Attempted Authentication = A: Authentication request sent successfully but the cardholder could not be authenticated. PARes status = “A”

The card schemes differ with their support of “U” and “A” responses re 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 3D 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.

You can claim attempted authentication on a MasterCard SecureCode™ transaction when you make any attempt to authenticate the cardholder. Ideally, you should receive a 3D 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 the transaction will not be processed. See 3.5, PARes status = “N”

3.5 Authentication Failure

Typically, if a cardholder is registered for authentication they will be familiar with the process to correctly authenticate on the 3D 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 reinitiated. Typical transaction lookup responses may include “Timeout”, “MPI Pending”, or “Secure3D Processing”.

3.6 Error Conditions

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



3.6.1 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 7 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 transactions based on your 3D Secure Risk setting and in line with scheme rules.

3.6.2 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 7 for Visa or ECI 1 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 transactions based on your configuration of the 3D Secure risk setting.

3.7 3D Secure Authentication Capture Screen

When 3D 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 most 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.



4 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 3D 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 3D Secure Hosted Authentication service and PayU Enterprise Service (Direct API integration)

• Use our integrated 3D Secure Authentication service and PayU Business or EasyMerchant Services (making use of PayU redirect payment page)

4.1 PayU Enterprise API Service

You must read this section if you are using the PayU Enterprise API Service with integrated 3D 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 support 3D 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 3D Secure authentication on all relevant transactions. Please note that your bank may instruct us to activate 3D 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.

http://www.payu.co.za/



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 3D Secure authentication service • Advise us immediately if you cease using the PayU Enterprise API Service

• Request us to configure “3D Secure Risk Options” within the PayU RPP 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 3D Secure authenticated

transactions • Control the processing of 3D 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.

4.2 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 3D 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 “3D 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 3D 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.

5 High Level Overview of 3D Secure Transaction Process

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



5.1 3D Secure Transaction Process Diagram:

5.2 3D 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 3D 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 3D Secure enabled. If the Merchant is 3D Secure enabled, the PayU Payment platform performs a 3D Secure Verify Enrolment Request (VEReq) by sending the relevant transaction data (including the card number) to the 3D 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 3D 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 3D 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 3D Secure risk setting and returns the transaction result via API to the Merchant software.

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

o Process fully authenticated transactions only, the transaction ends and is not processed for funds authorisation. Result = Failed

o 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 3D Secure risk is set to:


o 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 3D Secure Javascript code snippet containing two fields which are specific to the 3D 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. a 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. a 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 3D Secure data elements (PARes Status, Signature Verification and IAV).

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

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


o 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.

5.3 3D Secure OTP Screens

The images below depict the shopper's payment experience with both the cardholder’s card and the merchant enrolled in the 3D Secure program making use of the OTP authentication process.



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

6 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) ecommerce transaction.

6.1 Possible ECI values are:

MasterCard:

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

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

Visa:

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

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

ECI 7: 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).

6.2 PayU 3D Secure Risk Setting**

The PayU Payment Platform allows for the following 3D 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 in section 6.3 (Liability Shift Matrix) describe the selected 3D Secure Risk Setting and outline if the transaction will be processed or declined by the PayU Platform based on the 3D Secure indicators returned. Where;

• Y = Yes: Transaction will be processed

• N = No: Transaction will not be processed



6.2.1 PayU 3D Secure Risk Options:

1=Process all transactions. (Merchant accepts chargeback risk)**

This risk setting will allow all transactions to be processed in line with the card scheme rules. Liability will in some instances remain with the Acquirer and you will be liable for chargebacks in these instances (as set out in this document).

2=Fully 3D Secure authenticated transactions only**

This risk setting provides the greatest degree of protection against chargeback risk. The PayU Payment platform will only process fully authenticated 3D Secure transactions where the liability shifts to the issuer.

6.3 Liability Shift Matrix

Card Type

VERes

PARes

UCAF (CAVV - AAV)

ECI

PayU Risk Setting Description Chargeback Liability with

1 2

Visa

Y Y YES 05 Y Y 3DS Fully authenticated Issuer

Y N 07 N N 3DS authentication failed Failed

Y U NO 07 Y N 3DS Authentication unavailable Merchant

Y A YES 06 Y N 3DS Authentication attempted Issuer/Merchant [1]

N NULL N/A 06 Y N 3DS Card not enrolled Issuer/Merchant [1]

U NULL N/A 07 Y N 3DS Unavailable Merchant

MasterCard

Y Y YES 02 Y Y 3DS Fully authenticated Issuer

Y N NO - N N 3DS Authentication failed Failed

Y U NO 06 Y N 3DS Authentication unavailable Merchant

Y A YES 01 Y N 3DS Authentication attempted Issuer/Merchant [1]

N NULL N/A 06 Y N 3DS Card not enrolled Issuer/Merchant [1]

U NULL N/A 06 Y N 3DS Unavailable but attempted Issuer/Merchant [1]

[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.



Glossary & Terminology

3D Secure, 3DS or 3D 3 Domain Secure. E-commerce environment including Acquirers/Merchants, Issuers/cardholders and Card Schemes.

AAV Accountholder Authentication Value. This is the unique reference generated by MasterCard and Maestro card issuers to prove authentication took place.

ACS Access Control Server. This is the card Issuer system used to record which cardholders are registered.

AHS Authentication History Serve is operated by Visa and stores a copy of the 3D Secure transaction data for use by Visa, Acquirers and Issuers in case of a dispute.

API PayU Application Programme Interface.

CAVV Cardholder Authentication Verification Value. This is the unique reference generated by Visa card issuers to prove authentication took place or was attempted.

Acquirer The Acquirer is the bank of the merchant. It is in the acquirer's interest that all e-commerce transactions between the cardholder and the merchant are 3D Secure enabled. The Acquirer is responsible for encouraging the merchants to enrol for the 3D Secure service and assigns and manages merchant IDs, passwords, or certificates needed to authenticate the merchants in the system. The Acquirer therefore determines the Merchant’s eligibility to participate in the 3D Secure process or not.

Cardholder The 3D Secure process starts with the cardholder (shopper) when he/she makes an online purchase. To the cardholder, the 3D Secure transaction is almost transparent and not very different from an ordinary e-commerce transaction. At checkout, when he/she enters payment card data and clicks to pay, the software verifies if the cardholder is registered and if so starts the 3D secure authentication process. In response to the Purchase Authentication Page, the cardholder provides authentication information such as a password or OTP.

CRReq Card Range Request. 3D Secure Protocol message type.

CRRes Card Range Response. 3D Secure Protocol message type.

Directory Server The Directory Server determines whether a card number is participating in the 3D Secure process and directs the request for cardholder authentication to the appropriate ACS or responds directly.

ECI E-commerce Indicator. This provides the security level used in an internet transaction.

HPP PayU Hosted Payment Page.

IAV Issuer Authentication Value. This is a generic term that corresponds to either the Visa CAVV or MasterCard AAV.

ISP Internet Service Provider.

MasterCard Directory A system operated by MasterCard that determines whether a specific issuer and



card number is participating in authentication, and if so, it returns the URL of the appropriate Access Control Server to the Merchant Plug-in.

Issuer The issuer is the cardholder’s bank that issued the payment card. The Issuer defines the range of card numbers that are eligible for the 3D Secure programme and enrols the card numbers for 3D Secure processing.

Merchant Plug-in Generic term used to describe the SDK.

PAReq Payer Authentication Request. This is a 3D Secure Protocol message type.

PayU API The Merchant Server Software calls the PayU API (via a XML or SOAP request) to create and process a payment authentication message to the PayU Payment platform and returns control to the Merchant Software with 3D Secure authentication or transaction results.

Pop Up Internet browser pop up window displayed within the main browser page.

PSP Payment Service Provider. Companies who offer internet transaction routing to acquirers.

RFI Requests for Information. Also known as retrieval. A separate process to a chargeback used by card issuers to obtain further transaction information.

SecureCode™ SecureCode™. This is a cardholder authentication scheme for MasterCard and Maestro cards.

UCAF Universal Cardholder Authentication Field. This is the data field used by MasterCard and Maestro issuers to send the AAV (see above).

VbV Verified by Visa. This is the cardholder authentication scheme from Visa.

VEReq Verify Enrolment Request. 3D Secure Protocol message type.

VERes Verify Enrolment Response. 3D Secure Protocol message type.

We, us PayU Payment Solutions (Pty) Ltd

XID Transaction Identifier

** Future functionality – Where ** indicates that this functionality is planned or under development.



Appendix A – Managing Internet Fraud ‘Best Practice’

In the physical, traditional retailing world, where the cardholder and card are both present at the point of sale, merchants can adopt measures to confirm that the genuine cardholder is making the purchase. These include:

Talking to the customer if the order is suspicious

Checking the card signature on the card with the signature on the receipt

Chip & PIN utilisation

Name awareness – i.e. Mr P Smith embossed on the card being presented by a female

Other forms of identification may be requested.

Taking card payments over the internet means that none of these checks can be carried out at the time of the transaction, because the process is fully automated and therefore no manual intervention can take place. However, you will have collected information about the customer and their purchase on the order and payment pages of your website, which will help you to take measures to reduce the threat of chargebacks and stolen goods.

There are some simple questions you can ask yourself about customer not present orders:

Is the sale too easy? Is the customer uninterested in the price or details of the goods?

Are they a new customer?

Are the goods high value or easily resalable?

Is the sale excessively high in comparison with your usual orders?

Is the customer ordering many different items? Are buying patterns unlike your average customer?

Is the customer providing details of someone else’s card and not using his/her own card to make the purchase (e.g. that of a client or a family member)?

Is the customer reluctant to give a landline contact phone number and only prepared to give a mobile number?

Does the address provided seem suspicious?

Has the delivery address been used before with different customer details?

Is the customer being prompted by a third party whilst on the phone (if a telephone order)?

Is the customer attempting to use more than one card in order to split the value of the sale?

Does the customer seem to lack knowledge of their account?

Does the customer seem to have a problem remembering their home address or phone number?

Does the customer sound as if they are referring to notes?

Have they used a free email address such as @hotmail.com or an email forwarding address?

Does the email address match the name of the cardholder?

Has the customer email bounced?



There are a number of tools that you can use to verify these questions, for example, Internet Authentication, Address Verification Service and Card Security Code checking service.

3D Secure Internet Authentication: is an industry-wide initiative to fight fraud and protect businesses trading over the internet. It allows Visa card and MasterCard issuers to ask their cardholders for a password before purchasing online. This will automatically verify their identity and authenticate the card, so you can accept their payment with confidence.

Card Security Code checking: this service works by checking that the unique 3 digit code on the rear of most cards, and 4 digit code on the front of American Express cards match the details held by the card Issuer.

PayU Fraud Management Service (via ReD): This provides customized and or standard rules, lists and default checks that can be used to try and identify and alert you to potentially fraudulent transactions.

Risk Management systems, such as that offered by PayU, can help you to recognise and hopefully remove fraudulent transactions from being processed through your business.

No Risk Management system can definitively determine whether any given transaction is, in fact, fraudulent. Therefore, fraud protection systems can form only one part of a comprehensive business decision-making process that involves human oversight and investigation of each transaction in question.

payu 3d secure merchant guide

Economy & Finance