#nyxi_pi-autopms
1 messages ยท Page 1 of 1 (latest)
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.
- nyxi_invoice-return-url, 1 hour ago, 79 messages
๐ 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/1243246560762921010
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
I received this as well, but my request includes payment_method_types and only card.
I'm not entirely following your train of thought
allow_redirects: "never",
enabled: "false",
},
confirmation_method: "manual",```
like you can't pass both, and you passed both, hence the error right?
Correct, but if I don't provide automatic_payment_methods.allow_redirects = never, it fails to confirm the intent
because I have no redirect_uri
I also noticed I do payment_method_options.card, not payment_method_types => ['card'], so maybe that would help?
where does it fail exactly? Sorry you gave 2 request ids + a picture and not much details
It fails when I attempt to confirm the intent, as it wants me to provide return_url
If you want card only and manual confirmation you should be passing payment_method_types: ['card'] which you should always have done
If you weren't doing that and it now breaks, did you maybe upgrade your SDK or API version and not realize the impact?
Yes, I'm working on upgrading API version
I will add this and see if it works then
Gotcha so yes if you upgrade your API version it uses our new feature to calculate payment methods supported for you. So force payment_method_types: ['card'] on creation
Roger, I will
nyxi_pi-autopms
I'll get this to work on the latest API version first, then I'll migrate all of it to webhooks/async at some point
That was built back when payment intents didn't exist, so it's kind of wonky
Yep that makes sense
Would you happen to know which error code I get if I try to cancel a payment intent that's already paid?
HI ๐
I'm stepping in as my colleague needs to go
No problem
For the Q above, you'll get an error that looks like this:
error: {
code: "payment_intent_unexpected_state",
doc_url: "https://stripe.com/docs/error-codes/payment-intent-unexpected-state",
message: "You cannot cancel this PaymentIntent because it has a status of succeeded. Only a PaymentIntent with one of the following statuses may be canceled: requires_payment_method, requires_capture, requires_confirmation, requires_action, processing.",
Great
Thanks
Still working on confirming the other solution works, ran into some other problems on the way
If my balance_transaction (req_EnNFSeNpDClVJH) on my latest_charge is now null, does it mean I should set capture_method: automatic ?
(I did not see this change anywhere in the breaking changelog, so unsure how this broke on upgrade)
This is a consequence of automatic_async being the default capture method. https://docs.stripe.com/upgrades#2024-04-10
We detail how to handle that here: https://docs.stripe.com/payments/payment-intents/asynchronous-capture
Okay, so that's a yes
If you want longer response times but need the BT ID in the API response
I would say that's a signifiant enough change that it should be listed here (since it's a new default and not just an added option)
I assume I will have the same response time I had before upgrading?
That seems likely. We implemented this approach because most users don't really need the BT ID and prefer faster API responses
Of course, but wouldn't you consider this a breaking change?
non-nullable object now nullable
Yup, which is why i t was listed on the API changelog, like all our other breaking changes.
Fair enough, but what is the purpose of this list then?
That I cannot say. I'm not necessarily certain which list you are looking at.
It's the list of breaking changes that appear in the "upgrade api version" dialogue on the dash
I would say that it should either list all the breaking changes or none of them and only refer to the upgrade guide
Otherwise it's slightly misleading
Oh, the dashboard. Yes I agree with that. Honestly, I find that misleading as well. I'll file the feature request.
Yeah I loaded my own just to see what you meant. I'm going from 2020-08-27 to 2024-04-10 so I know there are plenty more breaking changes than they show
Ok
https://docs.stripe.com/payments/payment-intents/asynchronous-capture - on this page it's not explained what happens to the balance transaction etc. when i use manual capture
when I capture a payment with the API, will balance transaction potentially be null then also?
No, this is only a feature of automatic_async capture
ok thanks
but when I get charge.updated, balance_transaction is always defined, yes?
(regardless of capture method - assuming the charge was paid and captured)
That is my understanding, yes.