#neel_72026

1 messages · Page 1 of 1 (latest)

native wigeonBOT
#

Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

drowsy magnet
#

hi! not sure what you mean. can you clarify/give me an example of what you'd like to see?

strong raft
#

I am selling consulting services, for example.
Price for 1st customer is $50 per hour, 2nd customer $60 per hour, etc
So instead of creating a product with mappings to all possible pricings, I will simply use checkout to bill my customers.
In checkout I can just bill - no need to create a product or pricing before having the ability to take payment (either one time or recurring)

drowsy magnet
#

well you have to tell Checkout what to charge

strong raft
#

yes, Checkout allows me to set unit_amount = xyz

drowsy magnet
#

you either do that using a Price object, or there's an in-line Price creation via price_data (or the unit_amount stuff yes)

strong raft
#

So given that using checkout is much more simple than the headache of creating 10 different possible prices for a product, and then 10 variations of each pricing for different discounts, why would I not just use checkout instead, and get rid of the headache?

drowsy magnet
#

not sure, what are you comparing against?

native wigeonBOT
strong raft
#

In one time payment, for example, before I can bill, I have to

  1. Create a Product
  2. Create all possible pricings for each product
  3. Then bill

Now compared to CheckOut, One time payment seems painfull. So my question is: Why would I use one-time-payment as opposed to using CheckOut?

drowsy magnet
#

Not sure what you mean by "one time payment", what API is that?

#

Checkout supports one time payments , and subscriptions. You're totally free to use Checkout in any way the API allows and that makes sense to you. Really not following what specific technical question you have here.

#

I assume you're asking "why should I create Prices and Products instead of just passing the details directly when creating the Session?"

#

and the answer to that is that it makes reporting easier since it's easier to track what you're selling and generate reports and organise the data. And it allows things like the name of the product or the tax behaviour to be specified upfront once and re-used. But there are 100% use cases where ad-hoc amounts for each individual customer make perfect sense, and that's totally fine and you can integrate that way using price_data or unit_amount