#BrianC-automatic-payment-methods
next stump
Hello!
Those two links are for two different integrations - for payment element you need to add a bit of extra code to enable it, while for checkout you can just remove payment_method_types.
wild crane
the api doc says if we remove the payment method lists it will default to 'card' - pre-built checkout
next stump
Can you point to where in our docs it says that? I'm looking at https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-payment_method_types and I'm seeing it match what I mentioned (that you shouldn't include it if you want to use automatic payment methods)
wild crane
CAn't find it now so it may have been an older page. This is what we have in our dev logs though. As long as we can confirm that this will NOT be the behavior for pre-built checkout we should be fine. Is it possible this was the old behavior for previous versions though?
We also need to confirm that Automatic Payment Methods will NOT work for off_session or setup mode transactions. For this we need to specify payment methods using the dictionary list, correct?
next stump
We did default to card in the past, but that was before automatic payment method was added - it isn't tied to any specific API version.
What specifically do you mean by off_session transactions? How would you want to be using automatic payment methods in this context?
wild crane
What specifically do you mean by off_session transactions? How would you want to...
here is the link we are referring to. https://stripe.com/docs/api/payment_intents/create#create_payment_intent-payment_method_types
wild crane
What specifically do you mean by off_session transactions? How would you want to...
for an off_session (future usage) payment where the customers card information is collected in setup mode for a charge ata a later date.
next stump
Automatic payment methods should still work with off_session payment intents
As well as with setup intents
wild crane
are you 100% sure? The docs (which are somewhat confusing) seem to say otherwise. It's super important that we know this behavior
It would be great if it did BTW
next stump
What part of the docs say otherwise? I'm not seeing anything that says this won't work with off_session payments?
wild crane
footnote under the first chart - easily overlooked I agree
It seems to say that the system requires a specific dictionary object of methods for intents (which would mean off session payments)
Can you clarify?
next stump
Are you specifically talking about this quote? "2 Cards and bank debit methods including SEPA debit, AU BECS direct debit, and ACSS debit support both on_session and off_session with setup future usage. All other payment method types either don’t support setup_future_usage or only support off_session."
Ohhh I see - do you mean this one? "1 Checkout in setup mode requires that you pass payment method types."
next stump
Interesting! I wasn't actually aware of this restriction, but yes, from a quick test it does look like Checkout in setup mode requires payment_method_types to be set
wild crane
this needs to be much more prominent in the docs. APM seems like it could really mess things up if it is not a straight direct charge or behalf of charge. This is what we are trying to suss out and avoid.
We will avoid APM for anything that could vary from straight vanilla direct charges. Just needed to confirm.
Another question we have is about errors if a payment method list is sent (ex: off_session) and someone turns off one of the payment method in the dashboard (accidentally or purposely) which is still sent to the Stripe servers from our code. Will this fail silently or will it derail the transaction?
next stump
Just to clarify - you're asking what would happen if you created a Payment Intent that specified payment_method_types and included (as an example) ach debit. You're asking what would happen if you turned off ACH debit in the dashboard, and then tried to complete the payment with ach debit?
wild crane
Not exactly. If we sent a list of payment methods while creating an off_session payment setup for charging at a later date, and one of the items in the list we sent was now deactivated in the dashboard. What happens?
next stump
So at the point that you're creating the list of payment method types, one of them is disabled in the dashboard?
wild crane
Ah! Actually yes! Sorry.
In essence there is a discrepency between what is sent from our code and what is activated in the dashboard. An unavoidable possiblity of point of failure if they get out of sync.
Will it fail silently or abort the checkout flow? (if there is at least one payment method in the list sent from our server activated in the dashboard)
sharp pawn
If you specify payment methods and include one that is not activated, you should encounter API errors that indicate this
eg:
{
"error": {
"message": "The payment method type provided: boleto is invalid. Please ensure the provided type is activated in your dashboard (https://dashboard.stripe.com/account/payments/settings) and your account is enabled for any preview features that you are trying to use. See https://stripe.com/docs/payments/payment-methods/integration-options for supported payment method, currency, and country combinations.",
"param": "payment_method_types",
"type": "invalid_request_error"
}
}
What will happen (UI user experience) using the pre-built checkout? We are more concerned about losing sales
sharp pawn
You wont be able to create the session to get that far
that error will happen when you call the session create api
wild crane
So our implementation will break if that happens?
wild crane
Yes, of course. I guess we were hoping that Stripe would be able to handle the call and fail silently since there were other payment methods in the list that would be an option. Puts us in a tough spot
if a single payment metjhod in a list of valid ones is not activated
sharp pawn
Why would you specify one you have not activated?
wild crane
Other way around. Code is sending a list of activated but one gets shut off accidentally or purposely in the dashboard, or a situation where the payment method is shut off by tht provider for some reason. At scale with connected accounts would break all checkout transactions across all accounts. Correct?
in your error message example you sent did you send jsut one invalid method or a mix of valid and invalid methods?
sharp pawn
a mix, card and boleto specifically
If this is a flow you want to account for, then you should catch & handle errors on creating sessions. Looking for param: payment_method_types as above and parse the invalid one(s) to remove if you wanted to retry without them
wild crane
OK. Poor handlking of it though IMHO
SPF at mission critical transaction should be handled better on Stripe's end.
escpecially when using pre-built checkout
It would make sense if there were no valid payment methods sent but one in a list of many. not cool
shouldn't break
sharp pawn
But that would mean silently failing to to what you ask -- which would also cause issue
eg, if you expected to offer SEPA payments but this was left off
wild crane
why? disreagrd the bad method and display the others to the user
no so hard
I'm talking user/customer experience and getting a transactiuon through
sharp pawn
Perhaps for your use case, but that might break others. Instead of silently failing to display a payment method, we tell you it can't be used
wild crane
how break others?
sharp pawn
Not showing iDEAL, for example, might be effectively breaking for a customer in Netherlands
wild crane
just ignore the bad one
better than losing a sale
show them a card option
makes no sense otherwise when trying to capture a sale
sharp pawn
If that's your preferred flow, then you can do this given our error response
if you get an error back, reduce your listed types to just card and call the session create again
wild crane
Poor handling on Stripe;s end. No way around it for a business transaction.
we're talking at scale here
sharp pawn
I'm not sure what the challenge is here if that's the flow you expect, its possible to handle and get exactly what you want.
I appreciate the feedback but I don't see this changing. Explicit errors are preferred over silent ones that change behaviour (showing a payment method type or not).
wild crane
ok. we can agree ti disagree "Explicit errors are preferred over silent ones" not in exchange for a failed monetary transaction. Should be a webhook notification of the error but should most definitely not abort the chckout if there are other valid methods sent. Not from our POV as a business.
addint parsing and retries is not great at scale. unnessary
sharp pawn
ok. we can agree ti disagree "Explicit errors are preferred over silent ones" no...
Yep, agree this is an opinionated implementation. We choose to respond with an error immediately and let you handle what to do with that information.