SCA (strong customer authentication) compliant

[tttp]

as of sept 15 2019, if you use houdini in Europe (both NGO and donor), you need to be compliant with SCA, somewhat similar to 3D secure, ie an extra confirmation step of the payment from your smartphone banking application or your bank website)

This is a major change for houdini, both for onsite (ie one off donation of first recurring donation) and offsite (recurring donations)

More information about the migration as described by stripe https://stripe.com/docs/payments/payment-intents/migration#legacy-checkout

What needs to be done:

1. updating stripe API version(?)
2. migrating from "charge" to "payment intent" (when reading charges)
3. implement webhooks so stripe can confirm the payment (when extra authentication kicks in and delay the confirmation)
4. change the UI to handle that extra authentication step
5. change the recurring donations to handle if a monthly donation is on hold until confirmation by the donor

Some broader points to be discussed (that would potentially simplify the migration as the underlying system is already SCA compliant)

1. migrating the UI to stripe element
2. migrating the donations to subscriptions (ie. it's stripe that handles all the donations and frequency)

[wwahammy]

as of sept 15 2019, if you use houdini in Europe (both NGO and donor), you need to be compliant with SCA, somewhat similar to 3D secure, ie an extra confirmation step of the payment from your smartphone banking application or your bank website)

This is a major change for houdini, both for onsite (ie one off donation of first recurring donation) and offsite (recurring donations) Quick thought: we should come up with a better name for this as we use online and offsite in different ways throughout Houdini

More information about the migration as described by stripe https://stripe.com/docs/payments/payment-intents/migration#legacy-checkout

What needs to be done:

1. updating stripe API version(?)

I suspect we will need to.

2. migrating from "charge" to "payment intent" (when reading charges)

In Houdini itself, I'd like to keep each as an option. My hope is that we could complete this for V2. That may not be a quick enough timeline for those in Europe.

3. implement webhooks so stripe can confirm the payment (when extra authentication kicks in and delay the confirmation)

We need this either way.

4. change the UI to handle that extra authentication step

Definitely.

5. change the recurring donations to handle if a monthly donation is on hold until confirmation by the donor

I suspect this will be a significant change. We'd be adding a status for donations which doesn't currently exist.

Some broader points to be discussed (that would potentially simplify the migration as the underlying system is already SCA compliant)

1. migrating the UI to stripe element

We did this for CommitChange but I have not upstreamed yet. I was personally waiting until we got into V2. I'll

2. migrating the donations to subscriptions (ie. it's stripe that handles all the donations and frequency)

I'm unsure on this. The big concern I see is that recurring donations will be inconsistent between Stripe and other payment providers. Additionally, there would have to be a change in how card details get updated to Stripe itself.

Ideally, I believe recurring donations should stay in Houdini. That said, the timeframe for EU might require this as, at the very least, a stop gap.

[tttp]

The big concern I see is that recurring donations will be inconsistent between Stripe and other payment providers

I think it's unavoidable, because each of them will have their implementation. eg paypal run their subscription payment themselves, SEPA direct debit is a bit different too (eg the debit day is different than the donation day).

I think trying to "hide" these potential differences is a lost battle as soon as the number of payment providers > 1 ;)

[idengager]

Hey @ericschultz, I have a couple of questions, I'm sure you missed me 😀

• What's the hold-up for merging in the Stripe Element into Houdini master?
• Why would you rather keep the recurring donations logic in Houdini? I can see that as a way to maybe integrate more payments providers but it's also a whole lot of code to maintain.

recurring donations will be inconsistent between Stripe and other payment providers

I agree with Xavier, this seems unavoidable with different payment providers.

[wwahammy]

Hey @ericschultz, I have a couple of questions, I'm sure you missed me grinning

We did miss you! Welcome back Kasia!

* What's the hold-up for merging in the Stripe Element into Houdini master?

The patch from CC was done very quickly due to a short internal deadline so I didn't make it an actual option. I think Stripe Elements should be an option/a strongly preferred option. That said, I think Stripe Elements should not be the ONLY option for Stripe payments, the advantage with the default now is Houdini can run entirely using open source javascript. So Elements should be an option, not a default. We should add a setting into the setting files for Stripe Elements.

* Why would you rather keep the recurring donations logic in Houdini? I can see that as a way to maybe integrate more payments providers but it's also a whole lot of code to maintain.

recurring donations will be inconsistent between Stripe and other payment providers

I agree with Xavier, this seems unavoidable with different payment providers.

I think we're going to need support for both internal and external logic. There are providers, like Stripe, where you can outsource the recurring donation to them (although to date, we do it internally). There are providers, like say direct SEPA or ACH, where the recurring donation logic must be done in Houdini. So I don't think it's either-or going forward.

[tttp]

@ericschultz As for the stripe integration, is the current solution more opensource friendly than stripe elements? in both case, we do rely on code that has the same (non FLOSS ) licence, isn't it?

[tttp]

For SEPA, we do rely on an external solution (civicrm SEPA) for the monthtly debit, but in theory, the easiest path (if not the cheapest) would be to use stripe and payment intent, that seems to allow to process SEPA, ACH and a bunch of other national payment systems (eg iDEAL in the NL)... I think using the same subscription method

[wwahammy]

@ericschultz As for the stripe integration, is the current solution more opensource friendly than stripe elements? in both case, we do rely on code that has the same (non FLOSS ) licence, isn't it?

The default Stripe integration uses a custom replacement for the Stripe tokenization library. I think it's important that we keep that as an option even if most people don't use it.

[wwahammy]

For SEPA, we do rely on an external solution (civicrm SEPA) for the monthtly debit, but in theory, the easiest path (if not the cheapest) would be to use stripe and payment intent, that seems to allow to process SEPA, ACH and a bunch of other national payment systems (eg iDEAL in the NL)... I think using the same subscription method

Ya, I think it makes sense for a lot of orgs. But you never know what platforms we'll want to support so we don't want to box ourselves in too much.

[tttp]

So I had a discussion with stripe and 1) US based organisations can switch to payment intent instead of using charge without any other change, so @ericschultz it means we shouldn't have to keep two different branch/code. This also opens the option to use ACH from stripe if I got it right

2) For @idengager, when doing the first recurring donation, we need to set up a "merchant-initiated transactions." https://stripe.com/docs/payments/cards/reusing-cards it seems it's a parameter on the stripe API to notify them we are going to re-use this card later

AND that the future recurring transactions are exempted from SCA

That is a good news ;)

I'm still digging to evaluate the benefit of switching to subscriptions, but doesn't seem to be as useful as I first understood it

[wwahammy]

@tttp That's good to hear. I'm a little unsure on moving to PaymentIntent totally. I'd need to understand more about the plan.

Future recurring transactions are exempted from SCA? I was under the impression there was a chance they could still require SCA in some situations.

Also, I stumbled on a way on Stripe to implement SCA without using the PaymentIntent API which would require less change to Houdini (I can't for the life of me find the info again). I don't know that it's the best way but it's something you may want to consider.

[idengager]

Also, I stumbled on a way on Stripe to implement SCA without using the PaymentIntent API which would require less change to Houdini (I can't for the life of me find the info again).

@ericschultz Did you find it, by any chance? Not sure if we want to go that way, but always good to see more options!

[wwahammy]

@idengager I found it! https://stripe.com/docs/payments/payment-intents/quickstart#manual-confirmation-flow

[tttp]

@idengager,

could you remove the zip:

CardElement accepts all the options as defined in Stripe.js reference, so you can set hidePostalCode=true.