#frederic_api

1 messages · Page 1 of 1 (latest)

rapid patrolBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1256262263069741096

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

void relicBOT
bleak ridge
#

Hi 👋 yes, the Balance Transaction is the best place to see this. Can you share the ID of an example Charge or Payment Intent from your testing where a Balance Transaction ID wasn't provided?

pale shuttle
#

This one for example:
id: 'pi_3PWfi1FNm9Dqdsn80hp0QWvQ',

#

For information, I used to have the same approach, not in a webhook but in the server side part of the return page, and it used to work.
Therefore, my assumption is that is must be a timing problem: the balance transaction may not have already completed.
If my assumption is correct, it would mean this approach is a no go and it must be approached differently...

bleak ridge
#

I believe this is happening because your request to create that Checkout Session is using a very new API version, where the default capture method is now automatic_async.
https://dashboard.stripe.com/test/logs/req_OmQ6FiINaknolJ

With that capture method, we perform the capture asynchronously, so we can respond to your requests faster. One risk with that is that downstream objects may not be generated before you go looking for them. We talk about it in a bit more detail here:
https://docs.stripe.com/payments/payment-intents/asynchronous-capture

You'll either want to add error handling to determine when a downstream object is missing and wait for it, change the Events you listen for, or consider passing payment_intent_data.capture_method to automatic when creating the Checkout Session to avoid the asynchronous behavior.
https://docs.stripe.com/api/checkout/sessions/create#create_checkout_session-payment_intent_data-capture_method

pale shuttle
#

Ok, that's quite a lot to process.
I propose to read and digest all this, make some tests and possibly come back if that does not work.

That's my first time here. How do we process.
If I have any follow up questions, should I open a new thread ?
Can I possibly, come back in this thread once I have done my homework ?

bleak ridge
#

If the thread sits idle for 15-25 minutes, it will likely be closed to keep the thread count manageable. If you have additional questions, or follow ups to this one, and the thread is still open, then you're welcome to ask those here. If the thread is closed, then you'll want to ask another question to start a new thread.

pale shuttle
#

Is this alternative approach possible ?
For the context, we are storing purchases in our database. We want both the paid currency and the settlement currency. That's wny I need this information. The Stripe Id we store is ch_xxxxxxx.

Is there a scenario where I could listen for balance_transaction webhook and from there, know the associated ch_xxxxxx so that we can update purchase information in our database ?

bleak ridge
#

No, there aren't Events that you can listen to that will include a Balance Transaction object for you to work off of. Our full list of Event types is shown here:
https://docs.stripe.com/api/events/types

Looking at the guidance in step 2 of the doc I linked about asynchronous capture, charge.updated is the best Event type to listen for. That will be emitted whenever a Charge object is updated, which should include when the Balance Transaction ID is placed within the Charge object.

pale shuttle
#

ok, then. I assume I have two choices here:
either:

  • go ahead with the async route path which is a bit more complex but would work for any type of payments (especially deferred ones)
  • or set the capture_method to automatic to make my life easier (but would need to be upgraded for some type of payments)

Thanks, for the help; I will process this information and make some tests.

PS: do I still have access to this thread even if it's closed or do I need to copy the information you provided ?

bleak ridge
#

The thread's history will remain available, and this link should bring you right to it:
https://discord.com/channels/841573134531821608/1256262263069741096
(thread links can be gotten by right-clicking on the thread in the left-side pane, and selecting copy link)

I'm going to double check the use automatic_async vs automatic impacting the type of payment methods you can accept. Offhand I don't think that's correct, but I may be misremembering something.

#

Yeah, as far as I'm aware, using automatic doesn't impact the payment method types that you can accept. Instead it may increase response time to the requests made to our API as your customer completes the checkout experience.

automatic_async on the other hand should reduce latency a bit, but comes with a bit of additional complexity as objects may not be created as soon as they are with automatic.

rapid patrolBOT
pale shuttle
bleak ridge
#

Nope, two different concepts

pale shuttle
#

The documentation is really not completely clear on that.

This step is only required if you plan to use any of the following payment methods: Bacs Direct Debit, Bank transfers, Boleto, Canadian pre-authorized debits, Konbini, OXXO, Pay by Bank, SEPA Direct Debit, SOFORT, or ACH Direct Debit.

Can I assume that it does not hurt to implement this approach even if we don't use these payment methods for now?

frozen tinsel
#

Correct