minaturecookie-customer

[weary idol]

we don't really mind, it's up to you how you use Customers. But yeah we kind of assume you have user authentication and you store the cus_xxx in your database so you can associate a (returning) user of your site to an existing Customer object.

We're currently creating a new Customer for every new payment flow, since we're creating a SetupIntent to charge later on.
how do you know the customer and PaymentMethod ID to charge 'later on' if you're not authenticating the user and storing IDs though? I don't understand.

[halcyon topaz]

We store the setup intent and customer id in the booking DB, so we can resolve the booking at a later date

But if the user makes another booking, we don't currently attempt to link them to any historical bookings that were potentially made by the same user

we don't really mind, it's up to you how you use Customers. But yeah we kind of assume you have user authentication and you store the cus_xxx in your database so you can associate a (returning) user of your site to an existing Customer object.

just to make sure I 100% understand you — you're saying that we're not leveraging the Stripe API to its fullest, but what we're doing isn't going to make Stripe block any of our API calls etc.?

[weary idol]

ah ok got it, makes sense

no we're not going to block your requests or something like that

you'll just have a lot of customer objects and it might make reporting/analysis a little difficult, but it's perfectly fine