#_nerder
1 messages · Page 1 of 1 (latest)
Hi, could you elaborate what is different than your expectation? Normally a Subsscription will be created anyway
Since in my integration in order to create a subscription i'm asking to insert the card details, I'm expecting them to be there basically
The fact that they are not attached correctly for some users (not all users) it's quite frustrating because this means that I need to ask them again to add it
when they have done it already
So the issue is some of customers aren't attached correctly?
Can you share some example Id?
yes give me a sec
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
While this for instance (with the same code and integration) has it: https://dashboard.stripe.com/customers/cus_OhMP5BQaaEW1Fm
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
seems like a 3DSecure failure (which is quite common), but I want the subscription creation to fail in that case
Could you share the request you created the Subscription? req_xxx from https://dashboard.stripe.com/test/logs
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
should be this one
might be because the payment_behavior?
i'm doing that because i need to client_secret
Yep. Can you try chaning that to error_if_incomplete?
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
Thx
ok, but probably I want to do that ONLY in case i'm creating a subscription with a free trial right?
because it seems to me that every time a 3DS auth is required the sub creation fails
considering that in Europe is required, it means that all payments (to create a sub) will suddently fail basically
or am i reading the doc wrong?
For example, if a payment method requires 3DS authentication due to SCA regulation and further user action is needed, this parameter does not create a subscription and returns an error instead.
Your read is correct, and yes error_if_incomplete will fail all requests to create a Subscription in case of 3DS. You would want to scope out in which case you want this behavior, and which case you want the default_incomplete behavior
(Best to test out in Test mode)
I don't think this solution works in any-case, because 3DS is required for 90% cards in Europe
so it will not possible to create a sub with an initial free trial
I need to find a better solution than this because default_incomplete is necessary for me to handle payments (and non-payments like in this case) with 3DS
or i'm not understanding 3DS, in my head this is the auth redirection that you do with your bank app (or website) to authorize an online payment
Yes 3DS is the auth redirection, customer will see it on a bank provided website
So you basically want to keep default_incomplete, but only if this is a trial and needs 3DS, you don't want the Subscription to be created at all?
no, I don't want the subscription created at all only if 3DS fails
which is the case for subscription without an initial free trial (bacause a payment completed is required in order to create it)
this seems to be the problem
altough the proposed solution is very inconvinient, because it means that I need to change the flow of my app
and collect the payment method first, and later let the customer chose a subscription
the ideal flow would be to do it all at once
(Step 0) You send a request, a customer input a card and 3DS is display, there are 2 possibilities:
1- If the 3DS succeeded, you will have a Subscription
2- If the 3DS failed, you don't want to create a Subscription at all.
At the timing of Step 0 there shouldn't be a Subscription yet
To implement this, probably you would want to create a SetupIntent first in Step 0, then based on its result branch out for 1. and 2.
ok I see what you mean
so in the frontend, it will be the same the customer chose a product and insert their payment details
under the hood what I do is to FIRST create a setup_intent, IF success, then I go ahead and create a subscription ELSE i fail and not create anything
Yep
then it means that I need to create the subscription only when the webhook tells me that they setup_intent has completed successfully?
Yep yep
ok, gotcha
and how can I distinguish between a "setup_intent.created" event (not sure if is called like that) that has been generated from a subscription creation and not simply from a new payment method attached?
Hmm good question. you want to compare Step 0 above with when a Subscription created with a pending_setup_intent, correct?
Let me quickly try it
Hmm yes hard to know just from setup_intent.created You probably want to observe customer.subscription.created coming at almost same time frame, and make sure its pending_setup_intent isn't the id from setup_intent.created