Much of our previous content, such as our most recent PSD2 blog and our SCA Integration Guide, has focused on Customer Initiated Transactions (CITs), which occur when the customer is “in-session” or otherwise present during the transaction flow. In the subscription commerce world, CIT comes into play when someone first signs up for a subscription and provides their payment information. Similarly, a subscriber may decide, at a later date, to modify the payment information associated with their existing subscription. In both of these cases, the subscriber is available to complete any authentication challenges that might be requested by their card issuer in conjunction with Strong Customer Authentication (SCA) requirements.

Merchant Initiated Transactions

While it is undoubtedly important to lock down the CIT flow in order to onboard new subscribers and service existing ones, consider that most of the transactions that occur over the lifetime of a subscription will be recurring and thus happen while the subscriber is “off-session” and not actively involved in the process. These recurring charges are a type of Merchant Initiated Transaction (MIT), as stored subscriber credit cards are automatically charged on an ongoing basis, in conjunction with defined billing cycles and subscription terms. The burning question thus becomes, how do we handle SCA for these transactions where the subscriber is not present?

Exemptions to the rescue

Luckily, MITs qualify for an exemption in conjunction with PSD2, and thus are not subject to SCA requirements. In order to mark an MIT transaction as exempt, special flags are passed through to the payment gateway. Although each gateway takes a different approach to how these MIT exemption flags are structured and transmitted, Recurly handles these variables for you. Our platform automatically applies the appropriate gateway-specific flags when we charge your subscribers’ credit card as part of the renewal process. You can read more about it in our documentation. So, all good right?

Unfortunately not, as this exemption comes with a critical caveat. Namely, it is ultimately at the discretion of the card issuer whether to require SCA on any given transaction. This includes MITs and any other transaction that may qualify for an exemption. So, while we can expect—or hope—that card issuers will honor MIT exemptions most of the time, it is still prudent to have a fallback solution in cases where they do not. Of course, this means that we must somehow bring the subscriber back into session in order for them to complete the authentication flow. Failure to account for and handle this situation could result in the loss of subscribers due to involuntary churn.

Dunning for the win 

Dunning refers to the process of sending periodic communications to a subscriber, requesting payment for an outstanding invoice or accounts receivable. In subscription commerce, the dunning process is typically initiated when the card issuer declines a subscribers’ stored payment information when the recurring payment transaction is processed. Payment declines can happen for a variety of reasons such as the card on file being expired or deactivated.

At this point, it may be clear that dunning can also be an effective solution in cases where MIT SCA exemptions are rejected by card issuers, requiring customers to come back “in-session” to complete the SCA flow. Additionally, the Recurly platform has advanced dunning tools, and this use case fits quite nicely into our already existing ‘Payment Declined’ dunning configuration.  Thus, as part of our overall PSD2/SCA solution, Recurly will release a new, SCA-specific email template to this configuration in order to handle situations in which the subscriber must be brought back in-session to complete SCA.  

Recurly’s dunning management tool is intuitive and easy to use. Using the Recurly admin panel, you can configure a cadence for any number of dunning emails that are automatically sent to the subscriber when a payment is declined. You can customize the email content, as well as the look and feel (e.g., fonts, colors, etc.). You can also configure a final action, such as failing the invoice or expiring the subscription, in cases where the subscriber does not complete the payment. 

By default, dunning emails contain a link to a page, hosted by Recurly, that lets your subscribers take action to repair the failed payment, such as updating their credit card information. In the case of SCA, Recurly will provide enhanced pages that will guide the subscriber through the steps to complete the SCA process, including any required challenges. They will have the option of either authenticating the existing card on file or providing a new payment method. Once the subscriber has completed the authentication process, Recurly will once again attempt MIT exemptions for subsequent transactions using the newly authenticated payment information.

If you would like to create and host your own page for your subscribers to complete the SCA flow, you can include a link to this page in the dunning email template. You can build this page using Recurly.js and the Recurly API similar to the CIT flow. See our SCA Integration Guide for more details.

More to come

Look for more details regarding our MIT dunning solution for SCA in the coming weeks. In the meantime, if you’re not already familiar with our dunning management tool, please take a look at our product documentation.