#khadim-yaseen_api

1 messages · Page 1 of 1 (latest)

warm oasisBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1284081929670361099

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

crude cradle
#

Create SetupIntent
$intent = $stripe->setupIntents->create(
[
'customer' => $customer->id,
'automatic_payment_methods' => ['enabled' => true],
'usage' => 'off_session',
'metadata' => [
'from' => 'paymentElement',
'passbackconversiontrackingid' => $data['rtid'],
]
]
);

confirm setupIntent
const {error} = await stripe.confirmSetup({
elements,
clientSecret,
confirmParams: {
return_url: window.location.origin+'/success.html',
payment_method_data: {
billing_details: {
address: {
postal_code: postcode,
}
}
},
},
})

Create Subscription Via Webhook (setupintent.success)
$subscription = $stripe->subscriptions->create([
'customer' => $customer_id,
'items' => [['price' => $price_id]],
'default_payment_method' => $payment_method,
'collection_method' => 'charge_automatically',
'off_session' => true,
'payment_behavior' => 'default_incomplete',
'payment_settings' => ['save_default_payment_method' => 'on_subscription'],
'trial_period_days' => 3,
'expand' => ['latest_invoice.payment_intent', 'pending_setup_intent'],
'metadata' => [
'passbackconversiontrackingid' => $metadata['passbackconversiontrackingid'],
]
]);
echo 'Subscription ' . $subscription->id . ' is Created';

shrewd breach
#

Hey

In Live mode SetIntent succeeds but later requires 3DS for off-session payments.

In live mode, your integration should expect to handle 3DS at any time, because 3DS is something controled by the bank issuer and not Stripe.

#

So in live mode this could happens sometime

crude cradle
#

Isn't it that we authenticate and get the card verified on-session by the user and then can make off-session payments later?

shrewd breach
#

Yes it is. But there is nothing to prevent the bank issuer to request again a 3ds sometimes to re-verify.

crude cradle
#

I see, This means it won't happen for all the banks. We do authenticate the on-session.
But It will completely depend on the bank if it needs to re-verify later

shrewd breach
#

yes. Your integration need to handle these edge cases sometimes.

crude cradle
#

One last question,
Will this be also applicable if my subscription flow goes like this?

  • create user
  • Create subscription
  • confirm setupIntent

In this flow, the subscription is created on session and not later after confirming the setupIntent

warm oasisBOT
arctic glade
#

not sure that makes much sense, why would you have a SetupIntent after creating the Subscription?

crude cradle
#

Hi @arctic glade
When we create a subscription, It creates an setupIntent, that needs to be confirmed before the subscription becomes active or on trial

arctic glade
#

make sense but that's not how it works. If you create a subscription with trial_end/trial_period_end set, that immediately creates it, as status:trialing. It also returns a pending_setup_intent but it's not mandatory that that Intent is confirmed to make the Subscription become status:trialing, it already is immediately.

#

if you don't want to create the Subscription at all until after you have the details, you'd do a SI first, and then create the Subscription when it succeeds.

crude cradle
#

Yes in my current flow
I create a setupIntent first and then corfim it with confirmSetup.
and then via webhook on setupIntent.success, I create the subscription.
I followed this flow to prevent Incomplete subscription being created if confirmation fails on-session for some reason like card declines or insufficient funds.

Since with this flow there is a possibility that 3DS maybe required for some bank on off-session, even if 3ds is verified once on-session.
Which your colleage "os4m37" clarified to me.

I just wanted to confirm if 3DS may also be required off-session by some banks if instead of creating a setupIntent first, we simply create subscription with status incomplete initially and confirm it's setupIntent on-session. Which is the recommended flow I guess!
https://docs.stripe.com/billing/subscriptions/build-subscriptions?platform=web&ui=elements

I hope I made any sense

Build a subscriptions integration

Create and manage subscriptions to accept recurring payments.

arctic glade
#

I followed this flow to prevent Incomplete subscription being created if confirmation fails on-session for some reason like card declines or insufficient funds.

but incomplete subscriptions are a normal part of our designed integration, so you should just use them really.

crude cradle
#

Yes I understand that, But my client don't want to incomplete subscriptions created, it effects their tracking

arctic glade
#

fair, I would try to convince them to fix their tracking then and ignore status:"incomplete for example

crude cradle
#

Trust me I tried to convince him.

It would be helpful if you could confirm me if 3ds maybe required off-session by some bank for the recommended flow as well?

arctic glade
#

yes

#

any payment any time might require 3D Secure(or be declined), it's all at the issuing bank's discretion

crude cradle
#

Alright Thank you guys.
Appretiate it

warm oasisBOT
crude cradle
#

Hello

Can you please check this request ID :req_9yOqlsNxTORHzB

With the recommended subscription flow. This card didn't require a 3ds verification on off-session payment.
But gave this error: Card multi_use mandates cannot be used with PaymentIntents.

arctic glade
#

hmm I'm not sure, this is in livemode and using the Dashboard not the API? seems like a totally different question

#

it seems to be an issue related to charging card issued in India, which has a lot of complexity with e-mandates and is something my team doesn't know a lot about, I'd suggest opening a support ticket at https://support.stripe.com/?contact=true instead for livemode problems

crude cradle
#

Alright Understood, Yes this is the card issued in India.
Actually I tried to test the recommended flow with this card in live mode.

when I try to make the off-session payment on this payment by updating the subscription trial period to zero.
To initiate the charge.
I noticed it didn't required 3DS, but an e-mandates error. which I unserstand may arise with this particular card.

#

But with the different flow (setupIntent first), It asked for the 3DS.

weary bluff
#

Depends really on how the card is/was setup/saved. If there's a mandate error then perhaps it wasn't created correctly and therefore it's missing the mandate data necessary

crude cradle
#

Mandate error is not my concern actually. My integration only targets UK users. I used an card that's issued in India. That may be causing the madate error.
My concern is 3DS verfication for off-session

weary bluff
#

Well that's impossible. If 3DS is requested for an off-session payment then it will surface as a decline – you'll need to bring the customer on-session to provide payment details and attempt payment again