#boat_api
1 messages ยท Page 1 of 1 (latest)
๐ 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/1329503456976961598
๐ 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.
- boat_api, 2 days ago, 5 messages
- boat_partial-authorization-webhooks, 3 days ago, 6 messages
In particular, I'm asking about non-transient failures. We'll have adequate retry capabilities in place
Hello ๐
The authorization should put a hold on the funds with the customer's issuing bank. However, if something happens with their account or the banking institution that might be an extremely rare case where you could have a failure to capture.
But that would be something like
- Place hold
- Bank fails
- Attempt to capture funds
Gotcha, and are there any test cards that we could use to test this sort of scenario? I'm looking at the cards to test declined payments here and I'm assuming the auth itself would fail for these: https://docs.stripe.com/testing#declined-payments
Correct. I don't think we have a test card for this because it is an extremely unlikely scenario
However, I can raise it as a feature request
Ok, that would certainly be a nice to have
Thanks for your help!
Oh one more thing
If we were to encounter this edge case, what kind of result should we expect in the system? Would we expect to receive a payment_intent.payment_failed event for this payment intent?
Or just a synchronous error response from the capture request with the payment intent remaining in an incomplete state?
Correct. However, you should also receive a synchronous 4xx response from the /capture API request
So perhaps you could write your testing scenario to spoof the 4xx response
Ok, great. Thanks! I think that's all I have for now!