One increasingly common question we get here is “How can I as a developer integrate 3-D Secure Payer Authentication with the Authorize.Net system”. Another related question we get is “What the heck is 3-D Secure Payer Authentication?” If you’ve ever had either question, good news! You’ll get answers to both questions in this blog post. In addition, you’ll become familiar with one of the newest members of the Visa family, CardinalCommerce, a leading provider of solutions for Payer Authentication.
The concept of authentication is to provide the payer (the cardholder – the one making the transaction) with a means to authenticate themselves with their issuing bank to prove that they are, indeed, authorized to use the card. Elements like the card security code on the cards themselves are used to verify that the card is physically present, but they won’t prove that the card is actually being held in the hands of an authorized user. Payer Authentication goes further to show that the cardholder themselves is actually approving the transaction.
For a merchant, having this kind of proof is enormously beneficial. It doesn’t just provide the merchant with a warm feeling that the risk of fraud is low. There’s an actual liability shift that takes place with a payer authenticated transaction, such that liability for any fraud related chargeback rests with the issuer, and can’t be applied to the merchant.
This Payer Authentication is done using a protocol called “3-D Secure”, which specifies communication between three domains (hence the “3-D”). These are the acquiring domain (the merchant, the merchant’s bank), the issuing domain (the bank issuing the customer’s card), and any other components in an “interoperability domain”. The actual verification of the cardholder is historically completed by asking the cardholder for a password that they’ve previously set up with their issuing bank. However, the past 4 years have introduced Issuer Risk-Based authentication, which provides a silent user experience upwards of 60% of the time, as the bank makes an informed risk decision on the transaction behind the scenes and only steps up authentication on the riskiest of transactions. Other methods like SMS verification codes and biometrics improve user experience and forgo the cardholder having to remember a password.
The actual implementation of the 3-D Secure protocol a standard, implemented the same way by different card networks, but with the card networks creating slightly different programs and benefits. Visa calls their implementation “Verified by Visa”. Mastercard calls theirs “Mastercard SecureCode”. American Express, Discover, and JCB each have their own implementations.
For you the developer, the actual card network used won’t matter because the implementation details through the Cardinal Cruise service will be the same with each.
3-D Secure requires a piece of software called an MPI (merchant plug-in) to do the actual communication to the card brands and handling the signing of requests and responses.
You, the developer, provide the MPI with the details of the transaction that’s about to occur, like the card number and amount. The MPI contacts a lookup server at the specific card brand to find out if that specific card is enrolled in one of these authentication implementations, then responds to you with the results.
The MPI will generally indicate one of two responses, either that the card is enrolled in the authentication service, or that it isn’t. If the card isn’t enrolled, or if it isn’t enrolled because the issuer isn’t participating, all is not lost. In some cases, just the fact that you attempted authentication qualifies you for the liability shift, as long as you pass the data you received in this response with the transaction. If the issuer is participating and the card is enrolled, the response back from the MPI includes information to redirect the customer to the actual authentication page run by their bank if a direct interaction is necessary. Again, for upwards of 60%, the user will just see a quick processing page with zero interaction.
After the cardholder's authentication session ends with the bank, the cardholder’s browser will be redirected back to a page on your site, returning some data back to you that you’ll use in the subsequent transaction.
When you do a transaction with Authorize.Net, this data that you’ve received back after the customer authenticates will include a signed message indicating whether the authentication was successful. If you send this data in the Authorize.Net transaction (and it shows the payer was authenticated), this will prove to the network and the card issuer that you authenticated the customer, and that you won’t be subject to possible fraud chargebacks.
If the signed message you send with the transaction indicates that authentication wasn’t successful, or you don’t send the message, no liability shift will happen and you’ll be subject to possible chargebacks like any other ecommerce transaction.
In our Authorize.Net API, there’s a sub-element of the main transaction element called cardholderAuthentication. This element in turn contains sub-elements of authenticationIndicator and cardholderAuthenticationValue. You’d pass the information received after the authentication in these two fields to submit it with the transaction.
I’d be glad to. Let’s assume the following: You already have a server with a site that customers are interacting with to pay for something, and that you’ve already written a script or applet or some other software to get the payment information that your customers are entering and make a transaction request to Authorize.Net.
To add integration with the Cardinal Cruise script, you’ll do a couple of things on your side:
Cardinal has a quick online page to instantly obtain a sandbox account. It’s not even a signup page; they don’t even ask for any information. You just go to the page and get temporary credentials. Couldn’t be easier.
JWT is a standard, and there are lots of libraries and sample code floating around out there to help you generate a JWT on your server. In the Cardinal Cruise documentation, they’ve got a great section on generating the JWT on your server with links to recommended JWT libraries for different languages or environments. They also walk through the process of exactly what information needs to be included in the token and how it’s formatted.
The Cardinal Cruise documentation does a great job of laying out what needs to be done to include the script in your payment page, how to get that JWT into the page so that it’s readable by the script, and how to actually invoke the “Cardinal Consumer Authentication” process.
On your server, using the same JWT library that you used to create the token you passed to the credentials script, verify the signature in the returned JWT and decode it to get the information you need. Again, the Cardinal Cruise documentation has a great section that walks through this process for different languages/environments.
The two key fields in this response are the ECIFlag and the CAVV. The value for the ECIFlag field in the response is what you would include in the authenticationIndicator field in the transaction request to Authorize.Net. The value that you’ve received in the CAVV field is the value that you’d send in the cardholderAuthenticationValue field to Authorize.Net. If you send these two fields in an Authorize.Net request, you can expect to see an additional field of cavvResultCode in the response from Authorize.Net letting you know whether the information got back to the issuer okay. If the issuer recognizes this data as matching whatever they recorded earlier in the transaction when the cardholder was authenticating, they’ll respond with a successful code in this field. Congratulations, you just got a liability shift!
If you’d like to see some code actually implementing this in action, we’ve created a PHP sample app hosted on GitHub with Cardinal Cruise integrated.
Over time, you’ll be able to see Authorize.Net and Cardinal working closer together to bring the benefits of their payer authentication to more merchants. We’re looking at all sorts of ways to integrate their offerings tighter with ours including into our Accept.js solution and our hosted payment forms.
We’re also working closely with them on other initiatives like their rules-based authentication that helps limit possible friction customers might otherwise experience, and solutions utilizing 3-D Secure 2.0, the next rev of the standard that includes more flexibility and enables authentication in apps, wallets, or internet-of-things devices instead of just browsers.