Table of Contents
- Overview
- Prerequisites
- How does 3D Secure work?
- Gateway Requirements for Payer Authentication 2.0
- How to Enable Payer Authentication 2.0 for your Merchant
- What is the Path of a Payer Authentication Transaction?
- Test Payer Authentication 2.0 Transactions in Test Mode
Overview
Payer Authentication 2.0 protects merchants and consumers from unauthorized transactions by further validating the cardholder’s identity using 3D Secure. Enable Payer Authentication 2.0 today to reduce your fraud risk and increase customer confidence with 3D Secure for ecommerce payments. Learn more on how 3D Secure works, the gateway requirements, and how to enable Payer Authentication 2.0 for your merchants.
Prerequisites
Your affiliate sub-users will need the 'Manage merchant accounts' permission to be able to enable Payer Authentication 2.0 for merchants; this also applies to your Sub-Affiliate sub-users so they can enable Payer Authentication 2.0 for their merchants. Primary users have this permission set by default and it cannot be removed.
If you don't have Payer Authentication 2.0 in your Partner Portal Marketplace Apps and want it enabled to be able to resell this service to your merchants, please have your Primary Contact (the person who is listed under Settings → Account Information → Primary Contact) reach out to support@nmi.com to request for it to be added to your Partner Portal.
Please check the Processor Matrix to see a full list of supported processors that can be used with Payer Authentication 2.0. Log in to your Partner Portal and head over to the left side panel → at the bottom, click on Help → click on Processor Matrix. Click on the "Payer-Auth 2.0" column to bring them to the top.
How does 3D Secure work?
3D Secure is an eCommerce specific fraud prevention tool. Cardholders can sign up with their bank to create a password (or ‘secure code’) and assign it to their credit card. When a customer is checking out, a check is done to see if the customer's bank participates in 3D secure. If so, the merchant is provided some chargeback protection using a liability-shift similar to EMV. If the customer is enrolled, the issuer will either authorize the payment without challenging the cardholder (frictionless-flow) or challenge the cardholder (step-up) to provide additional information to authenticate the transaction, for example, entering a one-time passcode sent to their mobile device.
Traditionally this was a password the customer would create when they enrolled, but over time this has changed, and sometimes other personal data may be requested by the bank or a SMS code/verification code could be requested depending on each card brands 3D Secure requirements. This helps verify that the customer checking out on the website is the customer who owns the card, thus reducing fraud.
The goal is Authentication - Verifying the Identity of the Cardholder.
Gateway Requirements for Payer Authentication 2.0
What you need to know before enabling Payer Authentication 2.0 for your merchant:
- We need the merchant's website address (URL) and the Acquiring Bank to enroll a merchant.
- Why do I need a website in order to use Payer Authentication? - it provides verification to the consumer that the website they've been redirected to is associated with the merchant they're making the purchase from and it's not some phishing attempt. It's unusual for an eCommerce merchant not to have a website. They might want to consider using a free website builder with basic information on it. That way they may generate some business if someone finds it. If the merchant does not have an official website, they can provide a Collect Checkout or QuickClick link as well. A website is required for enrollment but not essential in the verification process.
- 3D Secure is only available for eCommerce merchants. It cannot be used for retail or MOTO transactions.
- The merchant account will need to have an active credit card processor that supports Payer Authentication 2.0 and the Processing Service has to be set to eCommerce classification.
- Payer Authentication is supported by the hosted checkout page, Collect Checkout, as well as custom API integrations via Gateway.js. Full documentation can be found in the Integration Portal.
- To use our Payer Authentication service, the merchant must use at least one of the following integration methods: Payment API with Gateway.js (preferred), Three Step Redirect API, Collect Checkout (Button Generator with 3DS flag checked), or QuickClick (Button Generator, Build a Button). These options allow us to redirect the customer into the payer authentication service.
- Invoicing supports 3DS through the use of QuickClick.
- For Merchants in the UK and Europe - please see PSD2 - Strong Customer Authentication (SCA) & What It Means to You, to learn more on the introduction of additional authentication of transactions, known as Strong Customer Authentication (SCA) and the means of achieving SCA.
What Payer Authentication 2.0 will NOT work with:
Payer Authentication 2.0 will NOT work unless a supported integration method is used in the solution.
- If using a THIRD PARTY service for 3DS verification (for example PAAY), use the variables under Payment API, in the Integration Portal, to pass the data into the gateway for processing. Again, it is important to ensure the client is on a supported processor.
How to Enable Payer Authentication 2.0 for your Merchant
To enable Payer Authentication 2.0 for your merchant, log in to your Partner Portal and head over to List Accounts → Merchant Accounts → scroll to the merchants name from the list or search their name in the search box → click on their name → scroll down to the Value-added Services section click on Add/Edit → check off Payer Authentication 2.0 → click Submit.
Once you click Submit, this will start the enrollment process. You will receive a "3D-Secure / Payer Authentication Information Request" email notification for required information to enroll the merchant in the service.
- Merchant's website address (URL)
- Acquiring bank name
- Acquiring bank's VISA BIN (first 6-8 digits, starts with a 4. ICA IS NOT ACCEPTED)
- Acquiring bank's MasterCard BIN (first 6-8 digits, starts with a 5 or 2. ICA IS NOT ACCEPTED)
- Requestor Category Code (For VISA/MC, this is usually the same as the Merchant Category Code entered on the MID)
- Requestor Name (For VISA/MC, this is usually the merchant's full business name)
- Requestor ID (For VISA/MC, this is usually the same MID number used for the processing platform)
If your merchants acquiring bank accepts other card brands' 3D Secure other than the ones listed in the email notification, please let our support team know in your reply to have them enrolled.
The service will remain in Pending status until we confirm activation. Once everything is set, you will receive an activation confirmation email notification and the service will be in Active status on the Gateway.
Once Payer Authentication 2.0 is activated, your merchant will have the option to set Payer Authentication Rejection Rules in their Merchant Portal → Settings → listed under Security Options. These rules allows the merchant to choose when to reject transactions based on Payer Authentication results.
What is the Path of a Payer Authentication 2.0 Transaction?
Transactions from your system are routed to both the card associations, as well as the banking authentication networks via an Internet connection through the Payment Gateway. This authentication information can be accessed in real-time through the gateway's comprehensive reporting system, allowing you to easily identify authenticated transactions and recognize fraudulent ones. Enabling authentication does not interrupt the current authorization process.
- During checkout, information about the cardholder is directed to the appropriate card association to check their program enrollment status.
- If the cardholder is enrolled, an authentication form (3D Secure page) will be displayed by the cardholder’s bank. This form will collect the password or SMS code/verification code and the bank will validate if it is correct.
- Results of authentication are returned in less than one second. The results, new data elements, are proof that the merchant authenticated or attempted to authenticate the cardholder.
- The transaction is then sent for authorization through typical processes and channels. The data variables (CAVV, DSTID, and ECI) are also submitted during the authorization request, thus providing the appropriate benefits associated with 3D Secure.
-
The Cardholder Authentication variable will tell you the status of the 3DS authentication.
- Protected - you may see Verified Protected when an “approved” cavv_result code was received from the processor or received a CAVV value associated with the transaction. Note, not all processors provide this.
- DSTID would be the 3DS Directory Server Transaction Id.
- Please see 3-D Secure Variables for more information and descriptions on these variables.
-
The Cardholder Authentication variable will tell you the status of the 3DS authentication.
Test Payer Authentication 2.0 Transactions in Test Mode
Payer Authentication 2.0 can be tested when a merchant account is in Test Mode AND the merchant account has the Payer Authentication 2.0 service active on their merchant account. When a merchant toggles themselves into Test Mode, they can run test transactions that will use test credentials for the Payer Authentication 2.0 service they have active. Test Data can be found in the Integration Portal.
***PLEASE NOTE*** Transactions ran in Test Mode DO NOT process at the Bank and the Merchant will NOT be funded. The test transactions in Test Mode are not live and are not sent to a real processor. Keep in mind, once you are done with Test Mode, you have to "Disable Test Mode" before going live/start to process real transactions.