#nova-card-cloning
oak aspen
cosmic pecan
@obtuse tundra what type of connected accounts are you using?
cosmic pecan
Okay, so really there's no notion of "cloning a customer" in any way. Really all you do is create a brand new Customer object on the connected account.
nova-card-cloning
obtuse tundra
So I have to use the API to clone their PAN, store a reference to that in a database somewhere, keep it up to date w/ changes they make to my platform account and then clone the payment method every time they make a purchase?
cosmic pecan
I mean that's one way yes. Sorry this is not super clear how you framed it as if it's a horribly bad approach. What's the problem?
obtuse tundra
Sorry, maybe explaining our goal will help. We want to provide our clients with the ability for users to store their payment info/personal info on our platform, and then create invoices on a connected account using that info.
We can do this with payment method cloning, but your invoice API requires a customer object. I am trying to figure out if I have to manually keep the multiple customer objects in sync, or if there is a better way.
A customer might interact with 300 shops over the span of their time on our platform. Keeping 300 account's worth of customer objects in sync with the main platform seems daunting, which is what im trying to avoid.
cosmic pecan
Gotcha, so yeah I would have Customer cus_ABC in the platform, and then when they pay my connected account I create a separate Customer cus_DEF on that account and I remember in my own database that they are related to each other
Not entirely sure what you need to "keep in sync" exactly in this situation other than the link betwen cus_ABC and cus_DEF in your own database
obtuse tundra
Customer email, billing details etc. Unless I am missing something crucial
cosmic pecan
You don't really need to keep them in sync right? You instead would update the Customer object when they are paying again to match what's in the platform no?
obtuse tundra
Gotcha. I was trying to avoid the RTT time on multiple back and forth calls, but if thats the only way i guess it has to work for us. I am pretty precious with our api rate limiting, so I try and avoid any unnecessary calls.
cosmic pecan
yeah that makes sense but unfortunately no way to minimize the calls in that flow if you use real Invoices from our Invoicing product
obtuse tundra
Gotcha. Might make sense at the end of the day to forgo your automated Invoicing emails (which is why we are using invoices in the first place) and just build a first party invoicing solution, and use charges in the backend.
Just to double check before I embark on a lengthy call w/ my client. I am perfectly okay to just create charges w.o a customer on connected accounts right?
cosmic pecan
that's one way, but ultimately cloning with Standard accounts should be fine really, lots of developers do this flow
and yes Customer is optional for normal one-time payments
obtuse tundra
Gotcha. One last quick question, how do I submit feedback to Stripe dev on this? I would have loved to use your on_behalf_of flow, if I could somehow get consent from an end user that they take responsibility for charges and refunds.
This would be an absolute godsend of an integration point for what we are trying to do, since on_behalf_of is far superior to direct charges.
cosmic pecan
that's just impossible with Direct Charges. The flow of funds are drastically different depending on the type of connected accounts because there's a completely different risk profile
obtuse tundra
Fair enough, I just thought that something like this (or the ability to share customers on the platform account via something like tokens) would take the stripe API from an 8/10 to a 9.5 for us instantly.
I wont take any more of your time though, so thank you for helping me out!