PSD2, SCA, and 3DS

What is PSD2 & SCA?

PSD2 is a new European Economic Area (EEA) regulation that requires Strong Customer Authentication (SCA) as a means to increase security and authorization rates while decreasing online payment fraud. Only transactions where both the issuing and acquiring banks are in the EEA will be affected by PSD2, so this will only affect you if your acquiring bank is in the EEA.

SCA will need to be collected prior to processing a payment by authenticating two of three possible identification traits—something the customer owns, knows, or is.

3D Secure (3DS) has become the most common, globally accepted security protocol that collects and confirms SCA. 3DS was initiated and created by Visa and MasterCard and may be familiar to some merchants through these card networks’ brand names such as Visa Secure and Mastercard Identity Check. But PSD2 turns 3DS into a requirement vs. a nice-to-have.

Here is a summary of what the process looks like:

When a customer initiates an online transaction, the issuing bank may flag transactions that require SCA based on a number of criteria
Your payment gateway will receive this request and initiate 3DS in order to authenticate the customer
Advanced Billing will receive that request and show the 3D Secure challenge to your customer
Once SCA is confirmed, it is sent back to the issuing bank to successfully process the transaction

Which Gateways Integrations are Enabled with 3D Secure and Stored Credentials?

Stripe
Braintree
CyberSource
Windcave/Payment Express
Adyen
BlueSnap

What do you need to do to comply with PSD2?

General guidelines are listed below. Visit our Testing 3D Secure page for gateway specific information.

Reach out to your Gateway about 3D Secure

If you meet the requirements for PSD2, the first step is to reach out to your gateway to enable 3D Secure on your account. When SCA is required, your gateway will receive the request and serve 3D Secure challenges that Advanced Billing will automatically include in your checkout experiences; see below for more detail on this).

Enable Gateway 3D Secure Access in Advanced Billing

After you’ve enabled 3D Secure with your gateway, you may also need to make gateway specific updates in your Advanced Billing account to authorize Advanced Billing to communicate with your gateway’s 3D Secure service. In some cases a separate 3D Secure service is used so you need to add additional API credentials to give Advanced Billing access to receive and serve these 3D Secure challenges to your customers. Please visit your gateway settings page in your to verify that you have included all required credentials to enable 3D Secure.

Update Your Card Collection Pages

If you are using Advanced Billing’s hosted pages for payments, such as the Public Signup Page, Self-Service Page, and public invoice URLs, no further action is required on your end. These page have all been updated to handle any SCA requests by default.

Any custom integrations that create subscriptions, transactions, or credit card payment profiles via API will need to be reviewed to ensure they are prepared for 3D Secure.

Additional work may be required if you have implemented Chargify.js and your gateway uses our post-authentication strategy, which is currently only Stripe.
- For sites using Stripe, customers will need to be manually redirected to an action_link that we return when a transaction fails due to requiring SCA.
- For all other gateways, the customer will be automatically provided a pop-up to authenticate with 3DS when their token is generated with Chargify.js. However, these gateways will need a field added to the Chargify.js form.
- See our article on testing 3D Secure for more details.
Chargify Direct: This is an old integration method which is deprecated and does not support 3D Secure. If you are using Chargify Direct we encourage you to move to our newer Chargify.js which allows you to take advantage of all of our recently released features and removed PCI compliance burden from your company. For more information on how to switch from Chargify Direct to Chargify.js, visit our developer docs.

Update Your Dunning Emails

There are two cases in which transactions are created without your customer being present: subscription renewal transactions, and transactions created when you create a new subscription inside the Advanced Billing UI manually. These transactions are exempt from SCA and should very rarely require SCA. We have designed our dunning system to help you save these transactions from failure by automatically sending emails to communicate with your customer the reason why the transaction failed along with a prompt to visit Advanced Billing’s Self Service Page to either authorize the transaction with 3D Secure, or enter a new credit card.

What else is Advanced Billing doing to ensure that your transactions process successfully amidst PSD2?

Advanced Billing has put in a lot of work in to ensure that your transactions are exempted from SCA wherever possible, and to ensure that when SCA is required your gateway’s 3D Secure service passes seamlessly through Advanced Billing’s checkout experiences to achieve the highest possible success rates for your customers. Below is a list of various workflows that have been modified to account for SCA requests.

