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

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 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 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 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 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
VER
es
PARe
s
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
Master
Card
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

More Related Content

What's hot

Similar to PayU 3D Secure Merchant Guide

Recently uploaded

PayU 3D Secure Merchant Guide