brianc - checkout async payment | Stripe Developers | Page 1

compact dagger May 30, 2022, 7:05 PM

#

Hello! Just starting a thread for you -- I'll review and respond as soon as I can 🙂

#

Retrieving the payment intent is the right way to do this, yes, where you need details about the payment

#

You could alternately do that retrieval when the session is completed and write to the session metadata to have it included in the later async event payload, but thats the same request just earlier

#

(plus an update)

#

But no, there's no way I can see to learn that without retrieving the PI

prime breach May 30, 2022, 7:13 PM

#

OK. Thanks. How can we achieve what we need to do without having to make an additional call though? Which event should we be listening for that will tell us the delayed payment succeeded/failed

#

and what type of payment it was (ie us_bank_account). Is there no event that returns both?

#

"You could alternately do that retrieval when the session is completed and write to the session metadata to have it included in the later async event payload, but thats the same request just earlier" - is this the soluiotn? Add metadata to the initial call?

#

Looking at it now, I don't see how that would work. as the user chooses during checkout so we do not know. Am I understanding this correctly?

#

We just hate adding additional potential points of failure into code with these unnesssary call backs to the Stripe server. It seems like a pretty essential piece of info being omitted from the payload (payment succeeded but we're not going to tell you what the user chose as a payment method unless you ask 🙂 )

open mantle May 30, 2022, 7:28 PM

#

Um... the Stripe server, is, by definition, the "definitive source" for such information, so it doesn't seem unnecessary, nor a point of failure. From a different perspective, in many applications (such as mine) I really don't care what the customer used to pay - just that the funds are present...

prime breach May 30, 2022, 7:29 PM

#

open mantle Um... the Stripe server, is, by definition, the "definitive source" for such inf...

Thanks for the feedback

#

It's unnecessary to have to call the Strip server back when we could/should be able to recieve all pertinent info in one event

compact dagger May 30, 2022, 7:31 PM

#

prime breach OK. Thanks. How can we achieve what we need to do without having to make an ad...

There's isn't one place - you'll need to expand via request to do this regardless, since even the payment method would need to be expanded on the payment intent

#

Typically getting the indication the session succeeded (along with any custom metadata) is sufficient. If you have needs for specific information about the payment, it's available but you do need to retrieve it.

compact dagger May 30, 2022, 7:32 PM

#

prime breach Looking at it now, I don't see how that would work. as the user chooses during c...

Possibly, depends on how async the payment is here

prime breach May 30, 2022, 7:33 PM

#

OK. The custom metadata would not contain the payment method the customer chose as it happens via Stripe chekcout, correct?

#

So maybe not a solution?

compact dagger May 30, 2022, 7:33 PM

#

No, it would be things like internal order ids and such

prime breach May 30, 2022, 7:33 PM

#

Right.

compact dagger May 30, 2022, 7:33 PM

#

I'm not saying its a solution for your situation, no, just the more common one

prime breach May 30, 2022, 7:34 PM

#

Is there another event we could be litening for? payment_intent.succeeded maybe?

compact dagger May 30, 2022, 7:34 PM

#

Flipping this around, including all that data in all events when its mostly not needed would be overkill, so its available atomically

prime breach May 30, 2022, 7:34 PM

#

Woudl that do the trick?

compact dagger May 30, 2022, 7:35 PM

#

Yes, that's what i was referring to above, but even then you need to retrieve the PM as the PI only knows the PM id, not the type or any details, unless you expand it

prime breach May 30, 2022, 7:35 PM

#

Yes, I understand the reasoning. Just looking for the most efficient solutiuon for our situatopm

compact dagger May 30, 2022, 7:35 PM

#

Hmm actually you might be able to get the info from the PI event here:

#

https://stripe.com/docs/api/charges/object#charge_object-payment_method_details

Stripe API reference – The charge object – curl

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

#

Within the PI object, there is charges which should include the payment_method_details

#

Try examining that to see if it has what you need

#

But then you might need to set additional metadata on the PI when you create the checkout session, since you won't have any of the checkout session context in the PI event payload

prime breach May 30, 2022, 7:39 PM

#

I'm guessing if the payment_intent_succeeded event is part of the checkout.session.succeeded, we could listen for that event and look for the payment method type - essentially backing out of it and they would be more efficient as no additional calls to the Stripe server or our DB would be neccesary. I think that might be it.

compact dagger May 30, 2022, 7:41 PM

#

Give it a test and let me know 🙂

#

Hopefully everything you need is there

prime breach May 30, 2022, 7:41 PM

#

Will do. Thanks for your help in figuring this out

compact dagger May 30, 2022, 7:43 PM

#

NP!

prime breach May 30, 2022, 8:10 PM

#

OK. Sanity check here. In the checkout session object that is returned on the checkout.session.async_payment_succeeded event, there is a payment_method_options returned which in the docs says it is "Payment-method-specific configuration for the PaymentIntent or SetupIntent of this CheckoutSession."

#

Is this what we are looking for? Would this ever return more than one payment method specific item with this event? It not, it seems to be returning the information specific to what the customer has chosen. Is this correct?

compact dagger May 30, 2022, 8:15 PM

#

thats meant to show all the options you set up for that session, so i dont think it can be used to discover what you were seeking

prime breach May 30, 2022, 8:16 PM

#

OK. You're 100% sure? payment_method_types seems to do what you are describing

#

This is what is returning from a session where the user can choose either a card or ACH debit

#

""payment_method_options": { "us_bank_account": { "verification_method": "automatic" } }, "payment_method_types": [ "card", "us_bank_account" ],"

#

The key question here is "Would this ever return more than one payment method specific item with this event?". If so, when? what scenario would return multiple items in the payment_method_options hash?

compact dagger May 30, 2022, 8:23 PM

#

I'm not sure off the top of my head, but should be possible to test to see a counter example, let me give that a try

prime breach May 30, 2022, 8:23 PM

#

OK. Thanks

#

It seems to us that the checkout.session.async_payment_succeeded >> payment_method_options is identical to the payment_intent.succeeded >>data>>payment_method_details>>type

#

The only thing we need to know for sure if if there would ever be a scenario where the checkout.session.async_payment_succeeded >> payment_method_options would return multiple items in the hash.

#

If we can confirm this sceanrio would never happen (multiple items in theat returned value), we can use that data sent in the checkout.session.async_payment_succeeded event without having to make any additional calls back to the server or our db.

#

thus eliminating a whole lot of potential pain points. 🙂

compact dagger May 30, 2022, 8:42 PM

#

This is more difficult to confirm than i suspected, only because there are not many options supported there in the API, currently

#

So i suspect this may be a coincidence of the only options you configured

prime breach May 30, 2022, 8:43 PM

#

The descriptions in the API give us clues as well. Someone has to know what the difference is on your end I would suspect?

#

payment_method_types = "A list of the types of payment methods (e.g. card) this Checkout Session is allowed to accept."

#

payment_method_options = "Payment-method-specific configuration for the PaymentIntent or SetupIntent of this CheckoutSession"

#

can a PaymentIntent have more than one payment-method-specific configuration?

#

that is all we need to know

compact dagger May 30, 2022, 8:45 PM

#

OK, no, this doesn't work like you want/need, its all the options configured

#

Yes, it can

prime breach May 30, 2022, 8:45 PM

#

can you describe a scenario?

#

where that would happen?

compact dagger May 30, 2022, 8:46 PM

#

i can guide you to test this to see

#

you can take your checkout session and specify those us bank account payment method options

#

but allow both cards and us bank account

#

and pay with a test card

#

your event should still include the us bank account options

#

I tested this using another card+ other PM type but same logic applies

prime breach May 30, 2022, 8:47 PM

#

OK. Testing that now

compact dagger May 30, 2022, 8:47 PM

#

I stand by my recommendation to look at the actual payment details

prime breach May 30, 2022, 8:48 PM

#

But a card is not a delayed payment method

#

There would never be a delayed payment call when using a card

#

different scenario, correct?

#

We would never get a checkout.session.async_payment_succeeded if the user paid with a card. Please confirm this

compact dagger May 30, 2022, 8:52 PM

#

Sure, but that doesnt matter -- the checkout session object is the same

prime breach May 30, 2022, 8:52 PM

#

a checkout.session.async_payment_succeede would not be sent if they paid wth a card though

compact dagger May 30, 2022, 8:52 PM

#

You're making some contextual inferences that might be generally true but not strictly true

#

correct, i was merely testing whether the post-Checkout event behaviour of the payment_method_options was restricted to those options relevant to the payment method used. My test was a counter example showing that it is not.

prime breach May 30, 2022, 8:55 PM

#

compact dagger You're making some contextual inferences that might be generally true but not st...

Yes, I undrestand. Thanks. but we are onlu concerned with the checkout.session.async_payment_succeeded which would only be sent if there was a delayed payemnt method. this is striclty true, correct?

compact dagger May 30, 2022, 8:56 PM

#

Sure, but maybe you add other async payment method with payment_method_options in future

prime breach May 30, 2022, 8:56 PM

#

It's an important disctinction as alll we really need to surmise is a bool value of whether or not it is a delayed payment

compact dagger May 30, 2022, 8:56 PM

#

for your scenario, and the current API, what you say might coincidentally be true

#

but it is not a strict defined behaviour, so your assumption might later break

#

Does that make sense?

prime breach May 30, 2022, 8:57 PM

#

Not really. A card payment would never be a succceded session with delayed payment that I know of. Are you saying this is where it breaks down?

open mantle May 30, 2022, 8:59 PM

#

It's hard to define now how new payment systems may work. There may come to be a card that behaves asynchronously. You may choose to add another asynchronous payment method.

#

synthrider's point is that this assumption is a future-trap

prime breach May 30, 2022, 9:03 PM

#

But it would still be an asynchronous payment. which is fine. We just need to know T/F it it is a delayed payment first and then from the hash we find which one was used. Let's not theorize the future for now, but maybe a clear definitiion of the explanation "Payment-method-specific configuration for the PaymentIntent or SetupIntent of this CheckoutSession" - what exactly is a payment-method-specific configuration in this case if the payment_method_types is "A list of the types of payment methods (e.g. card) this Checkout Session is allowed to accept."

open mantle May 30, 2022, 9:05 PM

#

I would read that as "the payment methods, and the configurations supplied for them, as originally set on the Checkout Session"

prime breach May 30, 2022, 9:06 PM

#

Ah. OK. I see.

compact dagger May 30, 2022, 9:06 PM

#

Yes, that

open mantle May 30, 2022, 9:07 PM

#

I'm all for reducing "un-needed" calls, but I think you may be optimizing prematurely - a sure-fire way to code your way into a corner.

compact dagger May 30, 2022, 9:07 PM

#

lets say you were set up to use two async payment methods: us bank account and async_method_2 -- each with payment method options supported

#

I'd expect any checkout events (async payment or others) to include both (all) payment method option config hashes

prime breach May 30, 2022, 9:07 PM

#

That makes sense. So it does not mean the actual method chosen. It measn all methods that would have additional configuration attached to them (ie. additional details on the list of payment options for each method that hass additiona options)

open mantle May 30, 2022, 9:07 PM

#

I'd say get your overall system operational - since you won't likely START at-scale - and then look for optimizations where needed

prime breach May 30, 2022, 9:08 PM

#

We're in production and need to prepare quickly for scale. Thanks for the tip though.

#

No sense in adding overhead where we don't need it only to have to fix later.

#

As you can see we are very detail oriented and the Stripe docs (although great) are not always that clear

#

Thanks for your help

#brianc - checkout async payment