jenn

[granite verge]

or is it acceptable to check the coupon validity ourselves, and calculate the discount as well?
I'd actually suggest going this route

[granite verge]

Accept the coupon or promo code in your own UI and check against your own backend + stripe for any validity rules

Then apply the appropriate discount to the payment amount and show some representation of the coupon/promo somwhere

[static prism]

Interesting! I imagined that it'd be smart to rely on Stripe to check those things in addition to us checking them, to double-confirm that it will be applied. Does that mean we need to check every promo_code.restrictions option to ensure that each one is a fit for a given price/product? My main question within those restrictions is on restrictions.first_time_transaction. Do we then need to check the customer to see if they have any previous transactions? If so, what is the correct way in the API to do so?

[granite verge]

Yes restrictions like that would only apply when using the coupon/promo with one of our surfaces like Checkout or Subscriptions

If you're doing your own custom payments, you'd need to check any such restrictions

[static prism]

For reference, we're using both one-time payments and recurring subscriptions

[granite verge]

For the subscriptions then you can apply the coupon via the API, then only handle custom validations for the one time payments

[static prism]

For the subscription, we'd still need to do some validation in order to show the discount to the user before final checkout though, correct?

[midnight fable]

Hi there 👋 taking over, as my colleague needs to step away

It depends on what validations you're referring to, but yes. Generally you would show the user a subtotal once you verified that the coupon applies to the product.

[static prism]

Makes sense. I guess my main concern is about the first_time_transaction validation, and what we should check ourselves to make sure that it's valid for a customer or not