Overview

Required plan

This feature or setting is available to all customers on any Recurly subscription plan.

Definition

Dunning Setup for 3D Secure 2 Declines refers to a mechanism established by Recurly to help merchants recover revenue that could be lost due to failed MITs under the PSD2 Mandate. It includes updates to dunning configuration, email templates, and Recurly Hosted Page aimed at resolving 3D Secure 2 (3DS2) authentication failures.

Please note, this email only functions for gateways that return 3DS-specific decline messages. Those gateways are: Adyen, Worldpay, First Data, Payeezy, and SagePay/Opayo.

Why is this setup important?

The PSD2 Mandate necessitates Strong Customer Authentication (SCA) for most online transactions within the European Economic Area (EEA). Although Merchant Initiated Transactions (MITs) should not generally require SCA, situations may arise where a customer's issuing bank presents an SCA challenge, necessitating customer authentication.

Recurly's approach to revenue recovery

To support merchants in revenue recovery from failed MITs, Recurly has developed a comprehensive solution to complete the SCA challenge for re-authentication. This includes:

Modifications to the dunning configuration
Updates to Recurly email templates
Enhancements to Recurly Hosted Page

These alterations aim to help retain customers whose recurring transactions suffer declines due to 3DS2 authentication failures. Depending on your integration, this may necessitate modifications to your Recurly settings.

Configuring your settings

Adjusting dunning settings

Recurring payments failing due to 3DS2 authentication issues will initiate a dunning cycle based on your existing dunning management settings. If these settings are not yet configured, it's crucial to activate them so the appropriate recovery email can be sent.

Upon activation, you'll notice a separate section within your dunning management settings that highlights dunning for 3DS2 failures. This will follow the same sequence of notifications configured for your default dunning cycle.

Tailoring email templates

If a recurring payment fails because it needs 3DS2 authentication, your customers will get a special email guiding them to complete the necessary payment authentication. You can personalize this email in your template settings. The email will contain a link to a secure payment page hosted by Recurly. To use this feature, you'll need to be using Recurly's hosted pages.

Configuring hosted pages

Recurly has a hosted solution enabling you to re-engage a customer whose recurring payment has failed into a payment session to complete the 3DS authentication required by their bank. To utilize this hosted page, ensure that the Recurly Hosted Account Management Pages are enabled for your site.

Customer flow at a glance

This is the high-level process:

In response to a 3DS challenge request from the issuer, the renewal invoice will become past due, initiating dunning. Recurly will dispatch a "3DS2 Decline" email to your customer to authenticate their payment.

From the email, your customer will be prompted to validate their payment, leading them to the hosted re-authentication page. This page is designed to bring your customer back in-session to complete the required authentication.

Clicking on the "Confirm Payment" button on the hosted re-authentication page brings your customer "in-session," to complete authentication and present a 3DS2 challenge frame from their issuing bank. The contents of this frame will depend on their bank.

If authentication is successful, your customer's payment will be processed, leading them to a confirmation page.

However, if payment is unsuccessful, your customer will be prompted to try again or update their billing information, requiring them to retry the 3DS2 challenge provided by their issuing bank.

Post-deadline enhancements

After the PSD2 deadline of 9/14/19, Recurly has refined the dunning process for transactions declined due to 3DS2 authentication failures, offering a more customizable re-authentication flow.

Helpful resources

Adyen: Dive deeper into understanding PSD2 and its implications with Adyen.
Braintree: Navigate your preparations for PSD2 with this comprehensive guide from Braintree.
Stripe: Explore Stripe's detailed guide on Strong Customer Authentication under PSD2.
WorldPay: WorldPay's resource on PSD2 provides a global perspective on this regulation.
Cybersource: Learn about the intersection of 3D Secure and PSD2 with Cybersource.

FAQs

Q: Do I need to worry about PSD2?
A: If your business bank or payment provider is in the European Economic Area (EEA) and you have customers there too, then yes, you need to get ready for PSD2 and make sure you have Strong Customer Authentication (SCA) in place. If your customers are outside the EEA, then you don't need to worry about SCA. If either you or your customers are in the EEA, you may or may not need to comply with PSD2, depending on your situation. Ultimately, the banks will be the deciding factor and may require SCA on a transaction.

Q: Where can I find more technical information on preparing for PSD2?
A: You can find all the technical details you need in our integration guide here.

Q: Will my checkout conversions change because of 3DS?
A: The first version of 3DS could lead to a drop in checkout conversions between 3-15%. But don't worry, the second version aims to limit this to a maximum of 5%. But remember, these numbers can change depending on your country. (Statistics provided by WorldPay)

Q: What's the effect of 3DS on authorization rates?
A: If you're new to 3DS, you can expect your authorization rates to go up from about 84% to 92% with the first version. The second version aims to push this up to 95%. (Statistics provided by WorldPay)

Q: Can 3DS help me reduce fraud?
A: Absolutely. According to statistics from WorldPay, businesses that didn't utilize 3DS experienced fraud rates of approximately 0.29%. With the introduction of 3DS 1.0, this rate decreased to 0.12%. The second version of 3DS aims to further diminish this rate to an estimated 0.05%. However, it's essential to note that 3DS 1.0 is no longer a feasible choice for the majority of businesses.

Q: Will 3DS slow down my transactions?
A: Generally, using 3DS could add up to 10 seconds to your transaction time. If an exemption is rejected and SCA is enforced, this could add another 1-2 seconds. (Statistics provided by WorldPay)

Q: Who can I turn to if I have more questions about PSD2, SCA, or 3DS?
A: While we're always here to help, your payment gateway should be your go-to resource for these kinds of questions. They'll be up to speed on how PSD2 and SCA might affect you and your customers.

Q: What about PayPal transactions?
A: No extra work needed here! PayPal will take care of Strong Customer Authentication in their "Pay with PayPal" process. We will also make sure our integration can handle recurring PayPal payments.

Q: Could 3DS be triggered on recurring payments that I initiate, especially if the value changes?
A: Yes, it's possible. Card issuers can challenge a transaction for any reason. Because of this, we're developing a "3DS dunning flow" to help you manage transactions that fail due to SCA and need to be re-authenticated by your customer.

Q: Will SCA be needed every time I re-bill a customer on a usage-based plan?
A: As long as the transaction is flagged as being started by the merchant (that's you), most re-bills shouldn't need SCA, even if the amount varies. But remember, card issuers have the final say and can ask for SCA on any transaction.

Q: I have a fixed subscription but the first month is prorated. Will the full charge in the second month need SCA?
A: Ideally, you should authenticate the full subscription amount when the customer signs up, even if the first month is prorated. After that, re-bills should generally not need SCA, as long as they're flagged as merchant-initiated. We'll take care of this for you.

Q: What if the original transaction happened before Sept 14, 2019? Will I need to authenticate all of these older transactions?
A: For renewals, we'll try to exempt these transactions from SCA by marking them as "merchant-initiated". This includes subscriptions that started before September 14, 2019. Our goal is to treat these as merchant-initiated so they won't need SCA when they renew on or after September 14.