#greggles_error
heady valveBOT
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.
- greggles_error, 5 hours ago, 7 messages
upbeat mulchBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1257447494665895976
📝 Have more to share? Add details, code, screenshots, videos, etc. below.
dull umbra
Hi there. Do you have a request ID I can review?
peak glen
Hi, sure, just a sec
req_KPJdH1EmjWkQQw - I'm sorry, I sent another request where I did not explicitly set the payment types. This request is for that error.
dull umbra
Ah, I see you're using the deferred intent flow
peak glen
req_KPJdH1EmjWkQQw
dull umbra
That's the same request ID you shared earlier?
peak glen
That is the request ID for the error where I explicitly set payment methods.
😦
One sec.
req_5l9xGp3UsqpZym
peak glen
Ah, I see you're using the deferred intent flow
Yes, that's correct
High level overview:
We're mounting the address and payment elements.
On submission we're creating an invoice for the item then finalizing the invoice and taking the client secret from that process to confirm the payment.
dull umbra
Okay
Let's see
Okay, the mismatch here is the payment_method_types on the Invoice don't match the types used in the PaymentElement
By default, we pull the Invoice payment methods from settings on your Dashboard: https://dashboard.stripe.com/test/settings/billing/invoice
peak glen
Hmm. Explicitly setting paymentMethodTypes when creating the payment element produces that error but omitting the paymentMethodTypes produces the first error (request ID) I posted.
And we're not explicitly creating a paymentIntent. The paymentIntent is being created as a result of the invoice being created and finalized. Are we missing a step?
dull umbra
I assume if you create the PaymentElement with paymentMethodTypes of card, cashapp, link, and us_bank_account, you don't receive this error?
peak glen
Untested, but probably not, however we'd like to expand the payment methods to capture more of our international clients.
peak glen
Are you saying I'm limited to only using paymentMethodTypes of card, cashapp, link, and us_bank_account?
upbeat mulchBOT
dull umbra
Are you saying I'm limited to only using paymentMethodTypes of card, cashapp, li...
Yes, at least for invoices. Your invoice settings in the Dashboard determine which payment methods are used for invoices. When you create the invoice, you should also receive a list of payment method types in the response from Stripe. What's happening here is there's a mismatch between the payment method types allowed for the invoice and what was used in the PaymentElement
It's a bit uncommon for folks to use Invoices for on-session payments like this. Is there a particular reason why you're not changing the order here: create the Invoice then use the Invoice's PaymentIntent's client secret to render the PaymentElement?
peak glen
It's mostly because of the options that are available during the checkout process that it seemed like the right thing to do. If we rendered the payment element as you say, will that open up the other payment methods?
I wasn't aware that deferring the paymentintent would hobble us like that.
dull umbra
If we rendered the payment element as you say, will that open up the other payment methods?
No, the PaymentElement will still only support/display the payment method types that are enabled for invoices in your Dashboard settings: https://dashboard.stripe.com/test/settings/billing/invoice
peak glen
Aside from being unconventional, are there other ramifications I need to know about the order I'm using to render the payment element?
dull umbra
That one's really it but it's a big one. If you render the PaymentElement without listing payment method types ("dynamic payment methods"), it's very likely that that list of payment method types won't match the enabled types for Invoices. You could initialize the PaymentElement with only the payment method types you allow for invoices but then that means you can never use dynamic payment methods with the PaymentElement
peak glen
So not specifying the payment types would automatically render payment types dynamically?
wraith owl
Hi there 👋 taking over, as my colleague needs to step away
wraith owl
So not specifying the payment types would automatically render payment types dyn...
Correct
peak glen
This fails on some payment methods when I use stripe.confirmPayment().
Error message
Payment details were collected through Stripe Elements using automatic payment methods and cannot be confirmed with a Payment Intent configured with payment_method_types.
It was for this reason I ended up specifying the payment types when rendering the payment element, per one of your representatives.
wraith owl
You have to omit the payment types from the Payment Intent too
peak glen
I'm not specifying them at all.
wraith owl
Do you have an example Payment Intent ID I can look at that produced that error message?
Or a request ID for that request?
peak glen
Sure, let me pull one up.
{
"id": "pi_3PXtEcGxG8m2870U0zz8lwgb",
"object": "payment_intent",
"amount": 10657,
"amount_details": {
"tip": {}
},
"automatic_payment_methods": null,
"canceled_at": null,
"cancellation_reason": null,
"capture_method": "automatic",
"client_secret": "pi_3PXtEcGxG8m2870U0zz8lwgb_secret_zDgOpzcjTuQheHhG3lpE6Z9Tk",
"confirmation_method": "automatic",
"created": 1719874930,
"currency": "usd",
"description": "Payment for Invoice",
"last_payment_error": null,
"livemode": false,
"next_action": null,
"payment_method": null,
"payment_method_configuration_details": null,
"payment_method_options": {
"us_bank_account": {
"verification_method": "automatic"
}
},
"payment_method_types": [
"card",
"cashapp",
"link",
"us_bank_account"
],
"processing": null,
"receipt_email": "greg.ulrich@me.com",
"setup_future_usage": null,
"shipping": null,
"source": null,
"status": "requires_payment_method"
}
Just ran another using 'automatic_payment_methods': {'enabled' : true}, in the creation of the payment element.
pi_3PXtNeGxG8m2870U1DsDaSr6
wraith owl
Ahhhh, okay. So you're using the Invoice to create the Payment Intent after the customer adds their payment method credentials to Payment Element. Does that sound correct?
peak glen
Yes it does.
wraith owl
Okay, I don't think that works, since the Invoice settings explicitly set the payment_method_types on the Payment Intent. I'd recommend switching to creating/finalizing the Invoice before rendering the Payment Element, that way you can pass its client secret in with the Payment Element and use whatever your Invoice's billing settings are.
The alternative would be to explicitly set the payment method types on every Invoice creation request and programmatically ensure that they match what was used in the Payment Element. This is prone to breakage obviously, since you have to check internally on your end if the payment method types match, then build a bunch of error handling so that your customers don't get to the Payment Element and just see an error.
peak glen
Oof, OK, I'll have to rearrange my checkout process and try again. Thanks for all your help.