SCA compliance

Hi @nomadarod

Hope you are doing fine!

In order to meet SCA requirements, Stripe Card payments require to configure 3D Secure. This feature assign rules to dynamically request a verification when creating or confirming a PaymentIntent. This rules should be configured in the 3D Secure Radar rules in your Stripe Dashboard.

You can find more information about these settings in this page:
https://stripe.com/docs/payments/3d-secure

And more specifically in this section:
https://stripe.com/docs/payments/3d-secure#three-ds-radar

About this question:

And is it possible to send the client to the Stripe page that corresponds to the product that he/she chose?

It may not be possible to forward customers to the Stripe page, since the objective of the plugin is to handle all the payment process without the customer needing to leave the site. In case you need your customer to proceed with the purchase process in Stripe, you can create a Payment Page as an alternative, but then, you may need to create links from your site to those pages, but this information won’t be recorded in Forminator:
https://stripe.com/docs/connect/creating-a-payments-page

Hope this information helps, let me know if you have additional questions or concerns.

Kind regards

Luis

Hi Luis,

I turned on the “Radar Rules” in the settings, but I don’t see any information suggesting that I need to do anything else in order to be SCA compliant. Did I miss anything?

But I did found “Major card brands no longer support 3D Secure 1. To continue using 3D Secure, adopt the Payment Intents API or Setup Intents API” . Is this taken into consideration when using forminator’s integration?

Thanks

Rod

Hi @nomadarod

Stripe implementation in Forminator already uses Payment Intents API to handle payments.

On your Stripe’s end, this guide should apply:

https://stripe.com/docs/payments/3d-secure#three-ds-radar

However, I think it’s important to mention here that there are additional factors involved:

– there may be transaction authorization requests issued by Stripe in that sense that according to this configuration and their internal settings but not necessarily for all transactions (e.g. if the transaction doesn’t rise any “red flags” in their fraud protection rules and the amount is relatively small)

– if transaction doesn’t trigger 3DS on Stripe end, then it’s up to card issuer/bank whether to require it or not and those rules are really different depending on that; in fact they may be even different between different types of card issued by the same bank; so it’s really difficult to say based only on form behavior whether such auth is expected or not.

In general though: Forminator simply incorporates – via Stripe API – Stripe payment forms and all the transaction flow (under the hood) is fully performed and handled by Stripe code. Basically, we only “tell” Stripe “hey, we want to make payment of that amount, display your form and do your magic” and upon form submission Stripe processes that all, including 3DS if needed.

Best regards,
Adam

Hi Adam. Thanks! That made it more clear to me.

And bout the Stripe plans that I create, do I need to be very specific and/or even have a corresponding product page in stripe’s end? In order to be SCA compliant, I mean?

For example, as the price is a variable in forminator’s end, do I need to create a plan for each combination possible (product one x1; product one x2; product two x1, etc?). What is the point of these plans?

Thanks

Rod

Hi @nomadarod

And bout the Stripe plans that I create, do I need to be very specific and/or even have a corresponding product page in stripe’s end? In order to be SCA compliant, I mean?

That’s a fair question but I’m afraid it’s not to us. We are not qualified to give any legal or law-related advise (personally, I don’t even have much of knowledge in that area) and that actually goes way outside the “technical aspects of Forminator”.

So as much as I’d love to give you response to that, I’m afraid I’m not really able to.

For example, as the price is a variable in forminator’s end, do I need to create a plan for each combination possible (product one x1; product one x2; product two x1, etc?). What is the point of these plans?

Point of plans is to provide you with some additional “flexibility” of charging different fees and you may use them but you don’t have to – that depends on your needs.

For example:

1. you only have a single, fixed price on the form – you don’t need multiple plans, you just create one plan and set it to “fixed” amount

2. you have price that may vary but that’s based on the choices that may be calculated based on other fields (for example “How many items?” where single item prices is fixed) – again, you only need single plan which is set to “variable” and the source of the amount is your calculation field

3. but you may also need to have
a) a mix of fixed and variable prices depending on form choices
b) and eg. amounts that vary but based on “incalculable” fields or in some sort of “impossible” calculations where you actually need to have two different calculation fields to be source of amount – in which case you set two plans, setting different calculation as source and make them conditionally processed.

I don’t have a simple “real life” example scenario in my head at this very moment but in general – plans usually come to play when you need to “conditionally decide” how much to charge based on some criteria that cannot be or are difficult to be handled by a simple calculation.

I hope that makes some sense.

Best regards,
Adam

• This reply was modified 1 year, 2 months ago by Adam - WPMU DEV Support. Reason: Typo: corrected "era" to "area"

Yes it does. Thank you very much for your time!

Best regards

Rod

Hi @nomadarod,

Since we haven’t heard from you for a while. I’ll mark this thread as resolved for now. Please feel free to re-open the thread if you need further assistance.

Best Regards
Nithin