3D secure problems with off_session=true

[garygreen]

• Cashier Version: 12.2.0
• Laravel Version: 7.25.0
• PHP Version: 7.3
• Database Driver & Version: n/a

Description:

Currently cashier forces off_session = true which is causing issues with 3D Secure payments for subscription creations when user is on site.

According to Stripe, if you set off_session=true this means you are telling Stripe the initial subscription setup is being conducted with the user offsite. This means Stripe will favour non-request of 3D secure checks, unless absolutely required.

This has been confirmed by one of Stripe's senior engineers and they recommend to not use off_session=true if the user is on site when the subscription is being created.

Steps To Reproduce:

This can be replicated by having your radar rules configured to require 3d secure (see below screenshot) and using a "supported" 3d card testing number (4000000000003055) with off_session=true - you'll notice it won't request for 3d secure. However it WILL request for it if off_session=false

Suggested fix

Could we have a way of configuring this value in Cashier? Would it make sense to have the default value to be off_session=false ? I think there maybe some overlap/confusion between setup_future_usage = off_session on payment intents.

[driesvints]

Heya, bit strapped on time but I'll try check in on this and reproduce it on Thursday.

You can already overwrite this with the subscriptionOptions btw: https://github.com/laravel/cashier-stripe/blob/12.x/src/SubscriptionBuilder.php#L242

[garygreen]

thanks

[driesvints]

Still haven't gotten to this sorry. It's been a bit busy with the Laravel release. I'm still planning to look at this eventually.

[garygreen]

No problem 😊

[garygreen]

For a bit more info, this is what we received from Stripe support when we were diagnosing the issue:

These are all set to 'off_session = "true"', I have confirmed this with some of our senior development team, this is normally used to to bypass the 3ds as followed by the documentation that I am adding below[1]. I am afraid that while this is active, then the 3ds would be bypassed everytime.

For some reference "off_session" is a command used for when a customer is offline, but a payment will still go through. In order to go through the 3ds process the customer must be online, this is not often possible and can cause issues, this is where the "off_session" comes into play. The document I am adding will have some more detailed information on this issue for you[1]. But I will add a snippet of this here for you for your convenience.

https://stripe.com/docs/strong-customer-authentication/migration#other-off-session

[driesvints]

@garygreen I've finally managed to get to this. I've been talking to some contacts at Stripe about this. From the looks of things it indeed seems sense to let the default be false for off_session as it seems an on session new subscription is the more common use case.

An off session subscription start could be for when you start a subscription in the future through a script or an API request when the user isn't directly present. We can update the docs for this and maybe provide a new method for initializing off session subscription creations.

It's also important to note that off_session is also needed for when a subscription starts after a trialing period. I'm checking with Stripe is this is done by Stripe itself though. Waiting for their answer.

The first possible moment to change the default is the next major version. I'm gonna wait a bit with doing that until all questions I've asked Stripe are answered. In the meantime you can manually set it to false by passing it like so:

$user->newSubscription('main', 'plan')->create($pm, [], ['off_session' => true]);

Thanks for the issue btw.

[driesvints]

Hey there, first of all sorry it took me this long to get this one ahead. I've had another check in with my contacts at Stripe which told me that this really depends on your situation. We moved over to the current default because the behavior you're suggested caused quite some problems for our users. See #764 & #743

Therefor since we only gotten one report for asking the opposite behavior we're going to leave the current behavior in place. You can already request the opposite behavior by using the example from above.

I'm not quite sure who you spoke to at Stripe but it might be best to let them know that the opinions differ a bit here. Still, thanks for raising this.