#jack11sparrow
bright trout
I don't think you can create one of those for an existing customer. I believe you have to always start with a new Customer
pseudo canopy
with our flow we need the customer to exist in out database as well to proceed so how should i handle that situation
broken masonBOT
bright trout
You would create the Test Clock first, then the Customer. I don't think there's a way around that unfortunately
smoky prawn
Easiest hacky way would to just swap out the customer id in your database for one of the test clock customers
pseudo canopy
there is subscription_id, payment_intent linked as well
ivory quartz
You need to create the subscription for a customer which was created with a test clock
You can't retroactively add a test clock
pseudo canopy
but the subscription_id will not match right?
ivory quartz
Match what?
pseudo canopy
even if i replace the customer_id in my db the subscription id will not match
ivory quartz
I'm not sure what you mean, or what you need guidance on. I can't really speak to your app/db, but can answer questions about Stripe APIs/SDKs
smoky prawn
you would need to need to separate the customer creation from the subscription creation.
so, for instance, user signs up for your service, create customer in stripe and the record in your db. swap out the customer id in your db for one of the test clock customer ids, then continue with the subscription creation in your flow
if you're doing it all at once its not going to be as easy or possible afaik
pseudo canopy
@smoky prawn that i can do when i do create a subscription with that customerid will i be able to use that in test clock even if it is created in actual flow?
smoky prawn
for me I create the stripe customer when a user verifies their email address, and then when they sign in, they go through the "select a plan" flow which leads to subscription creation. so i'm able to do ^ what i described
pseudo canopy
its the same for me
smoky prawn
yea as long as you're using a customer id that was created in the test clock, the subscription will also be affected by the clock even if you create it via the api/client libraries
pseudo canopy
nice, thanks let me try that
ivory quartz
I don't really understand what you're describing about using test clocks when considering real customers, but its accurate that the customer determines whether a test clock is used or not.
smoky prawn
I think they just meant "real user" as in a user being created from their code/existing in their db (their test enviornment) vs. manually creating one via the test clock web interface.
But as long as they can create a user (in their code/system) and then swap out the customer id in their test database with one of the test clock customer ids prior to them creating a subscription (from their code), it should work fine.