#primalfreeze_best-practices
ornate fiberBOT
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
đ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1399621879010033766
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
lime sonnet
Hi there, can I clarify that when you say "customer", you're referring to the Customer object: https://docs.stripe.com/api/customers/object?
worn imp
I believe so yes, that's what is a mandatory item beneath Invoice yes?
lime sonnet
Yes. the Customer objects represents a unique customer to a business.
It is technically possible to create all invoices in a Stripe account under a single Customer object but we do not recommend this approach. Customer management can become messy if the invoices are to be sent to different email addresses
worn imp
Customer management will be handled externally to stripe in another application, and invoices won't be sent via stripe either
lime sonnet
I see, but when the invoices are paid, the payment methods are saved to the Customer object on Stripe
worn imp
So a 'returning customer' could potentially see payment methods of 'other' customers?
lime sonnet
It depends on how your integrations are managing invoice creation and payment methods. Are you creating invoices for one-time payments?
worn imp
Yes, they won't be recurring payments
We looked at Payment Intents and one of the other items, but we needed to be able to dynamically adjust line items on creation and not be restricted to a product list and were told that Invoices were the way to go
lime sonnet
Right, using Invoicing does let you dynamically adjust line items as opposed to PaymentIntent, however, the concern here is about creating all invoices under a single Customer object. This is not a recommended approach and it will make your integration prone to Object Lock Timeout errors: https://docs.stripe.com/rate-limits#object-lock-timeouts
worn imp
So that would be a lock on the customer presumably?
lime sonnet
yes
that may prevent you from creating or modifying other invoices belong to the customer, or modifying the customer object itself
worn imp
What would you recommend overall then? We don't really want to manage customers in multiple systems
lime sonnet
I would recommend creating a customer object for every unique email an invoice is supposed to sent to.
worn imp
What would happen if I tried a create call with data for a customer that already exists? Would it just return the Id of that customer, or would it throw an error?
via this:
var service = new CustomerService();
Customer customer = service.Create(options);
lime sonnet
You will be able to create a new Customer object even if an existing Customer already exist for a given email address
worn imp
Eugh, not a fan of that...
Any other options for the overall solution then?
We also tried CheckoutSessions
lime sonnet
Not at the moment if you want to use Invoicing. If you do not wish to manage customers on Stripe, then the simplest way is to create a customer object for every invoice creation. You could use Checkout Session but note that if a post-purchase invoice is to be issued a Customer object will still be created: https://docs.stripe.com/api/checkout/sessions/create#create_checkout_session-customer_creation
worn imp
The checkout session can't support multiple line items though can it? With on the fly pricing? Wasn't it just a single $ amount?
lime sonnet
You can pass multiple prices in Checkout Session. I'm not understanding what's "on the fly pricing"
You can use either price or price_data to control pricing on Checkout: https://docs.stripe.com/api/checkout/sessions/create#create_checkout_session-line_items-price_data
If you passprice , it expects a price ID
worn imp
I'm just trying to remember why we would have swapped from Checkout session to PaymentIntent (to then go to Invoices).
If I can make a suggestion, it'd be to make these chats not disappear, I can't go back and reference them without copying them
lime sonnet
this chat won't dissapear but we do close idle thread. You should be able to reference our coversation by saving the Discord link
worn imp
I mean I've had threads from months ago that I can't see anymore and I'd really like to be able to read them right now...
But from what you're saying anyhow, even if I used a Checkout Session, it would effectively create a customer anyhow won't it?
lime sonnet
ah I see. Yes, Checkout Session will create a Customer object if the session is configured to send a post purchase invoice
worn imp
"if the session is configured to send a post purchase invoice" - this is presumably a flag of some sort? And what if it isn't, no customer record created and therefore no invoice created either? Realistically, I just want to be able to create a multi-line <something> where I can set the prices on creation and they can pay it.
lime sonnet
yes you can control whether a post-purchase invoice gets created after a Checkout Session completes: https://docs.stripe.com/api/checkout/sessions/object#checkout_session_object-invoice_creation-enabled
So if you don't want to send a post-purchase invoice after payment, then no Customer object will get created
worn imp
Ok, we're checking out the Checkout Session atm. While we have a look at that internally, can you please let me know how a refund would work in this scenario?
Checkout Session looks good from what we can see. Now we just want to confirm that invidual sessions can be refunded if needed
lime sonnet
To issue a refund, you can create a refund using the Payment Intent from the Checkout Session; https://docs.stripe.com/api/refunds/create
worn imp
Oh so a Checkout Session has a payment Intent reference?