Jump to content

Blesta unable to accept payments from European credit cards after September


Max

Recommended Posts

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

Link to comment
Share on other sites

  • 2 months later...
  • 4 weeks later...

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? 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 3 weeks later...
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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...