The SCA requirement aims to make electronic, online and mobile payments more secure and does so by asking customers to provide additional information to authenticate and complete their transactions. How Piano supports SCA is explained in this article.
On this page, we have compiled frequently asked questions about this topic.
What is SCA under PSD2 and how does it impact online payment processing?
SCA (Strong Customer Authentication enabled via 3D-Secure) are instruments regulated by the EU Commission affecting all banks, schemes and payment service providers. The underlying infrastructure is implemented and managed by EMVco between Payment service providers and banks with terms enforced by EU Commission PSD2 regulations in the EEA.
See more details on our partner sites and formal sources:
GoCardless (Direct Debit is not subject to SCA)
Which countries are affected by 3DS PSD2?
All EEA/UK issuers are enforcing 3DS authentication now. Other countries should be subject to a one-leg exemption, more information.
Exemptions
Please review the regulation specifics on the EU Commission Journal outlining scenarios of when Strong Customer Authentication applies and which exemptions are approved to be used. For subscription transactions the most important exemption is MIT.
Outline on exemptions by Stripe.
See details on the implementation of exemptions by Braintree:
Relevant exemptions:
-
-
MIT - Merchant Initiated transaction - Piano requests this exemption on recurring transactions. Application varies across payment providers, however, in all cases, 3DS authentication is required upon the initial transaction (Customer Initiated Transaction) to qualify for SCA exemption on a series of recurring transactions, provided the payee or the amount does not change as specified by
the EU Commission in Paragraph 3, Article 14.
-
Low risk - usually automatically assessed for and applied between the payment provider and the issuer, various risk factors are assessed for and dependent on the merchant status and observed fraud rates
-
Low value - usually automatically assessed for and applied between the payment provider and the issuer
-
MOTO - Mail or Telephone Order - in general can be requested if the payment service user is not in session and makes the purchase via Phone or Mail. This exemption is loosely specified. According to Braintree for example; merchants can apply MOTO flags with new transactions processed under very specific conditions, like when the customer is providing card information either verbally or over the phone for instance. Though these transactions are subject to a different standard of SCA authentication, and may therefore be exempt from 3DS, we do not recommend that merchants (or developers working on behalf of merchants, for that matter) use this as a way to bypass these requirements. Merchants who pass MOTO flags on transactions which weren't initiated by mail or phone through someone within their organization may be subject to severe penalties from banking providers. MOTO (Mail or Telephone Order) exemption parameters can only be passed for initial merchant-initiated transactions using new billing information or for merchant-initiated one-time transactions using stored billing information. Recurring transactions can not be supported using MOTO exemptions in an audit-proof way. The MOTO exemption was designed to enable the Mail Order/Telephone Order (MOTO) exemption. This exemption allows one-time, customer-initiated transactions (CIT) to bypass Strong Customer Authentication (SCA) requirements, provided factors such as no fraud risk and a typically low transaction amount (often below 30 EUR) are met. The MOTO is intended for (CIT) customer-initiated transactions only and does not apply to subscription flows or Merchant Initiated Transactions (MIT). In Piano, the feature was initially misapplied to subscription renewals (MIT), which does not conform to Visa and Mastercard guidelines. As a result, the MOTO exemption (and thus the toggle) is effectively disabled for subscriptions and Dashboard-created transactions. All transactions manually initiated via the Piano Dashboard always send transactionSource=recurring_first (or recurring), and do not pick up the MOTO flag.
-
TRA - Transaction Risk Analysis - can help exempt transactions from being 3DS challenged by the issuer. However, it is dependent on a separate service subject to availability by a given payment provider. For example, with Braintree, the request for Transaction Risk Analysis exemption will have to be filed by each merchant individually. The process begins by establishing what sort of fraud tools are being used by the merchant so that their account can be approved by the acquiring bank they're using. Once Braintree is able to verify, on a case-by-case basis, that a merchant's fraud prevention measures are adequate to maintain an acceptable fraud rate, Braintree can contact the acquiring bank and request approval.
The Issuer has the ultimate say on whether SCA needs to apply, the value of the transaction has to be below €500, and the risk analysis undertaken has to meet specific requirements. The Issuer or Acquirer applying the TRA exemption has fraud rates below the following defined limits:
-
Transaction value band PSP fraud rate
-
<€100 13 bps/0.13%
-
€100-€250 6 bps/0.06%
-
€250-€500 1 bps/0.01%
-
-
-
For additional reference, see the VISA guide on SCA exemptions.
What can I do as a Merchant to limit the impact of 3DS authentication on my business?
There are a number of steps merchants can take to minimize the impact of 3DS on their subscription business. See below a list of steps you can take;
-
Ensure you have enabled 3DS (v2) on your Merchant account (consult your payment provider to ensure this has been enabled)
-
Ensure you have enabled 3DS in your payment provider settings in Piano, review the supported features and make sure you’ve enabled 3DS support and made template changes as outlined in our documentation
-
Review the PSD2 directive in detail and consider rethinking your subscription and pricing strategy to limit situations which may lead to an increased number of failures due to 3DS. Primarily, price and subscription changes on recurring payments and grandfathered subscriptions. Keep in mind that 3DS functional/technical implementation may vary by providers and banks.
-
Consult your Payment provider and your acquiring bank about 3DS. PSD2 specifies exemptions stemming from being a Trusted merchant as well as having TRA (risk analysis and fraud prevention mechanism) in place which can help reduce the 3DS impact on your business substantially. This is dependent on the fraud rates currently reported on your account.
-
Monitor your business and approval rates
What happens to subscriptions and payment methods stored prior to 3DS enforcement?
Existing subscriptions and saved card information will be grandfathered: information saved to your payment provider prior to the enforcement date for SCA will not require additional authorization. Collected payment methods—either as a token, source or payment_method—saved prior to the SCA enforcement date can be used for off-session (e.g. Merchant Initiated Transactions) payments without requiring additional authentication, however only until the transaction amount or the payee changes.
How does SCA impact digital subscription billing and subscriber management?
With the regulation in effect across European countries, banks are requiring 3DS authentication. We observed an increase in decline rates due to authentication-required failures (usually soft declines) across payment processors actively operating in the EU. These errors may happen for a number of reasons, and it is the Issuing bank which decides whether 3DS authentication is required or not for a given user.
3DS PSD2 impacts transaction approvals by issuing banks in the EU and the UK. While recurring payments and legacy subscriptions established prior to the release of the PSD2 are exempt from the SCA (Strong Custom Authentication), some transactions may still be challenged by the issuers, provided the bank identifies the payer account as at risk, despite an exemption. The impact varies across banks, countries and the amount charged, for most EU countries the 3DS authorization is required when a transaction with an amount higher than 30 EUR is processed. Transaction amounts lower than that may qualify for low transaction exemption up to five times or a total of 100 EUR, as such unfortunately do not serve the purpose of recurring transactions.
However, providers have followed SCA PSD2 guidance and implemented support for exemptions. Piano follows the guidance and has integrated the support for the MIT (Merchant initiated transactions) exemptions to enable recurring transactions.
Following further VISA guidance on SCA, billing periods longer than 12 months may require another authentication.
How does Piano support 3DS on recurring subscriptions?
Piano is leveraging the Braintree, Stripe, Cybersource and other Payment service providers' guidelines and establishes SCA - 3DS upon initial transaction or when the card is first authorized as part of storing it within the provider vault. By enforcing 3D Secure for the first transaction or verification, the card issuer is notified that you have established a mandate between your organization and your customer to charge their payment method for subsequent recurring payments. Such subsequent transactions are out of scope from PSD2 SCA requirements and do not require authentication upon renewal unless the subscription amount or payment method changes.
Stripe: “Industry requirements for how merchant-initiated transactions will work in practice are still being finalized.”
Braintree: “Price changes will be subject to SCA standards at the discretion of the bank involved, whether there's been a price increase or not. Out of scope in this instance would be MOTO transactions, which also includes transactions which were initiated manually by organization members in the control panel. Ultimately, there's no way to ensure a subsequent charge in a series or subscription will bypass SCA requirements.”
What Piano functionality is affected?
Trial periods - due to the need for 3DS authorization, an increase in the transaction value as part of the recurring engagement may result in a decline, (e.g. initial transaction is at a discounted rate, renewals are at a greater rate). As a result, users may not be able to renew from trial periods successfully, unless the initial transaction is authorized at the full rate of the subscription. Piano has implemented the necessary parameters to enable merchants to authenticate free and paid trials for the full amount upon purchase in an effort to secure future renewals. However, every transaction is subject to issuer assessment and approval acceptance.
When free trials are used you should consider the validity of the 3DS authentication ID which is captured during the on-session Customer Initiated Transaction, which is 90 days according to PSD2. Setting your free trial to this exact duration or for a longer period may cause the renewal to fail as the initial authentication will no longer be valid or may be successful but the liability will not shift to the issuer. If such a 3DS authentication failure occurs, the user may still be sent to the re-authentication flow provided you configured the 3DS reactivation flow.
Promo codes - similarly to Trials, when the value changes, transactions may be declined by the issuer, if the full amount was not 3DS authenticated during the checkout either by passing specific parameters to the provider or by authenticating the subscription at a full rate, this varies by payment providers and their implementation of the 3DS, some providers only require 1 EUR amount to authenticate, while the best practice has been full amount authentication to ensure renewals are fully exempt. If such a 3DS authentication failure occurs, the user may still be sent to the re-authentication flow provided you configured the 3DS reactivation flow.
Action manager - If the action is to migrate users to a higher price term (this is an amount change which is subject to SCA, it is however up to the issuer, and ultimately, there's no way to ensure a subsequent charge in a series or subscription will bypass SCA requirements if the price has changed). As such when a recurring payment term is being modified, increasing rates on such subscriptions may result in a new 3DS authentication to be required and as such may result in a failure since the user is not in session. If such a 3DS authentication failure occurs, the user may still be sent to the re-authentication flow provided you configured the 3DS reactivation flow.
Upgrades - for instant upgrades, the 3DS authentication need may vary depending on whether the user has previously established a mandate with your business. As previously mentioned, if the user has initially established 3DS authentication on the purchase, following transactions from such a payment method may still be approved even if the rate changes, this decision would be subject to the issuer’s decision. Scheduled upgrades may be successful but the liability may not shift to the issuer, but again dependent on the issuer’s decision, they may in many cases fail upon renewal in case a new 3DS authentication was not established at the time of the upgrade. Furthermore, if the renewal date of the scheduled upgrade surpasses 90 days from the change, the renewal may be successful but the issuer will not assume liability shift, or it may fail due to expired authentication. Piano has implemented support for the 3DS on upgrades, the implementation may vary by provider for more details see the section: Which payment methods and providers are affected by PSD2? If such 3DS authentication failure occurs, the user may still be sent to the re-authentication flow provided you configured the 3DS reactivation flow.
Payment with saved payment method - if a new purchase has a higher price than the initial transaction and new 3DS authentication has not been applied previously when storing the payment method, or the user has not passed the 3DS authentication as part of this purchase, the renewal transaction may likely fail. If such 3DS authentication failure occurs, the user may still be sent to the re-authentication flow provided you configured the 3DS reactivation flow.
Manual renewals - this functionality offers users to renew their subscription before their current billing period ends, provided the initial transaction has been 3DS authenticated, renewal should occur successfully, otherwise a failure may occur upon renewal. If such 3DS authentication failure occurs, the user may still be sent to the re-authentication flow provided you configured the 3DS reactivation flow.
Add renewal payment method - similarly to making a purchase with a new payment method, in this scenario, 3DS authentication is required to verify and store the payment method in order to ensure a successful renewal. In case a 3DS authentication failure still occurs due to the issuer’s decision, the user may still be sent to the re-authentication flow provided you configured the 3DS reactivation flow.
Mitigating the impact
3DS PSD2 impacts the whole e-commerce industry. While Piano has support for 3DS, due to the variance in the effective dates by countries, variance in the affected transaction amounts, inconsistency in 3DS triggers and reporting across the network, limited testing capabilities, variance in the implementation of the 3DS by individual payment providers, further monitoring, research and testing is ongoing.
Meanwhile, it is recommended that clients transacting in the EEA, take precautions in subscriber management and limit the use of features which modify term rates, since these may invoke the need for 3DS authorization to harbor this change.
As such, make sure you have enabled 3DS support on your payment processor integration as outlined in the documentation.
Consider offering alternative payment methods that are exempt from SCA, such as direct debit or digital wallets, to provide more options for your customers and reduce reliance on card payments.
What happens when the price increases?
Braintree has confirmed that there is always a need to re-establish SCA on the existing subscription if the price of the subscription has increased or the subscription is being updated with a new payment method. However, the actual 3DS authentication challenge is subject to the issuer's assessment of the risk, as such, if the issuer observes the transaction to present a no or low risk, even a transaction in a series of subscription transactions with an increased rate can be accepted and successfully processed.
Likewise, Stripe’s confirmation has been that a subscription change would require a new setup intent, which would require another authentication if 3DS auth is requested by the issuing bank.
EU Commission PSD2 directive Article 5, point 1: “...the authentication code generated is specific to the amount of the payment transaction and the payee agreed to by the payer when initiating the transaction;”
“any change to the amount or the payee results in the invalidation of the authentication code generated.”
Collecting user mandate - Checkout Terms and conditions
Ensure that your Purchase Ts & Cs are addressing the requirements of a mandate.
As a reference see general guidance on Stripe documentation. Piano cannot provide exact text for your terms and conditions, however, at a minimum, you should ensure that your terms cover:
-
The customer’s consent to you initiating a payment or a series of payments on their behalf
-
The anticipated frequency of payments (i.e. is this a one-off payment or do you need consent for a series of future payments)
-
How the amount of the payment(s) taken will be determined
-
Ultimately, what your customer pays for, the frequency of payments and how the amount of the payment(s) will be determined is something we expect you already cover in your terms and conditions (although you should check this and confirm it is the case).
See an example text to obtain the customer’s consent to your organization initiating payment(s) on their behalf:
“I authorize [your business name] to send instructions to the financial institution that issued my card to take payments from my card account in accordance with the terms of my agreement with you.”
Stripe Support: “There is no regulatory requirement here for the merchant to pass consent captured to either Stripe or Issuer. It is a binding between you and your customer. These scenarios are different from a Direct Debit framework because, in the case of DDs, the mandate is managed by the customer directly with their bank (i.e. they can modify or revoke it over the issuer's interface).”
What is EMVco and which version is used?
EMVco is the underlying infrastructure used across the network to enable communication between the payment service providers, schemes, and acquiring and issuing banks. Its infrastructure is the one which manages the transaction assessment and triggers 3DS. It is developing new functionalities to minimize the impact of 3DS, and it is expected to release new versions, which the providers will need to implement.
Braintree uses CardinalCommerce (A Visa solution) for 3DS authentication, which is currently certified to version 2.2.0.
Stripe is certified with EMVCo directly and currently has certification for 2.2.0 at the moment.
Are all payment methods affected?
No, PSD2 3DS only applies to card payments, as such wallet payments or direct debit bank payments are out of the scope of SCA.
GoCardless - The EBA confirmed on 7 June 2019, that Strong Customer Authentication (‘SCA’) is not required for the set up of electronic ‘paperless’ direct debit mandates provided in favour of merchant payees. Specifically, the EBA confirmed:
SCA is only necessary where a PSP is involved in the setting up of such a mandate. Mandates given by the payer to the payee set up without the direct involvement of the payer’s PSP are not subject to SCA.
The EBA’s statement means that SCA only applies to ‘e-Mandates’ as defined in the SEPA Direct Debit Rulebooks, and not to other electronic direct debit mandates.
Only direct debit mandates that involve the payer’s PSP in their setup are Sepa e-Mandates, as defined by reference to the ‘electronic mandate’ option as set out in Annex VII of the SEPA Direct Debit Core and Business-to-Business Scheme Rulebooks (or equivalent).
The e-Mandate process is an optional feature that complements the SEPA direct debit scheme and is not in general use, due to the low availability of solutions provided by ASPSPs.
At a high level, whilst typically initiated by the Payee’s PSP, the e-Mandate process requires the direct involvement of the Payer’s PSP for authentication of the Payer’s bank details. Conversely, in a ‘paperless’ electronic direct debit mandate, the Payer’s PSP is not directly involved in the setup of the mandate at the point of involvement of the Payer.
Is there any reporting to better understand 3DS impact and exemptions?
Braintree: “… [we] don't have any native reporting that will tell you how many transactions are accepted through this exemption.”
Overall, we are able to capture and report on 3DS-related failures, usually present under the code of 2099, however, this is a general 3DS failure response and doesn’t allow distinguishing between different causes of the failure. These may vary from unsupported lack of supported APIs by the banks, 3DS challenge timeout caused by the end-user, 3DS connection timeout with the networks, customer not present to complete 3DS challenge, etc. EMVco should be working on improvements to enable better reporting, which will enable payment providers, platforms and merchants to better report on 3DS. Piano is dependent on the data being available from the providers and networks and currently has only very basic 3DS payment failure reporting.
Which payment methods and providers are affected by PSD2?
|
Provider |
Impact |
Features |
3DS Compatibility |
Provider Documentation |
|
Braintree Payments |
All card payments, except Apple Pay |
Price and Subscription adjusting features are affected |
|
https://www.braintreepayments.com/sk/resources/psd2-strong-customer-authentication-explained |
|
Stripe |
Card payments only, other methods are not affected |
Price and Subscription adjusting features are affected |
|
https://support.stripe.com/questions/subscriptions-and-strong-customer-authentication-sca |
|
GoCardless |
Paperless direct debit payments are exempt from SCA |
Features are not affected by SCA |
Not Available |
https://gocardless.com/guides/posts/an-introduction-to-psd2/ |
|
Cybersource |
All card payments except wallet-based methods |
Price and Subscription adjusting features are affected |
|
|
|
Klarna |
All card payments except wallet-based methods |
Price and Subscription adjusting features are affected |
|
|
|
Datatrans |
Card payments only, other methods are not affected |
Price and Subscription adjusting features are affected |
|
|
EU PSD2 Directive and Exemptions definition
Exemptions defined by COMMISSION DELEGATED REGULATION (EU) 2018/389 of 27 November 2017 supplementing Directive (EU) 2015/2366 of the European Parliament and of the Council with regard to regulatory technical standards for strong customer authentication and common and secure open standards of communication (formal EU Journal)
-
Low-value transaction constituted by the (MIT) Merchant initiated transaction exemption according to Article 16 of the EU PSD2 directive:
[excerpt] Low-value transactions
Payment service providers shall be allowed not to apply strong customer authentication, where the payer initiates a remote electronic payment transaction provided that the following conditions are met:
-
the amount of the remote electronic payment transaction does not exceed EUR 30; and
-
the cumulative amount of previous remote electronic payment transactions initiated by the payer since the last application of strong customer authentication does not exceed EUR 100; or
(c) the number of previous remote electronic payment transactions initiated by the payer since the last application of strong customer authentication does not exceed five consecutive individual remote electronic payment transactions.
-
Recurring transactions constituted by the (MIT) Merchant initiated transaction exemption according to Article 14 of the EU PSD2 directive:
[excerpt] Recurring transactions
-
Payment service providers shall apply strong customer authentication when a payer creates, amends, or initiates for the first time, a series of recurring transactions with the same amount and with the same payee.
-
Payment service providers shall be allowed not to apply strong customer authentication, subject to compliance with the general authentication requirements, for the initiation of all subsequent payment transactions included in the series of payment transactions referred to in paragraph in paragraph 1. [above]