#jenn

1 messages · Page 1 of 1 (latest)

harsh thornBOT
plain cedar
burnt scarab
#

Yes, times_redeemed is the number we'd like to increment as customers check out with their one-time purchases with promo codes applied. But when we're testing this, we're not seeing this number increase (as there's no way in the API that we see to tie the promotion_code to the payment_intent)

plain cedar
#

Can you elaborate on how you're envisioning using Promotion Codes?

You can't use Promotion Codes when working directly with Payment Intents, you have to use Checkout Sessions that can prompt customers for and accept Promotion Codes.

burnt scarab
#

We were previously using Checkout Sessions, but recently moved away from that so we could have a more professional and tailored checkout experience.

#

Maybe not more 'professional', per se, but to have the ability to fully brand and customize our checkout experience.

harsh thornBOT
plain cedar
#

Gotcha, that makes sense, and is a good reason to move to a Payment Element integration. When working with the Payment Element though, you're working directly with Payment Intents which don't accept Coupons or Promotion Codes. Instead you explicitly provide the Payment Intent with the amount for the payment, so you will need to calculate discounts on your end.

That leads to Promotion Codes and Coupon redemptions not being incremented because to our system they aren't being used, so you'll need to build your own logic for tracking the redemption of those.

burnt scarab
#

Got it, that is how I was seeing Payment Intents worked. I was wondering, if we set up the payments to generate Invoices and/or Quotes, is it possible to add a Promotion Code that would count redemptions to those somehow?

plain cedar
#

That might be an approach, but I think it would likely be simpler to track the redemptions yourself. If it makes it easier, you can likely leverage the metadata parameter value on the Promotion Code for that.

You could store a key/value pair along the lines of non-stripe-redemptions as the key, and where the value is the number of times the Promotion Code was used in your flows. Then you could add that number and times_redeemed to get the total number of redemptions across the lifetime of the Promo Code. Something to keep in mind there though, is that the additional interactions with the Promo Code object will require additional requests so you'll want to keep rate limits in mind:
https://stripe.com/docs/rate-limits

#

The more I think about it the worse of an idea using metadata is, and I apologize for suggesting it. It would likely be much easier to track this on your end without using Stripe objects as a container for that data.

burnt scarab
#

Hah, yes, we'd considered saving metadata, but we actually want to support customers also being able to check out with $0.00 totals, in which case they won't even have a Payment Intent at all. But storing these on the Customer didn't seem to make sense, either.

river beacon
#

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

burnt scarab
#

That's partly why we thought Invoices might be a good location, because it's possible to create Invoices for $0.00 totals.

river beacon
#

In the case of a zero total you can use a Setup Intent instead of a Payment Intent.

#

Well, actually, question: are you saving the payment info for future use, or is this for one-time payments where you don't save the payment info?

burnt scarab
#

We would have no need to save the payment info at this point, though we'd be open to it. But, we'd still want a way to track the promo code redemptions, so I don't think it would solve the initial problem 🙂

river beacon
#

Gotcha, yep. Best approach is to probably build something to track this on your end independently of Stripe.

burnt scarab
#

We actually already have our own promo code tracking system 😂 but we were hoping to store all our promo codes in one place, in Stripe! But it sounds like this is a firm technical limitation to building your own custom checkout.

river beacon