Set off_session parameter to true when creating a new subscription

[marcbelletre]

Set off_session parameter to true when creating a new subscription to tell Stripe that the recurring payments can be made off session. Without this parameter (which is false by default) all other payments will throw IncompletePayment exceptions.

This fixes issue #743.

[SlyDave]

Tested against all the Stripe test cards.

Second 3DS check upon first payment of subscription doesn't occur (unless the test card enforces it to do so). This holds true for subscriptions with trial periods (when the trial ends the first payment is taken without a 3DS check unless the test card enforces it)

I also note that Stripe correctly sends out emails (if configured to do so) when the 3DS check is off-session. which it wasn't doing before.

[skollro]

Can confirm this fixes #743, hopefully it is merged soon!

[taylorotwell]

@driesvints seems to make sense to me but you can review.

[azimidev]

You might want to add option 'confirm' => true as well as 'off_session' => true maybe for charge method according to this:
https://youtu.be/95qSebQrm5E?t=2393

[driesvints]

But when you're performing a charge you're always on session?

[SlyDave]

Incorrect, a automatically renewing subscription (for example) will process a charge off session. As will collecting payment details on session and processing the charge when the customer isn't there (like how much of America does card payments offline still).

Adding confirm = true is interesting, as it clearly wasn't required to make it all work, but seems like it should be to record the fact the user did authorise us to make the charge. One assumes without it stripe notes we charged off session without confirmation, as to what effect that has...

[driesvints]

@SlyDave we're talking about the charge method for one-off charges, not subscriptions.

[azimidev]

@driesvints not always. with off_session we can charge the customer with $user->defaultPaymentMethod()->id. If the card needs re-authentication then it will throw an exception which from that we need to pass payment_intent->id as a parameter to

$paymentIntent = PaymentIntent::retrieve($paymentIntentId)

(hold off to payment_method->id) and use $paymentIntent response in JS again with stripe.handleCardPayment like this (such a pain)

Stripe.handleCardPayment(paymentIntent.client_secret, {
	payment_method: paymentMethodId,
})
.then(response => {
	if (response.error) {
		console.log(response.error.message);
	} else {
	    // Success!
            // Persist do whatever you want
	}
});

I mean the front end isn't a problem but it would be nice Cashier had API for

$paymentIntent = PaymentIntent::retrieve($paymentIntentId)

Kind of like $user->createSetupIntent(). we don't have this do we?

[SlyDave]

My apologises, must have got confused with this being a pull request for subscriptions and not a new issue raised for a different concern, my bad, carry on. 😁

[driesvints]

@hassanazimi you can pass this with the $options array I guess?

[azimidev]

@driesvints absolutely!