#casey_api

1 messages · Page 1 of 1 (latest)

narrow foxBOT
#

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

📝 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.

low flare
#

Hello, yes we made asynchronous capture the default capture method. Basically, before we defaulted to automatic capture, which meant that your confirm call would be waiting for the funds to be both held and captured. With async capture, the API call returns as soon as the funds are held and we capture the funds asynchronously after that. This means that API calls for capturing payments return faster, but the side effect is that the balance transaction isn't part of the initial charge object because BTs aren't created until the funds are captured.
https://docs.stripe.com/payments/payment-intents/asynchronous-capture
You have two options here:

  1. Specify capture_method=automatic when creating your payment intent to go back to the old behavior
  2. You can change your webhook logic to wait for the events where the balance transaction is added https://docs.stripe.com/payments/payment-intents/asynchronous-capture#listen-webhooks
glass tartan
#

@low flare perfect, that's super-helpful and exactly the context I needed. Thank you so much!

#

One quick follow-up.

#

Am I right to assume that setup_future_usage = off_session doesn't impact that? ie, we could take either approach you outlined, regardless of future usage?

low flare
#

Correct, that is an separate concept from capture_method. setup_future_usage tells us how to optimize the card for payments that you create later, capture_method is about what we do right now with this specific payment

glass tartan
#

Right, yep—that makes sense. Thanks again for your help, really appreciate it!

low flare
#

Of course, glad I could clarify! Also apologies for the delay on that last response, the server got busy and I lost track of some threads

glass tartan
#

No worries at all!