#brianc-checkout
swift kayak
hi there! yes, Stripe would detect when to add/remove payment methods based on the type of transaction you're requesting.
hazy bough
OK. Thanks. Just to be sure. If at checkout using pre-built checkout, if the transaction requires "off_session" and/or "setup" mode Stripe would autom,aticaly hide any payment methods that do not suport this type of transaction. We are going to remove the specified payment method param but since it is mission critical we need to be 100% sure of the effect it will have on the transactsion.
swift kayak
for the direct charge, are you saving the payment methods used for off_session payments too?
hazy bough
It;s possible we might. why?
Where can we see some clear documentation on which payment methods support which transactions to connected accounts? We can't seem to find a clear answer
swift kayak
you should test first before making any changes.
is this what you're looking for? https://stripe.com/docs/payments/payment-methods/integration-options#payment-method-product-support
hazy bough
The link you sent doesn't seem to specify whether off_session or setup are suported when making charges on behalf of with a connected account. Am I missing something?
"1Checkout in setup mode requires that you pass payment method types." - this seems to say that Stripe would not detect and display payment methods as you described. None of that page seems to address connected accounts. Can you help clarify?
swift kayak
ah, yeah, I don't think we have any single page documentation for that. You can see it in each Payment Method documentation e.g. if you look at https://stripe.com/docs/payments/afterpay-clearpay/accept-a-payment, you can see
hazy bough
Either way, it's all very confusing to say the least and in many places seemingly contradictory. Why are we being promptyed to remove sending the payment types to "upgrade" our system when it looks like it would actually break it?
With all due respect, Stripe's code and documentation is becoming increasingly difficult to use/understand.
swift kayak
"1Checkout in setup mode requires that you pass payment method types." - this s...
my bad, you're correct, Checkout in setup mode does require that you pass in payment method types
was the recommendation provided when you wrote in?
hazy bough
Please don't worry about it. No problem. We just need to get this figured out. "If at checkout using pre-built checkout, if the transaction requires "off_session" and/or "setup" mode Stripe would autom,aticaly hide any payment methods that do not suport this type of transaction" I'm assuming the answer here is "no"
hazy bough
was the recommendation provided when you wrote in?
Recommendation is a prominent banner in our dashboard
swift kayak
hmmm, i'll pass on the feedback about that
hazy bough
I am going to assume at this point that NOT sending the payment methods and uysing the Automatic Payment Methods would actually break our code. Do you agree?
swift kayak
Without knowing the exact logic, i would say so yes, it would likely break your application.
for "setup" mode, you're going to need to explicitly pass in the list of payment methods
for "payment" mode, if you have a separate logic for it, it's possible to consider using automatic payment methods still.
but honestly, at this point, it just doesn't seem worth the effort if everything is working fine as it is
hazy bough
OK. Thanks. We don;t know if it's working fine as we are adding additional payment methods now. I think we are just going to research each payment method and (hopefully) it will act as expected in each scenario. You guys are doing great work but whoever is in charge of the product roadmap and documentation is making everyone's life more difficult 🙂
swift kayak
thanks, i'll pass on the feedback about our documentation
hazy bough
We're probably going to have more questions on the specific payment types and what the chart means. Should we continue this thread or start a new questions?
swift kayak
we can continue on this thread
hazy bough
According to the chart on this page. https://stripe.com/docs/payments/payment-methods/integration-options#additional-api-supportability. we have some specific questions
Ex: AliPay - It looks like AliPay does not support setup intents or future usage. If we sent AliPay as a payment method (we won't be using the Automatic Payment Methods feature) what happens? Is it just ignored and not displayed to the customer (silently fails) or will it cause an issue/disruption in checkout?
swift kayak
you can't, you'll get an error when attempting to create the Checkout Session e.g. payment_intent_data.setup_future_usage is unsupported for payment method alipay.
hazy bough
OK. Thanks.
The chart on this page does not specify any special conditions when using connected accounts. Does this mean the behavior/features do not change or are not affected when using connect accounts?
swift kayak
you're using direct charges right? Whether you can use the particular Payment Method would depend on the connected account e.g. which country it is based in, and currency of the payment
hazy bough
How so would it depend and where do we find that information? We are creating charges on behalf of using connected Standard accounts.
Also, is this something we need to implement and specify manually or would Stripe detect this and only display methods available to that connected account?
swift kayak
if you're using APMs, Stripe would display the payment methods that are available for the country of the connected account and currency. For example, a Standard connected account in AU and making payment using AUD wouldn't be able to pay using SEPA DD (because it's only for EUR)
hazy bough
OK. But back to the original question which is "The chart on this page does not specify any special conditions when using connected accounts. Does this mean the behavior/features do not change or are not affected when using connect accounts?" I'm assuming the answer is yes, there is no difference in behavior between charges made on master accounts or connect accounts.
As what you described would apply for all accounts
swift kayak
yes, there is no difference in behaviour being made between charges made on master accounts or connect accounts
hazy bough
OK. to be 100% clear "there is no difference in behaviour [of features/limitation provided in the chart] being made between charges made on master accounts or connect accounts"
swift kayak
OK. to be 100% clear "there is no difference in behaviour [of features/limitati...
yep, this is correct
hazy bough
If we send a payment method to a connected Standard account and the payment method is activated for the master account but is not on the Standard account, does is silently fail or does it disrupt the checkout flow?
swift kayak
sorry, i'm going to need to step away and my colleague will be here shortly to answer your question
hazy bough
Another question" We are getting contradictory info. The documentation states that if payment methods are not specified the default is "card". - https://stripe.com/docs/api/payment_intents/create#create_payment_intent-payment_method_types
It also says the when payment methods are not specified it defaults to "Automatic Payment Methods". https://stripe.com/docs/connect/automatic-payment-methods#integrate
Which is it and why do these two articles seemingly contradict each other?
compact orbit
the APM should be correct
This Doc will guide you based on fund flow and connect account type. I just chose Standard and Direct Charge for above link
hazy bough
OK. You guys need to remove the other documentation as it seems like it will not default to just "card" anymore. Just an FYI that could cause a real issue. 🙂
"If we send a payment method to a connected Standard account and the payment method is activated for the master account but is not on the Standard account, does is silently fail or does it disrupt the checkout flow?" Anything on this?
compact orbit
Yes thanks, agree we should improve the other Doc. About above question, I think you wouldn't be able to create the Checkout Session in the first place. By "send a payment method" do you mean passing in as parameter for "payment_method_types"?
hazy bough
Yes, payment method types. We cannot use Automatic Payment Methods as we need to specify each payment method due to our different requirements for payment (setup/off session/ direct payment/ onsessiopn). we are trying to create a scalable solution but need to know where any points of failure may happen. EX: we send a payment method in a list of methods and the master account supports it but the connected acount does not. Or if a payment method gets turned off in the dashboard but the software still sends it. It is potentially a big problem. We need clear documentation on the behavior (silently fails and contiunes checkout/fails with erroeo message displayed to user)
compact orbit
We cannot use Automatic Payment Methods as we need to specify each payment method due to our different requirements for payment (setup/off session/ direct payment/ onsessiopn)
I am keen on looking into detail about this reason. Your use case sounds like a perfect use for Automatic Payment Method, and it can be turned on for both Platform or Connected Account. What you need to do is just using it and let Stripe decide on the matrix of usable PM, then display properly in Checkout
hazy bough
It's not. It won't work for off_session/setup scenarios according to your doeucmnentation unless we are reading it wrong
see the footnote at the bottom of each chart. Are we not understanding ? It specifically says "1 Checkout in setup mode requires that you pass payment method types." Doesn;t this mean Automatic cannot be used?
compact orbit
I see. Yeah you were right. (I need to take a step back looking at this thread context, sry)
fmfm
hazy bough
You folks really need to know your software better before making recommendations that could have consequences to businesses. Sorry but this is the third time we've gotten bad instruction from you and your documentatioj is even wrong. Very tired at this point.
This is what we need answers to:
We cannot use Automatic Payment Methods as we need to specify each payment method due to our different requirements for payment (setup/off session/ direct payment/ onsessiopn). we are trying to create a scalable solution but need to know where any points of failure may happen. EX: we send a payment method in a list of methods and the master account supports it but the connected acount does not. Or if a payment method gets turned off in the dashboard but the software still sends it. It is potentially a big problem. We need clear documentation on the behavior (silently fails and contiunes checkout/fails with erroeo message displayed to user)
Can you provide that?
compact orbit
Sorry to hear that. I am looking for the documentation. I could try it but you rather want a clear statement on public Doc, is it correct?
hazy bough
We just need to know the answersm doesn't matter how/where. More than 2 hours on this thread so far and not much progress. Help in any way would be appreciated
Signing off. Thanks for your help
compact orbit
I was trying to reproduce it. It has been some quirk within my account. Will update here if I can sort it out.