#Kellen - Coupons

1 messages · Page 1 of 1 (latest)

maiden ocean
#

Hi đź‘‹

latent oar
#

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:

  1. 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?

  1. 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.

maiden ocean
#

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

latent oar
#

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*

maiden ocean
#

It happens even with PaymentIntents. A user gets to the Payment Element then navigates away and you have an incomplete Payment Intent

#

Darn users

latent oar
#

Silly silly users

maiden ocean
#

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

latent oar
#

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.

maiden ocean
#

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

latent oar
#

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.

civic fossil
#

đź‘‹ Hopping in since snufkin has to head out soon

#

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

latent oar
#

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

#

Did that page get moved?

#

Well to be clear I get a nicely handled "Page not found!" 🙂

civic fossil
#

Ahhh that's my mistake - that page is only visible for users who have used our previous orders API

latent oar
#

Ah that would explain why it's still linked in a few places.

civic fossil
#

nice! yup that's the one I was thinking of 🙂

latent oar
#

There's no timeline on that one?

#

It's pretty much exactly what I want haha

#

Of course

civic fossil
#

Yeah unfortunately I don't know what the public timeline is - you can try emailing again and check

latent oar
#

Cool, I followed up with support so hopefully I'll hear back soon. It would be awesome to get into that beta.

#

Thanks so much for your help @maiden ocean and @civic fossil - very appreciated!