didi1982_code

[cosmic holly]

👋 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/1234515382799437824

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

[acoustic hazel]

Hello

[valid pilot]

Hi

[acoustic hazel]

Validation errors will be synchronous, yes.

But all card errors would be async

Mostly you want to follow https://docs.stripe.com/error-handling

Which indicates how we recommend handling errors

[valid pilot]

is there a way to emulate this with test cards

with 4000000000000341 i always get a sychronos decline

[acoustic hazel]

Let's back up a second.

When you say synchronous and asynchronous are you actually talking about during the same session flow versus later async?

Or you talking about your code specifically?

I think you actually are referring to async payment mehtod types here?

Like Bank Debits?

[valid pilot]

i am currently referring to credit card payments only

(might later change)

so can a

payment.intent.create(confirm=true) go into processing
instead of succeeded or failed directly

[acoustic hazel]

No

It would never go into processing

It could go into a requires_action state if 3DS is requested

But it is not async like a bank debit that would move to processing

[valid pilot]

but i cannot setup a 3DS card for future use correct?

so this wont happen neither

[acoustic hazel]

Not sure what you mean by that?

[valid pilot]

we use a checkoutsession with mode: 'setup',
to obtain the payment method

[acoustic hazel]

When you collect the PaymentMethod you should set it up for future use via setup_future_usage (or via using a SetupIntent) if you intend to charge it again later when your customer is off-session.

[valid pilot]

so the paymentintent creatiojn happens off_session

[acoustic hazel]

Okay yeah that works to set it up for future use correctly.

But it is always still possible for the issuing bank to request 3DS

[valid pilot]

so when doing the payment.intent.create(confirm=true)
there wont be a 3ds possible

[acoustic hazel]

By using a SetupIntent here we essentailly request an exemption from 3DS from the issuer for future payments so that 3DS isn't required. However, it is still possible for the issuer to force 3DS in these cases

[valid pilot]

ok

but this would also be error case

[acoustic hazel]

So you should always be prepared to bring your customer back on-session to complete 3DS if necessary

[valid pilot]

as we cannot do anything directly

[acoustic hazel]

Yeah you will want a flow to communicate this to your customer if the PaymentIntent moves to requires_action

[valid pilot]

ok thx