Blesta unable to accept payments from European credit cards after September

[Max]

Be aware that using strong customer authentication methods such as Securecode/3Ds becomes mandatory when taking payments from European customers after 14 September 2019.

For subscriptions the first payment should be authenticated, but subsequent payments do not.

So all merchant payment gateways should be updated, or payment processing will simply stop working.

 

See the articles published by the various payment gateways for details. E.g.: https://stripe.com/en-US/guides/strong-customer-authentication

[SamP]

Will Blesta payment gateways get upgrades to accommodate this new legislation second Payment Services Directive (PSD2)  ?

[fossxplorer]

I do own an unbranded Blesta license and i'm totally dependent on this feature to be added to Blesta and the Stripe gateway. I got the following from Stripe:

We wanted to remind you about required changes to your Stripe integration. Upcoming industry-wide regulation will require Strong Customer Authentication (SCA) on many European payments starting 14 September. Unless you take action, payments that aren't authenticated may be declined by your customers' banks.

	Our information shows your business will be impacted by SCA, and that you still need to make changes to your Stripe integration to get ready for these new requirements. As this change may require additional software development, we strongly recommend that you start updating your integration as soon as possible.

Visit the Dashboard to plan and start implementing the changes you'll need to make before 14 September.

@Paul Can you please take a closer look at this issue so we don't loose customers and money? 

[Michael]

38 minutes ago, fossxplorer said:

I do own an unbranded Blesta license and i'm totally dependent on this feature to be added to Blesta and the Stripe gateway. I got the following from Stripe:

We wanted to remind you about required changes to your Stripe integration. Upcoming industry-wide regulation will require Strong Customer Authentication (SCA) on many European payments starting 14 September. Unless you take action, payments that aren't authenticated may be declined by your customers' banks.

	Our information shows your business will be impacted by SCA, and that you still need to make changes to your Stripe integration to get ready for these new requirements. As this change may require additional software development, we strongly recommend that you start updating your integration as soon as possible.

Visit the Dashboard to plan and start implementing the changes you'll need to make before 14 September.

@Paul Can you please take a closer look at this issue so we don't loose customers and money? 

Paul is working with the guys to get Stripe 3DS and they are doing it in the core so other gateways can use 3D Secure.

Part of CORE-3068

[fossxplorer]

@blesta.store that is fantastic news for many customers of Blesta!

[Paul]

Stripe 3DS is in progress.. as in, code is actively being written for this.

[Max]

On 7/27/2019 at 1:39 PM, Blesta.Store said:

Part of CORE-3068

 

I think some things are getting mixed up in the comments on that issue.

Tokenization (stripe.js) has nothing to do with 3DS.

 

3DS/SCA is more about redirecting the customer to the website of his bank, to perform 2-factor-authentication there and authenticate the payment.

Customer not only needs a credit card number, but also confirm the payment through the app of his bank or a hardware token nowadays.

See the Payment Intents API for Stripe.

[Paul]

13 minutes ago, Max said:

 

I think some things are getting mixed up in the comments on that issue.

Tokenization (stripe.js) has nothing to do with 3DS.

 

3DS/SCA is more about redirecting the customer to the website of his bank, to perform 2-factor-authentication there and authenticate the payment.

Customer not only needs a credit card number, but also confirm the payment through the app of his bank or a hardware token nowadays.

See the Payment Intents API for Stripe.

What is getting mixed up exactly? CORE-3068 is for implementing Stripe 3DS, and the core changes required to support it.

[Max]

Just now, Paul said:

What is getting mixed up exactly? CORE-3068 is for implementing Stripe 3DS, and the core changes required to support it.

As far as I can see Johnathan only listed the changes needed for card tokenization.

As in let Stripe.js collect the digits of a credit card number, let the browser Javascript phone it back to Stripe, get a token in return.

That is only to prevent the credit card number touching your own server, and yes, that is best practice, and you should have that too.

 

However that alone does not give you SCA support yet.

Be aware that there is a reasonable change that the customer may be leaving your website page totally during the process, and does not stay on your page (like do is the case with just card tokenization methods like stripe.js)

And if all goes great, he may be redirected back to it some time later.

So make sure that all payment session information is stored somewhere. Preferably in the database.

Also be prepared for the case that some banks do not redirect the customer back to you automatically, and require the customer to click some link to return to shop.

Some customers over see that and close their browser instead.

