#usmseong_29857
rugged fogBOT
Hello! We'll be with you shortly. 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.
- usmseong_29857, 30 minutes ago, 14 messages
- usmseong_29857, 1 hour ago, 7 messages
- usmseong_29857, 3 hours ago, 13 messages
- usmseong_29857, 16 hours ago, 4 messages
- usmseong_29857, 18 hours ago, 5 messages
- usmseong_29857, 20 hours ago, 11 messages
and 3 more
valid wing
not related to my previous question
bleak estuary
Hi, can you share the request id where you see this error? Here's how you can find a request ID: https://support.stripe.com/questions/finding-the-id-for-an-api-request
valid wing
yup plz give me some time
bleak estuary
Sure!
bleak estuary
Taking a look
From looking at this request, it looks like you're using the Deferred Payment Intent. That error happens when using our deferred intents flow, if you use mismatched approaches for determining what payment method types should be offered to the customer.
Right now it sounds like you used dynamic payment methods (previously automatic payment methods) when initializing your frontend, but then created the Payment Intent in your backend explicitly passing payment_method_types instead.
You'll need to adjust your flow so that your frontend and backend use the same approach.
In this case, you can update your server side code to use dynamic payment methods: https://stripe.com/docs/api/payment_intents/create#create_payment_intent-automatic_payment_methods
valid wing
i'm so sorry but I'm not sure what you mean by these.. could you please elaborate ?
bleak estuary
Sure, it looks like you're collecting payment details, and the creating the payment intent using this flow: https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web. When you initiate the Payment Element, you're using dynamic payment methods, https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=payment#add-the-payment-element-to-your-checkout-page. So when you create the Payment Intent on the server side, you'd want to match that by using https://stripe.com/docs/api/payment_intents/create#create_payment_intent-automatic_payment_methods on the creation request.
rugged fogBOT
bleak estuary
Sure!
valid wing
i talked to a BE developer to add that on his end but he said "automatic payment methods only enables the payment methods specified on stripe to show automatically on the element. Don't know how thats going to help with off session stuff"
what do you think?
calm spoke
👋 stepping in here as pgskc needed to step away
Yeah I'm not sure what you backend developer means exactly by that. This doesn't have to do with "off session stuff" at all... the PaymentIntent was created using payment_method_types explicitly (see: https://dashboard.stripe.com/test/logs/req_IqPmbfYuHTrjRz) so you either need to match that on the frontend (by setting paymentMethodTypes -- see: https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=payment#additional-options) or you remove payment_method_types from the backend and use automatic payment methods as recommended above.
valid wing
ah i see. could you please not archive this chat for like 20 minutes? we'll have to try this
calm spoke
Sure
valid wing
I'm running into other issue that prevents me from testing this. in the meantime I have 2 other questions
-
If we switch to using payment elements instead of using the Stripe API, will our existing users be able to use their stored payment methods without any hiccup?
-
Currently, we have promo code that can be applied at checkout, does stripe elements have a promo code functionality? Will we need to create promo codes in stripe? If so, what kind of limitations can we add to these promo codes?
calm spoke
If we switch to using payment elements instead of using the Stripe API, will our existing users be able to use their stored payment methods without any hiccup?
You are already using Payment Element so I don't really understand the question.... but yes you can store PaymentMethods for future use.
Currently, we have promo code that can be applied at checkout, does stripe elements have a promo code functionality? Will we need to create promo codes in stripe? If so, what kind of limitations can we add to these promo codes?
No Elements doesn't work with promo codes for one-off payments (only Subscriptions/Invoices) so you would handle this from your end and just update the PaymentIntent (and frontend) amounts based on the promo codes that you would track in your own database.
valid wing
thank you for the response. I got this response from a BE developer regarding the issue I shared initially.
"it makes sense to specify the payment method types in the FE because there are some we shouldnt use"
I'm a FE dev and How do I specifiy the payment method types in FE?
valid wing
thank you. what could be the possible values for paymentMethodTypes?
also another question - is there a way to listen whether a user selected Google Pay from Stripe form (PaymentElement) from outside so I can hide other UI based on what the user has selected?
calm spoke
Really you should just use automatic payment methods
You can control which ones show from your Dashboard
Much simpler and more effective. We don't return you a list of payment method types from the API or anything so if you want to set them explicitly then you need to hardcode
is there a way to listen whether a user selected Google Pay from Stripe form (PaymentElement) from outside so I can hide other UI based on what the user has selected?
Yeah you want the "change" event: https://stripe.com/docs/js/element/events/on_change?type=paymentElement
The value will tell you the selected type
valid wing
is there a react js way for this event?
valid wing
awesome it works like a charm thank you 🙏