Renewal Transactions

Stored Credentials: Renewal transactions are exempted from SCA because no customer is present to authenticate the transaction. In order to receive this exemption the transaction must be marked as a “Merchant Initiated Transaction” and must include a prior transaction ID to prove that a prior relationship exists with this customer. In many cases the gateway has automated this process and we simply include a recurring flag when we submit these transactions to the gateway. However, some gateways do not support stored credentials and in those cases we submit these transactions as MITs and include prior transactions ourselves to ensure that these transactions remain exempt from SCA.

3D Secure: While renewal transactions should always be exempt from SCA, the reality is that the issuing bank can choose to ignore these exemption and request SCA whenever they wish. So, we’ve also added measures to ensure that when SCA is required on renewal transactions your customers are able to authorize the transaction at their convenience. Please be aware that if a renewal transaction is not successful because SCA is required, the subscription will move to past due status and dunning will kick off.

Update Dunning Emails for Failures Due to SCA

When a renewal transaction requires SCA, the transaction will fail with a reason code related to SCA being required. The subscription will move to a past due status and dunning emails will be sent to the customer letting them know why the transaction failed and encouraging them to visit Advanced Billing’s Self Service Page to authorize the transaction. We recommend updating your dunning emails to tailor these emails for your customers.

Self-Service Pages

Our Self-Service Pages will detect if a renewal transaction is awaiting SCA and will include a link to the 3D Secure page to allow the customer to authenticate the transaction rather than enter new credit card information.

When new credit cards are collected using Advanced Billing Self-Service Pages (SSPs) Advanced Billing will run authorizations on the card with 3D Secure that will be used as initial transactions to ensure that your later renewal transactions process successfully.

If a prior transaction on the subscription is awaiting SCA, then a link will be shown on the SSP so that your customer can authenticate via 3D Secure directly from the Self Service Page.

Invoices

If SCA is required when your customer attempts to pay an Advanced Billing invoice, your gateway’s 3D Secure challenge page will presented to your customer in a modal, or pop-up, on the page.

When SCA is required while creating subscriptions using Advanced Billing’s Public Signup Pages 3D Secure Challenges will be presented to your customer directly in the PSP and the subscription will not be created unless 3D Secure passes successfully.

Creating Subscriptions in the Advanced Billing User Interface

When you create subscriptions in the Advanced Billing UI, these transactions will be classified as Mail Order and Telephone Orders (MOTO) whenever possible since the the credit card information is usually collected via telephone, mail, or another similar method. For the most part, SCA should not be required, but the customer’s bank may request for verification at any time.

If an initial transaction occurs and fails due to SCA, the subscription will not be created. If SCA is required and you prefer to have the customer authorize the transaction via your dunning flow, you can simply push out the subscription start date. Note that this approach will skip any trial or setup fees on the subscription’s product.

Creating Credit Card Transactions or Authorizations via API & Chargify.js

When SCA is required on transactions created via Advanced Billing’s API, Advanced Billing will return a response with a redirect link parameter called action_link. You will need to make sure that your pages are updated to handle these action_link redirects. Advanced Billing has integrated with the 3D Secure systems of all 3D Secure supported gateways to ensure that these 3DS urls and tokens are passed seamlessly between Advanced Billing, your gateway, your gateway’s 3D Secure Service, Visa/Mastercard, and the issuing bank.

Pre Authentication Gateways

Pre Authentication payment gateways such as CyberSource, Windcave (formerly Payment Express) or Adyen require the end-customer to be actively on the session to validate SCA through 3D Secure. Because of this requirement certain workflows aren’t supported because they do not involve the end-customer being on the session.

If the card collection, passing the full credit card details, is happening through the API (including new signups and card updates), the end-customer is not actively on the session, so this method for card collection is not supported.
If the card collection is happening through the Advanced Billing admin user interface, the end-customer is not actively on the session, so this method for card collection is not supported.

It is recommended to make use of the Public Signup Pages for new signups, and self-service pages or Billing Portal for card updates. If you wish to continue using the API or user interface for signups, you will want to adjust your flow to sign the end-customer up to a no-cost/free product that doesn’t require card collection, collect their card through a self-service page or Billing Portal, and then perform migration to charge them for the product.