If you do want to receive payment in the case the customer did confirm the payment, but is not redirected to you, and does not click the link, you should implement webhooks to listen for the event that payment was confirmed and finalize the charge then. Otherwise it is not processed

 

You probably also don't want to put your customer through the confirmation process every month for every recurring payment...

If you want Stripe/the bank to remember that you already completed the process for the first payment the customer did, and want to indicate you should be exempt for recurring transactions, it requires that you create Stripe Customer objects, and save the payment details to that after the initial charge.

You should store the "id" of that customer object in your database (instead of the actual card details).

 

And similar changes like that.

[Paul]

11 minutes ago, Max said:

As far as I can see Johnathan only listed the changes needed for card tokenization.

As in let Stripe.js collect the digits of a credit card number, let the browser Javascript phone it back to Stripe, get a token in return.

That is only to prevent the credit card number touching your own server, and yes, that is best practice, and you should have that too.

 

However that alone does not give you SCA support yet.

Be aware that there is a reasonable change that the customer may be leaving your website page totally during the process, and does not stay on your page (like do is the case with just card tokenization methods like stripe.js)

And if all goes great, he may be redirected back to it some time later.

So make sure that all payment session information is stored somewhere. Preferably in the database.

Also be prepared for the case that some banks do not redirect the customer back to you automatically, and require the customer to click some link to return to shop.

Some customers over see that and close their browser instead.

If you do want to receive payment in the case the customer did confirm the payment, but is not redirected to you, and does not click the link, you should implement webhooks to listen for the event that payment was confirmed and finalize the charge then. Otherwise it is not processed

 

You probably also don't want to put your customer through the confirmation process every month for every recurring payment...

If you want Stripe/the bank to remember that you already completed the process for the first payment the customer did, and want to indicate you should be exempt for recurring transactions, it requires that you create Stripe Customer objects, and save the payment details to that after the initial charge.

You should store the "id" of that customer object in your database (instead of the actual card details).

 

And similar changes like that.

My head isn't as deep in it as Jonathan and Tyson, but that sounds right and I don't think we are overlooking anything. The ability to handle tokenization without passthrough via stripe.js is necessary to be able to support 3DS as far as I'm aware, so we're kind of addressing 2 things at once. If you'd like to test it out when we have something available that would be great. Since it requires core changes, it will likely require 4.7 beta.

[Max]

12 minutes ago, Paul said:

My head isn't as deep in it as Jonathan and Tyson, but that sounds right and I don't think we are overlooking anything. The ability to handle tokenization without passthrough via stripe.js is necessary to be able to support 3DS as far as I'm aware, so we're kind of addressing 2 things at once.

Just saying that it is a "little" bit more work than just the points stated in the issue.

If you were already aware of that, and that were just the first things you wanted to get started with, rather than the whole plan of action, ignore I mentioned it. :-)

 

Quote

If you'd like to test it out when we have something available that would be great. Since it requires core changes, it will likely require 4.7 beta.

 

No sorry.

I am not using Blesta in production, but still have my own (ancient) home made billing system for now.

May switch some day, and would like to see your software working perfectly if/when we do, but cannot test it with real customers right now.

[Jono]

Hi, just to chime in on this.  Obviously it is still a work in progress but our goal in this process is to create a stripe integration that will address any security concerns that people have with the current one.  Primarily this includes adding 3DS through Stripe and using Stripe.js to save payment details without them every touching the Blesta server.   Both can be accomplished through the use of Stripe Elements through Stripe.js.  When I mention adding the ability for a gateway to modify the credit card form, that means for stripe it could use those things.  The 3DS process is already a part of Stripe.js and stripe elements as long as we set things up correctly.  That is not specifically laid out in the task so I hope to be able to update it and say more specifically and in depth how it will be implemented.

[MDHMatt]

hi any news if this will be in 4.6.1? even in beta, september is only 2 weeks away and id like to still use stripe and not add aditional merchants

[Paul]

6 hours ago, MDHMatt said:

hi any news if this will be in 4.6.1? even in beta, september is only 2 weeks away and id like to still use stripe and not add aditional merchants

We don't release new features in bug patch. MAJOR.MINOR.BUG. Stripe 3DS will be in 4.7, beta soon. Wrapping up now.

[Bloory]

Just as a heads up, the legislation is being slowed down in response to concerns from online Traders.

[Bloory]

Only in the UK maybe: