November 20, 2020 Update
We highly recommend that you begin implementing and testing immediately to meet the January 1st, 2021 deadline. Delaying any further may result in increased decline rates if 3DS2 is not enabled or working properly by that date and you are operating in the EEA.
Please contact both Zuora support and your Gateway Rep (or Gateway support) in order to ensure that you are enabled for 3DS2.
As of today, the following gateways are supported in Zuoras sandbox environment and production environments:
The EBA has announced that it will not be granting further widespread delays to enforcement regardless of the pandemic due to the length of its previous extension. If you are operating in the EEA, please review this list of impacted countries for a detailed breakdown of enforcement by country. Previous requests for delays by country that extended beyond the January 1st deadline are still in effect.
If a local regulator has not announced a delay, the assumption should still be that they plan to enforce SCA on January 1st, 2021. If you have any issues after January 1st, please contact Zuora Global Support AND contact your gateway directly.
Additional documentation for PSD2 and SCA can be found on our Knowledge Center.
September 3rd, 2019 Update
The EEA countries are all publishing updates to their timelines of PSD2 enforcement as delays have been announced. To help navigate the complexity of the enforcement, Braintree has published a cheatsheet outlining EEA countries that will be delaying their enforcement of PSD2 and SCA. Click here to learn more.
Zuora is continuing to roll out integrations with payment gateways for PSD2. A detailed list will be provided in an update later this week.
In the meantime, to enable this feature for your Zuora tenant, please contact Zuora Global Support AND contact your gateway directly to ensure they have this feature turned on as well.
Additional documentation for PSD2 and SCA is now available on our Knowledge Center.
August 15th, 2019 Update
In light of the EBA's decision to grant individual countries the ability to request an extension to the September 14 deadline for SCA compliance, Zuora is continuing to develop integrations to the gateways as discussed in the July 2019 update. It is Zuora's plan to meet the September 14 deadline.
As of today, CyberSource's 3DS2 solution is in Zuora's production environment and Adyen's is in Zuora's sandbox environment. If you want to enable this feature for your Zuora tenant, contact Zuora Global Support.
July 2019 Update
This community post will help our customers understand the new PSD2 regulation, how it impacts them, and what they need to do to prepare.
What is PSD2 and when does it go into effect?
PSD2 is an extensive revision of the European Unions Payment Services Directive regulations. PSD2 will be going into effect on September 14, 2019. It applies to online transactions where both the issuing and acquiring banks are located in the European Economic Area (EEA).
PSD2 objectives are the following:
What is SCA and why is it important?
SCA stands for Strong Customer Authentication and is one of the mandates of PSD2 that is most applicable to Zuora customers in the European Union. The SCA regulations are designed to protect consumers. While many tools exist to reduce fraud, one of the most effective is authentication validating a customers identify before they pay online.
With SCA, all electronic transactions will need authentication, using at least two of three possible methods:
Zuora recommends using 3DS2 (3DS v2) to provide your customers with SCA for European customers. 3DS stands for 3D Secure, an open standard used by major credit card brands to authenticate cardholders. 3DS can dramatically reduce fraud and increase authorisation approvals and is one of the ways for Payment Services Providers to comply with the SCA mandate. Starting September 14, 2019, issuing banks can decline certain payments that require SCA, but have not gone through authentication.
If your merchant account provider is based in the EEA - and you transact with customers in the EEA - you will need to do some work to prepare for this change. If you do not know who your merchant account provider is or where they are located, check with your gateway. For subscription businesses, merchants only have to present the 3DS flow on the initial purchase. Subsequent recurring subscription purchases are generally considered exempt from PSD2 and SCA unless the issuing bank declines the exemption.
3DS vs 3DS2 - whats the difference and why is it important?
3DS (3DS v1)
3DS2 (3DS v2)
Why is it important?
For payment cards only
Also supports mobile and digital wallets
Greater flexibility and support for mobile e-commerce
Designed for web desktop
Streamlined for mobile interaction models/devices
3DS2 adoption expected to be greater because it is easier to use
Higher false declines
Modified authentication flow
reduces false declines
Customers likelier to abandon transaction or use a different
No merchant opt-out or exceptions
Lower-value transactions exempted from validation, depending on the merchant's fraud rate
Greater flexibility and alignment of the protocol to the risk of a particular transaction
10 data points captured
Up to 150 data points captured
Issuer can make better decisions about the validity of the transaction with more data, preventing both fraudulent transactions as well as false positives
How Zuora is helping you comply with PSD2
Zuora provides seamless integration with your payment gateways, simplifying and automating collections. Zuora plans to integrate to each gateways 3DS2 capabilities. If your gateway is compliant and is providing a 3DS2 solution, Zuora intends to integrate to their solution by the September deadline.
Specific Payment Gateway Support for PSD2
Zuora is currently planning to enhance payment gateway integrations that support SCA through 3DS2 in advance of the September 14, 2019, PSD2 deadline. As of July 29, 2019 the following Gateways have provided us with their 3DS2 solution and Zuora is actively developing the integrations:
*These payment gateways may require a version update, migration or an additional feature to enable 3DS2 functionality; we recommend speaking directly with your gateway contacts as soon as possible.
Zuora is currently not planning to enhance support for the following payment gateways, because they either do not transact in the EEA or they have informed Zuora that they are not applicable to PSD2 (if these gateways do become applicable to PSD2 requirements and they provide Zuora with their 3DS2 integration, Zuora currently plans to provide support for these integrations at a later time):
As part of your comprehensive PSD2-compliant solution, Zuora currently intends to provide the following:
What will I have to change in my tenant?
Additional documention for PSD2 and SCA is now available on our Knowledge Center.
For existing recurring transactions, we will align to the gateway specifications. Details will be provided by the gateways, and Zuora currently plans to provide guidance on any changes required within your tenant. For questions, please post in the comment section below or reach out to your gateway provider directly.
We use Stripe for our payment gateway with hosted pages - do they support PSD2 and when will the Zuora integration to Stripe support it ?Thanks
We will be sending out a more official statement next week on how Zuora intends to help your organization comply with PSD2 and what you need to do, including which gateways will be ready by September 14th. Please stay tuned.
Hi, Braintree is not listed as one of the included or excluded gateways does this mean you're not developing an integration for this?
Hi @scottw_deputy - thanks for the catch! Yes - Braintree is included. We've updated our post.
@IanBennett - We have updated this page with new information for PSD2. Please let us know if you have any additional questions. Thanks so much!
@JustinLi Thanks for the update, can you clarify what "*These payment gateways may require a version update, migration or an additional feature to enable 3DS2 functionality" means? The KC page states that the integration with Braintree is using v2.81.0 of the Braintree Java JAR, are you saying we as a Customer need to confirm that 3DS2 works with this version or is this for something else?
Also when you say you're planning on releasing the enhancements before the 14th of September when exactly is this? Can we get a pre-release of the code in a Sandbox somewhere?
How and when will we be informed of the changes that need to be made on our side?
Hi @JustinLi do you have an answer to my question from above in relation to Braintree versions and whether there's a dev environment we can connect to?Thanks
Stripe released APIs for managing payments (both one-off and for subscriptions) a lot of time ago. It is possible update the integration by looking at the public documentation and the Stripe API reference. As for subscriptions, it is possible to refer to the following flows:Scenario 1: On-session First payment - Immediate charge: https://stripe.com/docs/billing/migration/strong-customer-authentication#scenario-1Scenario 2: Off-session First payment - Charge later: https://stripe.com/docs/billing/migration/strong-customer-authentication#scenario-2Scenario 3: Off-session Recurring payment (from the second charge onwards): https://stripe.com/docs/billing/migration/strong-customer-authentication#scenario-3Scenario 4: One-time invoices: https://stripe.com/docs/billing/migration/strong-customer-authentication#scenario-4I report below also the API reference that could be useful: https://stripe.com/docs/api
I have spoken to Braintree and they've said we need to make sure 3D Secure is enabled on our Braintree Account, however they couldn't confirm if it's version dependent. Can you please confirm this is going to work with the version you're developing the integration with? Also as our Subscription amounts vary month by month (as we're predominantly usage based) we need to submit transactions with either the recurring or unscheduled transaction flag to ensure the transactions (ongiong payment requests) are classified as exempt from PSD2 requirements. Link to the flags on the Braintree Dev site are at https://developers.braintreepayments.com/reference/request/transaction/sale/php#transaction_source Are these being supported in the update?
Please respond urgently as we need to start development in parallel with you and no response means we are unlikley to hit the deadline being mandated
It sounds like your conversation with Braintree might have been a little confusing since it sounds as if they assume you'll be doing all of the development which is unnecessary when using HPM so I want to clarify.
Our latest version of Braintree will support 3DS2 in both the HPM and via direct POST. Direct POST will require additional work, but I believe you are using the HPM so I will not touch on that. As part of the integration, we will be providing the challenge directly within the iFrame of HPM as well as flagging transactions with the recurring flag for you. There will be a requirement for you to get the 3DS2 feature enabled in your Zuora tenant(s), but that is all from our side.
If there is anything else you need to do for enablement then Braintree should be able to answer those.
We are using Stripe payment gateway, where-in we save customers' cards on Stripe and create CreditCardReferenceTransaction payment method on Zuora. How will such a kind of integration be supported and how should we design our workflows?
We are also using Stripe gateway as CreditReferenceTransactions as @arpan wrote above. We save in the same manner, credit card token, and reference id, and use this payment method for future recurring payments.
What actions have we to make to go through this preparation, to not to be affected actual payment methods and future payments?
We are using HPM with BlueSnap as our payment gateway.
I couldn't understand if there is any action needed from us.
Hi @arpan and @bteleky,
If you are generating your tokens outside of Zuora and importing your tokens to CCRef payment methods within Zuora then you are susceptible to SCA challenges within your solution where you are creating the token. You will need to work with Stripe to understand what needs to be done with your integration for 3DS2 compliance.
@gbarak, the first thing I would recommend is that you contact BlueSnap and make sure you are required to enable 3DS2 on your gateway as I believe Outbrain is domiciled in Israel. If so, you will not need to perform a migration or upgrade to a new version. The only requirement should be that you will need to submit a Support ticket to enable 3DS2 on your tenant(s) and then check a box within your gateway on each tenant to ensure that customers can be challenged. The details of this will be covered in the documentation for the gateway when it becomes available.
@TylerS that answer for stripe seems to apply to the intial capture of the card. What about further payment attempts generated from the Zuora end after the initial token is created?
@lancehendrickso if you are using a tokenized approach for capturing cards, there would likely be a need to pass back the NTI (network transaction id) into Zuora, from the gateway. If there is a challenge after the initial attempt then that would be handled either via the approach created in the initial transaction or via a credit card capture in Zuora's hosted payment pages 2.0. The latter of these (via hosted payment pages 2.0) would not create a tokenized credit card, but rather create a payment method with the actual credit card information.
Article says "Zuora is currently planning to enhance payment gateway integrations that support SCA through 3DS2 in advance of the September 14, 2019, PSD2 deadline"
It is now the 28th August 2019 and we haven't seen the feature. How is Zuora tracking to this date? When will the new functionality to support PSD2 be available in our sandboxes?
Do you have a date for Stripe compatibility release ?
We are still tracking towards the list that we have displayed in the original post. We will continue to provide updates like the one from August 15th to let you know of releases as they come out.
@IanBennett, Stripe's 3DS2 support should have released to sandbox today. A more official update will be added to the post listing what was pushed to sandbox today.
What about a client using CORS APIs (CreateAccount)... what are the fields which are supposed to be stored these "necessary IDs"... ?
> Stripe's 3DS2 support should have released to sandbox today.
How can we use it? I can't see anything in the drop down for payment gateways, only "Stripe v1"
EDIT: I can see "Stripe v2" now. This name is wrong as SetupIntents/PaymentMethod api is still on stripe v1 API. should be "Stripe v1 PaymentIntents" See https://stripe.com/docs/api/setup_intents
To enable any of our available integrations, you will need to create a Support ticket including your tenant ID requesting that support for 3DS2 is enabled. Upon doing that, you will need to enable 3DSecure 2 in the corresponding Payment Gateway in Zuora. For more details, you can refer to the guide on the Knowledge Center. Stripe's and Braintree's guidees should be updated in the next couple of days but you can review Cybersource as an example.
@Emmanuel you will need to pass at least the networkTransactionId to the corresponding field and additional tokens may also be included.
When using Stripe v2's 3DS2 feature, please make sure you have contacted Stripe Support to complete necessary configuration for your account to avoid below error when processing payment:400 [invalid_request_error/parameter_unknown] Received unknown parameter: payment_method_options[card][mit_exemption]
When we turn on 3DS2 feature on the Hosted Payment Pages, will that be smart enough to only trigger 3DS for non-US cards? In discussing this topic with Adyen, I wanted to know whether it would hurt if we sent ALL of our credit card traffic through 3DS (via the HPM), they said "It would definitely hurt." and "you should instead do it based on issuing country, amount, or if a certain risky risk rule triggers.". Now I'm concerned that we need to build additional logic to route cards to a different HPM depending on criteria. Please help me understand this better.
The European Banking Authority (EBA) requires that PSD2 comes into full effect on September 14, 2019. However, EBA agreed in June to allow national regulators to delay the enforcement date of SCA resulting from the general concerns over industry readiness.
As of September 8, 2019, more than half of EU members have announced to allow some transition period. Some of our payment gateway partners have gathered information about the SCA enforcement date delay announcements from different countries:
We are closely tracking the updates from our gateway partners and will continue to post the updates here as soon as more information is available.
The determination on whether a card can be challenged will be determined by the issuing bank based upon information sent from the gateway. Cards where the user is US-based, as an example, would not be challenged by the issuing bank and therefore would not be problematic.
@TylerS - thank you! sounds like we don't have to worry about this at all.
I have another question. We never enabled 3DS, and are going straight to 3DS2. I came across this article on 3DS, however, and I'm wondering about some specifics and how it will apply to us (https://knowledgecenter.zuora.com/CB_Billing/LA_Hosted_Payment_Pages/B_Payment_Pages_2.0/Configure_Advanced_Security_Checks_for_Payment_Pages_2.0/3D_Secure_for_Payment_Pages_2.0)
One of the requirements mentioned is
Does this also apply to 3DS2? If so - how would you recommend we implement this for Free Trial signups that later convert automatically to paid?
I'm curious how the Payment Method Updater fits into PSD2. It updates the cards - but what happens once 3DS2 is in place?
Do you guys have something documenting 3DS2 response parameters, similar to this document? https://knowledgecenter.zuora.com/CB_Billing/LA_Hosted_Payment_Pages/B_Payment_Pages_2.0/Configure_Advanced_Security_Checks_for_Payment_Pages_2.0/3D_Secure_for_Payment_Pages_2.0/3D_Secure_Response_Parameters
We are seeing some fields returned with rather large values (like "enrollCheckPaymentData_1")
Could you please log a Support ticket for questions with this level of specificity?
@TylerS - for which one of my messages
That would be for your question regarding response parameters.
In regards to authorization amounts, our transactions are Merchant Initiated Transactions (MITs) and are therefore exempt from SCA requirements. The only Cardholder Initiated Transactions (CITs) that we perform are the capture of the card details which is susceptible to a challenge. You do not have to worry about updating your authorization amount as we authorize utilizing the default amount set in the gateway settings.
For the PMU, what are your concerns specifically?
Thanks for all of your questions! We've updated the Community post with another update.
Well done Zuora for getting this one out of the door for Cybersource. We'll kick the tyres in in our Greenfield project and let you know how we get on