#Miran-subscription-3ds-zero

1 messages · Page 1 of 1 (latest)

shadow onyx
#

Hello! Yes this is certainly confusing. What I expect is happening here is that the 3DS flow is prompting auth for the initial 'verification' charge (of 0)

remote hedge
#

Then how can I make the amount correct at the first place?

shadow onyx
#

This is dependent on your integration, but it seems like:

  • The payment method is being 'setup' for future off-session (recurring) payments. This is the bank prompting for 3DS/auth. There's nothing to pay at that point as it's just a verification check.
  • The subsequent payment is accepted without auth because of previous auth step.
#

Can I ask how you are integrating?

remote hedge
#

We are using Laravel and stripe sdk, also Laravel Cashier to make the subscriptions, one time charges.

#

Here is our code -

#

$me->newSubscription('expert', $expertPlan)
->withPromotionCode($coupon)
->create($paymentMethod->id, [
'email' => $me->email,
'off_session' => TRUE, //for use when the subscription renews
]);

shadow onyx
#

Not overly familiar with Laravel Cashier. Let me check their docs

#

This is most likely an issue with how they built the plugin. But let's see

#

How are you creating the $paymentMethod?

#

Can't find that off_session parameter in their docs

remote hedge
#

stripe
.handleCardSetup(clientSecret, cardElement, {
payment_method_data: {
//billing_details: { name: cardHolderName.value }
}
})
.then(function(result) {
console.log(result);
if (result.error) {
// Inform the user if there was an error.
var errorElement = document.getElementById('card-errors');
errorElement.textContent = result.error.message;
} else {
console.log(result);
// Send the token to your server.
stripeTokenHandler(result.setupIntent.payment_method);
}
});

#

sorry for the messy code

#

I am not 100% sure about the off_session thing!

shadow onyx
#

Is this how Laravel recommend integrating?

remote hedge
#

Yes.

#

Saves lots of efforts

shadow onyx
#

So are you also creating a Setup Intent prior to calling handleCardSetup>

remote hedge
#

Yes.

#

The thing is, our application is almost live, so it's not feasible to change these critical issue at the last moment. So is there any way around?

shadow onyx
#

Is there any additional code after you create the subscription?

#

Are you calling confirmCardPayment with Stripe.js?

#

The handleCardSetup is likely what is prompting the 3DS verification for NOK 0,00

shadow onyx
#

Can you share the ID of the Payment Intent related to the subscription?

#

Or even just the Subscription ID

remote hedge
#

let me fetch those.

#

sub_1JxRcvIbABbFHjKR8OY3R3oG

shadow onyx
#

In an ideal world you can ditch the handleCardSetup (we don't recommend this flow with our direct integration because of issues like this)

#

Generally you'd create the Subscription, collect payment details, then confirm the Payment Intent

#

Laravel seemingly does it a little differently

#

So I think you need to adapt your client-side code a bit

remote hedge
#

okay, I'll try to do that. Thanks.

shadow onyx
#

What I would suggest you try (so it is more inline with our recommended integration path: https://stripe.com/docs/billing/subscriptions/build-subscription):

  1. Create the Subscription with Laravel.
  2. That will return a Subscription object with a payment_intent field (you'll need to expand that to get the full object and client_secret).
  3. Capture payment details with Stripe.js.
  4. Call confirmCardPayment using the client_secret from the Payment Intent and the Element. You'll also want to pass setup_future_usage: https://stripe.com/docs/api/payment_intents/confirm#confirm_payment_intent-setup_future_usage
#

setup_future_usage is what ensures the card is setup for future recurring payments when your customer is off-session. It's basically the same as what handleCardSetup is doing, but at the time of payment confirmation

#

So the 3DS UI will reflect the initial payment value