#Miran-subscription-3ds-zero
1 messages · Page 1 of 1 (latest)
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)
Then how can I make the amount correct at the first place?
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?
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
]);
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
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!
Is this how Laravel recommend integrating?
handleCardSetup is deprecated, that's all: https://stripe.com/docs/js/deprecated/handle_card_setup_element
Complete reference documentation for the Stripe JavaScript SDK.
So are you also creating a Setup Intent prior to calling handleCardSetup>
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?
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
Can you share the ID of the Payment Intent related to the subscription?
Or even just the Subscription ID
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 this is the API request that creates the Subscription (from Laravel): https://dashboard.stripe.com/logs/req_gOr9hqNDGj0AoB
So I think you need to adapt your client-side code a bit
okay, I'll try to do that. Thanks.
What I would suggest you try (so it is more inline with our recommended integration path: https://stripe.com/docs/billing/subscriptions/build-subscription):
- Create the Subscription with Laravel.
- That will return a Subscription object with a
payment_intentfield (you'll need to expand that to get the full object andclient_secret). - Capture payment details with Stripe.js.
- Call
confirmCardPaymentusing theclient_secretfrom the Payment Intent and the Element. You'll also want to passsetup_future_usage: https://stripe.com/docs/api/payment_intents/confirm#confirm_payment_intent-setup_future_usage
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
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