#ben-talentville_api

1 messages ¡ Page 1 of 1 (latest)

noble sedgeBOT
#

👋 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/1293310925926961214

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

shut horizon
noble sedgeBOT
bleak sable
# shut horizon Hello Have you referred to this doc? https://docs.stripe.com/billing/subscripti...

That refers to subscriptions, not regular old purchases. In my site store and with the way I use coupons, there can be multiple, each referring to a single item being purchased. The docs do say that for purchase sessions, only one overriding discount can be there. And, even if it allowed more, it would not allow it to be applied to a single line item. That approach seems really bad, as it is easy to see how each item being purchased might have its own individual discount or coupon.

barren marten
#

Hello! I'm taking over and catching up...

#

Ah, okay, so are you using one-off Invoices or Checkout? What are the line items you're referring to on?

bleak sable
#

I think the term is one off (not sure??), I create a session with line items and use the embedded form to collect the money.

#

These are not recurring charges.

barren marten
#

It sounds like you're probably using Checkout Sessions, not Invoices? It's important to be clear about this; they work very differently even though they can both be used for single, non-recurring charges.

#

Can you share a bit of the code you're using to create one of the "sessions" you mentioned?

bleak sable
#

$stripevars['ui_mode'] = 'embedded';
$stripevars['line_items'] = $lineitems;
$stripevars['customer'] = $customerid;
$stripevars['mode'] = 'payment';
$stripevars['return_url'] = TVSITEURL . '/xpurchasecomplete/{CHECKOUT_SESSION_ID}';
$stripevars['saved_payment_method_options'] = ['payment_method_save' => 'enabled'];
/* 'discounts' => [['coupon' => "$tenpercentcoupon"]], */

$checkout_session = $stripe->checkout->sessions->create($stripevars);

barren marten
#

Ah, yeah, so you're creating a Checkout Session. You're correct that a Checkout Session doesn't support per-line-item discounts. For that functionality you can switch to one-off Invoices: https://docs.stripe.com/invoicing

bleak sable
#

Uggh, that's terrible. I cannot imagine the numbskulls who limited discounts and coupons with the embedded checkouts, which otherwise are so simple and easy to implement, all embedded right in my site

#

Now I have to investigat eand learn an entirely new API and strategy

#

And it seems invoices have a due date or something? Are they also for immediate payment with a checkout? All of my purchases must be done immediately

barren marten
#

I mean, it's fine to have opinions, but if you want to insult my colleages I'd be happy to remove you from this server so you can do so elsewhere.

bleak sable
#

Flexibility in what I charge is so key to being able to allow varied discounts for varied products

barren marten
#

You can set an Invoice's due date to now and require immediate payment. You can also take the approach of creating an Invoice, which creates a Payment Intent behind the scenes, then make your own payment form using Stripe.js to confirm that Payment Intent.

#

There's a fair amount of flexibility.

bleak sable
#

To just be able to have a single overriding coupon for the entire cart doesn't seem logical to me

barren marten
#

Checkout Sessions are designed for more straightforward use cases than yours. For more complex functionality, like what you need, the solution we offer are one-off Invoices.

bleak sable
#

I will investigate, maybe it will be straightforward, but it does mean I cannot make the payent form 'feel' like it is all within my site.

barren marten
#

You can, with the Payment Element approach I described above.

#

You don't need to use the Stripe-hosted payment page if you don't want to.

bleak sable
#

THe beauty of the sales pitch I was given was that the embedded form would make it so easy, which was true. Creating my own form and all that is a new level of complication, being up front and fair about it

#

I will read the docs, that is all I can do if I want to be able to retain the functionality my site has had in terms of offering discounts on varied items to drive memberships and other purchases

#

Suggestion from new customer: Allow coupons in line items in the embedded checkout. That would exponentially expand the use cases.

barren marten
#

I'll flag that as a feature request internally.

bleak sable
#

What kinda sucks for me is that for basic purchases, it all works great and in two days I have almost completed implementation of Stripe in my dev website. Do I try to use a strategy of making a bunch of prices for each product, representing full price and maybe 10% off and others, or do I change the whole implementation which feels like that is another week of reading docs and programming. Sigh.

barren marten
#

That's entirely up to you.

#

So you don't need to have, like, 10% off versions of all your Prices sitting around.

bleak sable
#

Do you mean creating on the fly prices? Won't that clog up my dashboard prices list with tons of indivisually created on the fly prices for each product?

barren marten
#

No, the Prices created via price_data don't show up in the Dashboard.

bleak sable
#

Ahhh, I did not know that

#

So it is a temporary price structure used for that one purchase, then it goes away?

#

SO you are saying I could calculate the actual price after the discount and create a temp price data for tha tline item with the actual price being paid.

barren marten
#

It doesn't go away, it continues to exist behind the scenes as part of the record of that transaction, but it's not going to be visible or get in your way.

#

Yes, that's what I'm suggesting as a possible workaround.

bleak sable
#

Well, that is probably the best workaround

#

Use the real price for normal transactions, but for coupons use on the fly price data even if that means there will not be a nice "10% off" marker at the bottom of the item list in the form

#

I might suggest the docs reflect that option since it allows for indivisual prices independent of the prices stored in the DB

barren marten
#

The docs I linked you to do reflect that option.

bleak sable
#

And to be honest, I might just ignore the stored prices and always just use on the fly price data for each line item, using the copy of all the prices that are in my own database, thus never risking them being out of sync

#

THe docs show the price data creation, but do not specify that they get saved only in the BG and will not clog up the price list in the dashboard

#

That was my worry, hundreds of prices in the list

barren marten
#

That's fair, it could be more clear about how it works, but trying this out in test mode quickly shows how it works.

bleak sable
#

well, that will allow me to just set the price from all my own calculations, coupons and add ons, from my initial learning ofthe API it seemed the way to do it was meant to be using price IDs

barren marten
#

We do generally recommend using Price IDs for existing Prices, as that fits most use cases better, but we also have price_data for use cases like yours.

bleak sable
#

Thanks for the help, that workaround is gonna save my rear end in terms of programming

barren marten
#

Happy to help.

bleak sable
#

All the best

barren marten
#

Candidly, for next time, it would help to avoid comments like the "numbskulls" quip. That kind of thing is going to make most people not want to put in the effort to help you further.

bleak sable
#

Well, you know how it is, updating my website is so critical to me, especially payment, and I was completely stumped. We all get heated from time to time.

#

Still, I hope my suggestion for line item coupons makes its way up the chain, it would allow easily for so many use cases.