#Kellen - Coupons
1 messages · Page 1 of 1 (latest)
Stripe Coupons cannot be applied to PaymentIntents so I’m considering the following options to improve my system and allow for the use of coupons and upsells:
- Start using Stripe Products/Prices for calculating prices + using a Stripe Invoice to act as an “order” (since the Orders API is deprecated - correct me if I’m wrong on that). When a user decides to purchase an item they will be brought to the purchase page and this will create a Stripe invoice (via my NodeJS backend) with that Product/Price as an Invoice Item. I could then upsell other products and optionally add them to the invoice. When the user clicks purchase (and selects a previously saved payment method - or adds a new payment method that is then saved for later use), I finalize the invoice and charge it automatically (get the PaymentIntent for it and confirm it).
I think this might be my best option but I’m curious if it makes sense to use Invoices this way?
- Keep my current system but write a mini library to parse Stripe Coupons and apply them to my custom pricing logic locally. My concern with this is that 1) that’s a lot of manually work and 2) can I “redeem” a Stripe Coupon manually via the API?
This is a very flexible option and would allow me to handle more discounting options than what is available via Stripe but very time consuming and I'm not sure it's possible.
The first option would allow you to take more advantage of the Stripe Coupon features.
Coupons have useful features like max_redemptions, redeem_by and such that would require a lot of development on your own end to replicate.
Additionally if you use Invoices and Coupons you can more easily track which coupons are used where
Yea Option 1. definitely has much more appeal in many ways. Does it make sense to use Invoices in that way? It's essentially using an Invoice as a "cart" or "order". I'm concerned about how it will work with an "abandoned cart" - i.e. a user goes to the checkout page but leaves without making a purchase. Then there is just this Invoice that's not finalized. Do you think I should have any concerns with just leaving that Invoice un-finalized?
I agree that replicating max_redemptions, and redeem_by would be a lot of development on my end.
features like*
It happens even with PaymentIntents. A user gets to the Payment Element then navigates away and you have an incomplete Payment Intent
Darn users
Silly silly users
But, if your system had a means of logging users and any incomplete invoices associated you could surface that to them if/when they return to your applicaiton
Yea there was a request to handle "abandoned carts" and send users follow up emails so this approach could actually help with that request as well.
Then at least you could confirm whether the user wanted to continue where they left off or delete the Invoice while it's still in draft status
Yea that checks out. Good idea.
So, there used to be an Orders API right? Is using Invoices in this way a decent replacement for what functionality that API used to provide?
I found a sign up form in the docs for an Orders API beta, signed up for it, and then wasn't able to find that page again. Then I found some posts explaining that the Orders API was deprecated in ~2017. Just wondering if "orders" functionality is something that's coming again in the future or if this would be my long-term approach.
đź‘‹ Hopping in since snufkin has to head out soon
There are still some new APIs in beta (which we call out at https://stripe.com/docs/orders-legacy) but I don't know of any specific timelines
One thing I do want to mention if you go with Invoices - I don't know a lot about or pricing structure, but I would check whether the switch to Invoices would affect your overall fees
Oh interesting call out - I hadn't considered that. I'll dig into that and see what the impact will be.
Thanks for hopping in
I do get a 404 at https://stripe.com/docs/orders-legacy
Did that page get moved?
Well to be clear I get a nicely handled "Page not found!" 🙂
Ahhh that's my mistake - that page is only visible for users who have used our previous orders API
Ah that would explain why it's still linked in a few places.
Oh here we go, this is the Orders beta that I found: https://stripe.com/docs/orders
nice! yup that's the one I was thinking of 🙂
There's no timeline on that one?
It's pretty much exactly what I want haha
Of course
Yeah unfortunately I don't know what the public timeline is - you can try emailing again and check