#culture7410
1 messages · Page 1 of 1 (latest)
If you remove payment_method_types from the Subscription creation request, it'll use automatic payment methods
The thing is that I don't use payment_method_types when creating my subscription, but when I analyze the Subscription object that is created automatic is null and payment_method_types is not null and contains card
Can you share an example subscription ID (sub_xxx), so that I can take a look how your integration works?
Hm I'm not sure what you need, you want the full object json?
I just need the Subscription ID (sub_xxx), not the full object
In https://dashboard.stripe.com/test/logs/req_JZyLc6H6umnhzr, I saw 3 payment methods returned in the respond:
payment_method_types: [
"card",
"paypal",
"sepa_debit",
]
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
What are the payment methods you expect to see?
These ones:
and these ones as well:
The documentation says that automatic_payment_methods is on by default, but for some reasons that's not the case for me
The thing is my payment element uses automatic_payment_methods, so when I get the payment intent ClientSecret there is a conflict because the payment intent uses payment_method_types instead
Not all payment methods support subscription or the currency
Which specific payment method do you expect to see in your subscription, so that I can check the limitations for you?
I'd like Paypal, WeChat and Alipay at least, the other are secondary
PayPal is returned in the subscription. WeChat Pay and Alipay doesn't support subscription
You can check the product support of each payment method here: https://stripe.com/docs/payments/payment-methods/integration-options#product-support
Ok I get it
But for example when I try using a card (which is supported for subscription), the payment fails because of the conflict between my payment element and the payment intent
Here is the error message I get when doing elements.confirmPayment on the client:
The provided setup_future_usage (off_session) does not match the expected setup_future_usage (null). Try confirming with a Payment Intent that is configured to use the same parameters as Stripe Elements.
What is the error you're facing? Can you share the request ID (req_xxx) with the error? Here’s how you can find it: https://support.stripe.com/questions/finding-the-id-for-an-api-request
Find help and support for Stripe. Our support site provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.
In any case, your above request was confirmed in the deferred intent flow. Can you share your client code on how you create the Elements and Payment Elements?
Well I am now facing this problem, the previous one (the conflict with automatic payment methods) doesn't seem to happen anymore
Thanks for sharing! You shouldn't need deferred intent flow in such a case, i.e. setting up mode, currency and amount in the elements options: https://stripe.com/docs/billing/subscriptions/build-subscriptions?ui=elements#add-the-payment-element-to-your-page
Only client secret is needed
I create the client secret only after, when the client click on "Pay"
Pay button calls the server (which create the subscription and send back the client secret), then the pay function proceed with confirmPayment
I've been working with the Card elements for the past months, it was working well like this. But now I'm trying to migrate to payment element
hi! I'm taking over this thread.
Hey!
So your colleague answered my question for subscription (not all payment methods are supported for recurring fees), but I still got the same problem for a one time payment:
- my payment element use
automatic_payment_methodsby default (that's what I want) - my invoice is created with
payment_method_typesby default, which creates a conflict with the payment element. And I can't find how to change this default behavior in my code
Invoice created on the server: in_1OcOznGSweb1VpkGI95OyFyz
Conflict with the payment element:
req_Xsru4dLXEinUWk
you could try and pass https://stripe.com/docs/js/elements_object/create_without_intent#stripe_elements_no_intent-options-setupFutureUsage as off_session (the PaymentIntent created by the first Invoice on a Subscription will have setup_future_usage:off_session), but to be honest I'm not sure we even support this flow(the 'create Elements without Intent'(deferred) flow + Subscriptions)
That's ok for the subscription I got it to work with the help of your colleague. And this flow worked for me in production with the card element
ok I see now it's about a one-time Invoice
Yes
as far as I know this just doesn't work, because of the exact issue you're facing, we haven't made it work yet.
Billing/Subscription/Invoices don't actually use that whole automatic payment methods system, they use their own parallel settings controlled in https://dashboard.stripe.com/settings/billing/invoice and the problem you're facing is due to that incompatibility
Alright, it was driving me crazy ahah
So a workaround would be to specify payment_method_types in my payment element with the full list of the types I want?
having said that I think you can pass https://stripe.com/docs/js/elements_object/create_without_intent#stripe_elements_no_intent-options-paymentMethodTypes
I think so
Ok I'll try it that way