#dave_paymentintent-currency
narrow cargoBOT
đ 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/1288208504040984709
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
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.
- dave_api, 4 days ago, 12 messages
- dave_dashboard-bug, 4 days ago, 8 messages
stoic vault
dave_paymentintent-currency
@ruby orbit you are explicitly passing payment_method_types and you pass sepa_debit yourself. That is not supported for currency: 'eur' so you get that error
This comes from your own code (or Bubble's code)
ruby orbit
I don't understand why a payment_method_type has to be passed when we're already passing the payment method id? I was trying to take the complexity out of the call by simple hardcoding the different methods into the api request. Is there not a way of automatically using the payment method type of the payment method id being used?
stoic vault
you don't have to pass one. You're the one who passed that parameter, it's not required and it would use our Dynamic Payment Method feature if you didn't https://docs.stripe.com/payments/payment-methods/dynamic-payment-methods
And the reason why something has to happen is because an attacker could create say a SEPA Debit PaymentMethod and give you the pm_123 id even though you only expect card payments for example. So you have to either be explicit with payment_method_types or use the Dynamic Payment Methods feature