#nyxi_pi-autopms

1 messages ยท Page 1 of 1 (latest)

copper ruinBOT
placid trenchBOT
#

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.

copper ruinBOT
#

๐Ÿ‘‹ 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.

tiny rain
#

I received this as well, but my request includes payment_method_types and only card.

restive prawn
#

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?

tiny rain
#

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?

restive prawn
#

where does it fail exactly? Sorry you gave 2 request ids + a picture and not much details

tiny rain
#

It fails when I attempt to confirm the intent, as it wants me to provide return_url

restive prawn
#

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?

tiny rain
#

Yes, I'm working on upgrading API version

tiny rain
restive prawn
#

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

tiny rain
#

Roger, I will

restive prawn
#

nyxi_pi-autopms

tiny rain
#

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

restive prawn
#

Yep that makes sense

copper ruinBOT
tiny rain
#

Would you happen to know which error code I get if I try to cancel a payment intent that's already paid?

split walrus
#

HI ๐Ÿ‘‹

I'm stepping in as my colleague needs to go

tiny rain
#

No problem

split walrus
#

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.",
tiny rain
#

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)

split walrus
tiny rain
#

Okay, so that's a yes

split walrus
#

If you want longer response times but need the BT ID in the API response

tiny rain
#

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)

tiny rain
split walrus
#

That seems likely. We implemented this approach because most users don't really need the BT ID and prefer faster API responses

tiny rain
#

Of course, but wouldn't you consider this a breaking change?

#

non-nullable object now nullable

split walrus
#

Yup, which is why i t was listed on the API changelog, like all our other breaking changes.

tiny rain
split walrus
#

That I cannot say. I'm not necessarily certain which list you are looking at.

tiny rain
#

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

split walrus
#

Oh, the dashboard. Yes I agree with that. Honestly, I find that misleading as well. I'll file the feature request.

tiny rain
#

Okay, great

#

for context, here is the full dialogue

split walrus
#

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

tiny rain
#

Ok

#

when I capture a payment with the API, will balance transaction potentially be null then also?

split walrus
#

No, this is only a feature of automatic_async capture

tiny rain
#

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)

split walrus
#

That is my understanding, yes.

tiny rain
#

I think I got all the answers I need for now

#

Thanks for the help