#yandos666-cloning
1 messages · Page 1 of 1 (latest)
hi! please don't use the token or Charge APIs, they're deprecated. But that doc unfortunately is horrible and wasn't update to not use the legacy ones. You want the guide at https://stripe.com/docs/payments/payment-methods/connect#cloning-payment-methods for the middle steps instead.
To charge the customer on the connected account you must pass the customer ID and the cloned PaymentMethod ID to the PaymentIntent API, not just the customer ID.
\Stripe\Token::create won't work when the card you're cloning is a PaymentMethod pm_xxx which is the basic reason for the error you're getting. The solution is to not use \Stripe\Token::create, use \Stripe\PaymentMethod::create as in the PaymentMethod guide.
Thanks! so when it says "After you create a PaymentMethod and attach it to a Customer, "
does that mean the customer on our platform?
(from the link you sent)
does that mean the customer on our platform?
yep
you have Customer A on the platform with PaymentMethod B
you do that API call to clone
you now have PaymentMethod B2 on the connected account [that's the extent of the cloning]
you can charge B2 directly or attach it to a new Customer A2(that you might create) on the connected account
Cool - if you dont attach it to a customer on the connected account, whats shown in the connected accounts dashboard for that payment - does name/email etc flow through or are these just empty?
they'd be empty, only the details on the PaymentMethod itself are copied(number + billing details)
got it
any other context you might want you have to manually set by passing it when creating objects on the connected account like creating the new customer using details of the one on the platform
I generally encourage not trying to keep Customers in sync, a good approach is to have the 'master' customer on that platform and store all the context there, and just clone a payment method ad-hoc to a connected account to charge directly whenever needed
yeah i get that
otherwise you have to handle things like "customer is updating their saved card, I need to now clone it 50 times to each connected account to keep them in sync"
And finally(hopefully) - is there any considerations regarding storing the payment method for future use on the master customer and just keep cloning payment methods for each connected account?
a bit of an open ended question, but just any gotchas? can we by and large follow the docs for doing this?
only real gotcha is this only works for cards and I think SEPA debit
so if you rely on this it will be hard to expand to other payment methods as it's just impossible, you'd have to either create the local payment methods on the connected account directly, or use Destination charges with them instead
the other gotcha is integrating this way generally requires some custom code that we just don't document so it's hard. And in some integrations it's not well supported. For example you probably want to have your frontend use two instances of Stripe, one for creating the PaymentMethod on the platform, and another that confirms a PaymentIntent on a connected account. That works ok on the web but is hard/impossible on some of our mobile integrations that have a global Stripe account configuration.
sorry, I really wish we invested more in this feature and we push for it a lot internally but it's not as good as it could be
no worries, thanks for the honesty!
Sorry, having an issue with this, getting No such customer: 'cus_LtPyW5wBpy7qJk'
when attempting to charge - this is the customer on the platform account
i'm passing through the connected accounts ID via stripe_account
do you have a request ID req_xxx from the error message?
How do i find that out?
it's generally printed when using our PHP library I think if you dump the \Stripe\Exception , but otherwise https://support.stripe.com/questions/finding-the-id-for-an-api-request , it's returned in the Request-ID header in the response
thanks - so what's weird is that if i dont pass the customer ID and just the payment method ID to the paymentIntent::create it seems to work fine? I thought both where required for security reasons?
pi_3LBdSrQG4Egxrzvt1EKRuQZI
that payment method isn't attached to a customer though so it's fine
to go back to what I said :
you have Customer A on the platform with PaymentMethod B
you do that API call to clone
you now have PaymentMethod B2 on the connected account [that's the extent of the cloning]
you can charge B2 directly or attach it to a new Customer A2(that you might create) on the connected account
that last step is optional, You don't have to have a Customer A2 you can just charge B2 directly(as you do here)
Not sure I follow when you said its not connected to a customer, isn't it connected to the platform customer?
nope
it's an entirely new and separate PaymentMethod now, it's a new PaymentMethod object on the connected account, it has no connection to the one on the platform or the customer that the one on the platform is attached to.
doh sorry i get you, i was thinking it was the original PM but of course its the cloned version
is there any downside of just cloning the OG PM each time, i guess as its not really attached to anything theres no limit to how many i can make?
as the moment you do attach it to something you have the issue described earlier with updating if things change