DubbaThony

[undone rampart]

you should use https://stripe.com/docs/payments/payment-methods/connect#cloning-payment-methods

cloning with the token approach won't work and gives you that error about no payment sources because that's a legacy approach that only looks at legacy objects and you have customers with current PaymentMethods pm_xxx

the docs are unfortunately a mess

If we clone payment method *from connected account *after payment to platform account
that's impossible.

What you do is you store the customer and payment methods on the platform, and then clone them to connected accounts when needed

[sullen cape]

Yeah I've been running in circles for 2 days with this problem

Okay I will try this

Is there any pre-made frontend (like for checkout session) to handle adding payment method (also so we don't need to deal with card numbers etc)?

[undone rampart]

well you can use Checkout in setup mode

but if you're going to be cloning you'll really need to build your own UI I would say as it's a more complex integration

so I would be using https://stripe.com/docs/payments/save-and-reuse?platform=web with Elements

[sullen cape]

That's at the second way beyond our scope unfortunately to build UI for cards etc, so the checkout in setup mode sounds like way to go. Can I create the setup mode checkout without actual payment going on than?

[undone rampart]

ultimately Checkout is not designed for charging a customer's saved card, it almost always is just a UI for collecting a new payment. So if your use case involves presenting and charging saved cards, that's mostly something you have to build your own UI unfortunately

[undone rampart]

I mean to be clear there's no PCI scope difference if that's what you think

the difference is that Elements is hosted on your own page as inputs rather than a redirect to a hosted payment page

. Can I create the setup mode checkout without actual payment going on than?
yes ; https://stripe.com/docs/payments/save-and-reuse?platform=checkout

[sullen cape]

Great

[sullen cape]

Well, when handling such sensitive data as credit cards some extreme care would need to be taken and we prefer to offload that care to stripe

[undone rampart]

in your use case I don't think I would use Checkout though since you can't really use it for charging the saved cards later. For charging the card later, generally you would call https://stripe.com/docs/api/payment_methods/customer_list on your backend server and return any information you need to render your frontend UI such as the brand/last4 of the card etc to put into a table, back to the frontend. Then when an option is picked you can call https://stripe.com/docs/js/payment_intents/confirm_card_payment#stripe_confirm_card_payment-existing to charge it

[undone rampart]

yeah but it's the same if you use Elements or Checkout, in neither case do you touch any cards yourself, it's all tokenized, just want to make that clear

[sullen cape]

So FE talks directly to stripe?

Like that way?

[undone rampart]

yes

the inputs from Elements are an iframe and interact directly with Stripe, your code doesn't touch the actual input

[sullen cape]

Okay that could work for us, I will need to talk to team about it.

Thanks @undone rampart. I appriciate.

If we will have more questions can I come back to this thread later down the line?

[undone rampart]

we close the thread after ~30 minutes, but you can always ask in the main channel and someone will be around!