#eugene-bakhmetiev_api

1 messages ¡ Page 1 of 1 (latest)

ornate surgeBOT
#

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

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

velvet hare
#

to clarify -- we only finalize the invoice and generate payment intent at the very end, when all of the purchase parameters are confirmed by the user

foggy igloo
#

Sounds like the deferred flow? Like you init the Payment Element before creating the subscription?

velvet hare
#

yes

foggy igloo
velvet hare
#

for a bit of additional context -- we had a situation recently where our supported payment methods in our Stripe configuration (Cash App updated it's rules, and our business is not supported anymore), which caused the supported payment methods on the subscription, that were generated automatically, to change, which caused a mismatch between frontend and backend. So if we set the allowed payment methods on subscription in the code, and Stripe settings change again, we will need to update our code and redeploy, which is what we're trying to avoid / minimize. Can we set "automatic_payment_methods" on the subscription somehow?

foggy igloo
#

No, it'll just use auto PM if the parameter above is null/unset

velvet hare
#

so basically if we are using subscription AND need to initialize payment form before invoice is finalized, we have to always set the allowed payment methods list explicitly?

foggy igloo
#

No, you can just omit paymentMethodTypes and then it'll dyanmically show the available PMs

#

Then you'd do the samew when you create the sub via the API

velvet hare
#

we tried that, and when I tried to confirm the payment using FE form, I got "Payment details were collected through Stripe Elements using automatic payment methods and cannot be confirmed through the API configured with payment_method_types" error

foggy igloo
#

Can you share an example where you saw that error? The sub_xxx or pi_xxx? Something doesn't add up

velvet hare
#

this was a long time ago, when we were just setting up the subscription flow, so I don't think I can find that now, unfortunately. I'm assuming this happens because PI created from invoice from a subscription has "automatic_payment_methods": null and explicitly set "allowed_source_types": [...], but maybe I'm wrong

#

I can adjust the code on our side and try to get you a PI record with this error a bit later today

foggy igloo
#

Sure, that would help

velvet hare
#

okay, I'll post here when I have it. Thanks for your help!

velvet hare
#

can you take a look at pi_3RWzPmJaf89hC41I14xlacXh ? It's created in test mode

foggy igloo
#

I suspect you're passing mode: 'payment' there, looking at this confirmation request

#

That should be mode: 'subscription'

velvet hare
#

yes, you're right, we're using mode: 'payment' there. I will look into mode: 'subscription', thank you!

foggy igloo
#

Yeah if you're using payment it'll look at a different payment method config which doesn't match the one used to create the sub

#

So the error message is inaccurate really, but I suspect that's the issue

velvet hare
#

oh, I see. I saw the Default and Billing payment methods configurations in Stripe dashboard, are you talking about those?

foggy igloo
#

Yep!

#

mode: 'payment' -> Default
mode: 'subscription' -> Billing

velvet hare
#

okay, got it. Thank you so much and have a nice day!