Check out our integration guide and work with your team to make sure you are prepared for Strong Customer Authentication (SCA) by September 14, 2019
October 17, 2019 update
The EBA has announced the following regarding the PSD2 deadline:
"The European Banking Authority (EBA) published today an Opinion on the deadline for the migration to SCA under the revised Payment Services Directive (PSD2) for e-commerce card-based payment transactions. The Opinion sets the deadline to 31 December 2020 and prescribes the expected actions to be taken during the migration period."
Additional details can be found on the EBA website.
The Revised Payment Services Directive (PSD2) is going into effect throughout Europe on September 14, 2019 (see October 17, 2019 update). It applies to all online transactions where both the issuing and acquiring banks are located in the European Economic Area (EEA): Austria, Belgium, Bulgaria, Croatia, Republic of Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, Monaco, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, and the UK.
The main requirement of PSD2 that is relevant to businesses is what's called Strong Customer Authentication (SCA). SCA is a new European regulatory requirement to reduce fraud and make online payments more secure. To accept payments once SCA goes into effect on September 14 (see October 17, 2019 update), you will need to build additional authentication into your checkout flow. Essentially, you will have to present customers a 3DS (3D Secure) flow when they purchase online, so that they can "authenticate" they are who they say they are, and that they are the valid holder of the credit card being used. Starting September 14, 2019 (see October 17, 2019 update), banks will decline payments that require SCA but have not gone through authentication.
If your merchant account provider a.k.a. your acquirer or acquiring bank, is based in the EEA - and you transact with customers in the EEA - you will need to do some development work to prepare for this change. Please ensure this is added to your roadmap. If you do not know who your merchant account provider is or where they are located, you should check with your gateway. (Note: your merchant account is different from your bank account. A merchant account is a type of bank account that allows businesses to accept payments by debit or credit cards. When your customer pays for your product or service with a credit card, the funds are first deposited into your merchant account. Then, it is transferred to your business bank account.)
For subscription businesses, merchants only have to present the 3DS flow on the initial purchase. Subsequent recurring subscription purchases are considered exempt from PSD2 and SCA unless the issuing bank declines the exemption. For businesses that also have one-time purchases, they should plan to present SCA on those payment flows, as well.
There are certain additional conditions where a transaction can be considered exempt from SCA, including transactions under 30 EUR and subscription or recurring transactions (after the 1st purchase). Merchants may be able to configurably “apply” for these exemptions. Support for SCA exemptions varies by gateway; you should contact your gateway to understand how they support exemptions.
The decision to accept or deny an exemption is wholly up to the card issuer. However, if the issuer opts to accept a transaction as exempt from SCA, then the customer will not be prompted to complete the 3DS flow. However, note that if you, your gateway on your behalf, or your acquirer requests an exemption that is then accepted by the issuer, the liability stays with you. If the exemption is applied by the issuer, the liability shifts to the issuer.
There are 2 flavors of 3DS. 3DS 1.0 is the older version that has been available since 1999 but is not widely adopted because of its historically negative impact on checkout conversion. 3DS 2.0 is the newer, more seamless version that will be introduced as part of PSD2. You can read (and see) the differences between 3DS 1.0 and 3DS 2.0 in this article from Adyen.
Note: PayPal, AmazonPay, and ApplePay -- as well as alternative payment methods like iDEAL and SOFORT -- already support payment flows with a built-in layer of multi-factor authentication, so no 3DS authentication is necessary with those payment methods.
For Recurly’s part, we will be enhancing our client-side integration so you can leverage Recurly to do SCA and present 3DS on initial and one-time purchases. Recurly will then pass the authentication along with the authorization to your gateway. Be prepared to update your current Recurly integration for SCA by September 14, 2019. (see October 17, 2019 update) Check out our integration docs here: https://dev.recurly.com/page/recurly-3d-secure-2-integration-guide
For subsequent renewal purchases, Recurly will endeavor on your behalf to exempt these transactions from SCA by flagging those transactions as "MIT" (Merchant Initiated Transactions). This includes existing subscriptions that started prior to September 14, 2019 (see October 17, 2019 update). Recurly will endeavor to "grandfather" these subscriptions as merchant-initiated so that they don't require SCA when they come up for renewal on/after September 14 (see October 17, 2019 update).
However, note that there will still be cases where subsequent renewal “MIT” purchases will still require SCA. Card issuers always have the final say and can require SCA for any transaction, for any reason. Given that, Recurly is also planning to provide fallback option(s) to help you recover MIT transactions that do, in fact, fail due to SCA.
The checklist below outlines the steps you'll need to complete to support SCA through Recurly:
- Contact your gateway to ensure you're set up to support 3D Secure 2 transactions and to make any other required changes. We've documented known needed changes here.
- Update your Recurly integration to support SCA challenge flows on checkout. Our implementation guide describes this setup. Note: if you use our hosted checkout pages, you can skip this step.
- Configure your dunning flow and related dunning emails. This hosted flow is described in our documentation, though please refer to the implementation guide linked in Step 2 if you'd like to implement your own solution.
Recurly supports a number of global gateways and payment methods. As such, we will be enhancing our integrations with the following:
- Credit card gateways: Stripe, Braintree, Adyen, WorldPay, Wirecard, SagePay, Chase, Cybersource, PayPal Payments Pro UK
- Payment methods: PayPal (aka "PayPal Business"), AmazonPay, ApplePay
Note about PayPal: for PayPal transactions where PayPal is the payment method (aka "PayPal Business"), there will be no work required by merchants. PayPal will augment their "Pay with PayPal" user flow to do Strong Customer Authentication. Recurly will additionally augment our integration for this payment method to handle subsequent recurring scenarios.
We are not planning to enhance our support of the following gateways and payment methods as they are not impacted by PSD2 because they do not offer or support acquirers in the EEA, and/or we have previously deprecated support for them:
- Credit card gateways not impacted by PSD2: TSYS, First Data, Payeezy, Vantiv, CardConnect, CheckCommerce, Bambora, Authorize.net, PayPal Payflow Pro, Merchant eSolutions
- Credit card gateways we've deprecated: QuickBooks, LinkPoint, Ogone
- Payment methods not impacted by PSD2: Roku
Note about Authorize.net: We've learned that Authorize.net will not be supporting PSD2. Merchants who would be impacted by PSD2 will have to migrate to Cybersource gateway according to Visa, the parent company of both Authorize.net and Cybersource. If you are currently processing through Authorize.net, please look for detailed communications about this from Authorize.net soon or contact Authorize.net support at +44 (0) 203 564 4844.
Question: How do I know if my business will be impacted by PSD2?
Answer: If your merchant account provider a.k.a. your acquirer or acquiring bank, is based in the EEA - and you transact with customers in the EEA - you will be impacted by PSD2 and should be prepared to do SCA. On the other hand, if either of the parties in a transaction are outside the EEA, then the SCA regulation does not apply.
Question: When will technical documentation be available so my teams can plan to do the work necessary to prepare for PSD2?
Answer: The integration guide is available at: https://dev.recurly.com/page/recurly-3d-secure-2-integration-guide.
Question: How will 3DS impact my checkout conversion?
Answer: Businesses saw between a 3-15% dropoff in checkout conversion with 3DS1, though that number varies widely by country. With 3DS2, issuers are targeting at most a 5% dropoff at checkout. (Statistics provided by WorldPay)
Question: How will 3DS affect authorization rates?
Answer: Businesses that have previously not implemented 3DS see, on the whole globally, about an 84% authorization rate. 3DS1 increased that to 92%. Issuers are hoping to see 3DS2 further improve authorization rates to 95%. (Statistics provided by WorldPay)
Question: What reduction in fraud can be expected?
Answer: Businesses that have previously not implemented 3DS see, on the whole globally, about 0.29% in fraud rates, inclusive of both authenticated and unauthenticated fraud. 3DS1 reduced that to 0.12%. Issuers are hoping to see 3DS2 further reduce fraud rates to 0.05%. (Statistics provided by WorldPay)
Question: How much transaction latency should I expect as a result of 3DS?
Answer: In general, 3DS authentication can take up to 10 seconds. In addition, if the issuer rejects an exemption and forces SCA to take place, there could be an additional latency of up to 1-2 seconds for the issuer to evaluate an exemption, reject it, and then force SCA. (Statistics provided by WorldPay)
Question: I have more specific questions about PSD2, SCA, or 3DS. Who should I ask?
Answer: While Recurly is here to help you prepare for PSD2, your gateway is your primary resource. We are working with each of the gateways listed above to understand how best to meet their technical integration requirements around PSD2 and SCA, but in terms of what the regulation means, how it will impact your business and customers, etc your gateway will be the subject matter expert.
Question: What about PayPal?
Answer: For PayPal transactions (where PayPal is the payment method, aka "PayPal Business"), there will be no work required by merchants. PayPal will augment their "Pay with PayPal" user flow to do Strong Customer Authentication. Recurly will additionally augment our integration for this payment method to handle subsequent recurring scenarios.
Question: Will 3DS ever be prompted on recurring, merchant-initiated transactions, e.g. if the value differs, etc?
Answer: The card issuer can technically challenge a transaction, even merchant-initiated ones, for any reason. Because of this, Recurly is planning to provide fallback option(s) like a "3DS dunning flow" to help you recover MIT transactions that fail due to SCA and need to be re-authenticated by your customer.
Question: With usage-based billing, would SCA be required on each re-bill?
Answer: As long as the transaction is merchant-initiated and is appropriately flagged as such, subsequent re-bills should in most cases not require SCA, even if the amount varies (as in usage-based billing). However, note that there will still be cases where subsequent renewal “MIT” purchases will still require SCA. Card issuers always have the final say and can require SCA for any transaction, for any reason.
Question: With a fixed subscription where the first month is prorated, would the second month (charging the full amount) still qualify to be exempted from SCA?
Answer: Best practice suggests that in this scenario, merchants should authenticate for the full amount of the subscription at the time the customer signs up, even if the first month is prorated. Then, subsequent re-bills should in most cases not require SCA as long as they are appropriately flagged as MIT. Recurly will take care of both of these pieces for our merchants: authenticating for the full amount, and flagging subsequent re-bills as MIT.
Question: What happens with MITs where the original transaction was pre-Sept 14, 2019? Will we have to authenticate all MITs for existing customers prior to Sept 14?
Answer: For subsequent renewal purchases, Recurly will endeavor on your behalf to exempt these transactions from SCA by flagging those transactions as "MIT" (Merchant Initiated Transactions). This includes existing subscriptions that started prior to September 14, 2019. Recurly will endeavor to "grandfather" these subscriptions as merchant-initiated so that they don't require SCA when they come up for renewal on/after September 14 (see October 17, 2019 update).
Updated about a month ago