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 the cliff notes version of how it all works and 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
- Chargify 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
- Windcave/Payment Express
General guidelines are listed below. Visit our Testing 3D Secure page for gateway specific information.
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 Chargify will automatically include in your checkout experiences; see below for more detail on this).
After you’ve enabled 3D Secure with your gateway, you may also need to make gateway specific updates in your Chargify account to authorize Chargify 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 Chargify 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.
If you are using Chargify’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_linkthat 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.
- For sites using Stripe, customers will need to be manually redirected to an
- 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.
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 Chargify 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 Chargify’s Self Service Page to either authorize the transaction with 3D Secure, or enter a new credit card.
Chargify 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 Chargify’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.
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.
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 Chargify’s Self Service Page to authorize the transaction. We recommend updating your dunning emails to tailor these emails for your customers.
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 Chargify Self-Service Pages (SSPs) Chargify 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.
If SCA is required when your customer attempts to pay a Chargify 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 Chargify’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.
When you create subscriptions in the Chargify 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.
When SCA is required on transactions created via Chargify’s API, Chargify 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. Chargify 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 Chargify, your gateway, your gateway’s 3D Secure Service, Visa/Mastercard, and the issuing bank.
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 Chargify 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.