#Jim C (Galen)
wind lotus
pliant prairie
Hi there
Reading!
Gotcha. So basically this is just how cloning works. First off, you don't actually clone Customers. You clone the PaymentMethod itself. Mostly, if there is an update to your stored PaymentMethods at the platform level and you want to mirror that on the Connected Account, then you re-clone that PaymentMethod to the Connected Account and attach it to the Customer on the Connected Account.
hollow kayak
Hmm. I could not figure out how to use a cloned payment method without creating a cloned customer too.
Do I simply use its ID in the checking session / payment intent directly?
pliant prairie
What does "its" refer to?
hollow kayak
Sorry. The newly-created cloned payment method.
pliant prairie
Yeah you can if you don't want to save it.
Or you can attach to a Customer for later use
Or, you can save it when making payment by using setup_future_usage on the PaymentIntent
hollow kayak
I should clarify that I've got customers using setup intents before they are able to make payments.
So I have those payment methods already set up and ready (I assume) for payments in advance.
pliant prairie
Sure, at the platform level, correct?
hollow kayak
Correct
pliant prairie
Yep that's all good then
hollow kayak
So I need only clone the payment method for one-time use and use that directly in a checkout session?
pliant prairie
Yep that is a fine route to go
The only negative with that route (and not storing them on the Connected Account) is that you clone each time a new payment is made
But not a big deal overall
hollow kayak
I assume this is preferable to do each time. So that changing customer preferences are respected.
pliant prairie
And if you don't expect a lot of re-use on same Connected Account then definitely not a big deal
It certainly makes it much easier to just maintain PaymentMethods in your platform
hollow kayak
What are the downsides? Performance?
pliant prairie
And not have to sync to your Connected Accounts
Yep just performance
Which should only be slight
hollow kayak
Makes sense. And I've found in the test environment that performance is great overall. I assume production is even better.
Okay. So in creating checkout session, I have a PaymentIntentData parameter. It has a PaymentMethod sub-parameter. Just put the temporary payment method ID in there?
pliant prairie
Well performance will be slightly slower in production because we have to correspond with card networks and financial partners
hollow kayak
Makes sense.
pliant prairie
But yeah still should be quite fast
pliant prairie
Okay. So in creating checkout session, I have a PaymentIntentData parameter. It ...
No
You don't need to create a Checkout Session at all in this case
hollow kayak
Just a payment intent?
pliant prairie
You already have the PaymentMethod so you just create/confirm a PaymentIntent
Yep
hollow kayak
That makes sense.
pliant prairie
You pass the PaymentMethod ID here: https://stripe.com/docs/api/payment_intents/create#create_payment_intent-payment_method
hollow kayak
You know. It's funny. Every time I find something doesn't seem to make sense in the API, I find it's just because I am doing it wrong.
pliant prairie
🙂
hollow kayak
Our use case complicates things a little. We will do this two ways. One is when our long-term customers setup payment and we auto-charge them. The other is customers doing one-time payments and not persisting their methods. But that case is easier to understand. And that's where I would do the checkout session. And do so without an existing customer.
Although I might still create platform customers for them anyway. We have the info.
But then it's either directly create payment intent for auto-pay or checkout session when we don't have payment methods stored yet.
pliant prairie
Yeah overall that all makes sense
How are you collecting the PaymentMethods when storing them and not charging?
Are you using a Checkout Session in setup mode?