#mathias_promotioncodes-restrictions
empty mortarBOT
đ 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/1225739863014379580
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
sudden emberBOT
mild ibex
mathias_promotioncodes-restrictions
Hey @hazy breach ! There isn't really a direct way to do this in our API if you explicit limit this to one usage
You'll have to keep track of this on your end and either change the restriction or keep it unlimited at first and deactivate it after the first real usage
hazy breach
Do you know how this is handled in the Stripe Customer Portal?
mild ibex
The CustomerPortal can't start a Subscription so that shouldn't be relevant right?
hazy breach
We have used the customer portal before and just recently created our own payment solution.
mild ibex
yes but the CustomerPortal is used to manage existing Subscriptions not start a new one
hazy breach
sorry i meant a checkout session
mild ibex
you were asking about someone entering a PromotionCode but not paying which is usually related to a Subscription creation with default_incomplete
Ahhhhh okay so you're saying that on Checkout they are starting to pay, enter a PromotionCode, never pay but it still considers the code consumed? Do you have a concrete example I can look at?
hazy breach
yes that is correct. I dont have one right now, becase we have used a bandaid solution for some time now where when the customer clicks "pay $xxx", it fires a call to the backend which creates a subscription and returns a client secret. When the frontend recieves this secret, a useEffect is triggered which confirms the payment.
The problem here is that Apple Pay does not allow this, because the payment confirmation is not directly associated with a user action, because there is an async event in between the click and the confirmation.
I can change the integration locally and send you an example.
mild ibex
yeah sorry I'm struggling a bit to follow the overall flow/problem. But ultimately if you apply the PromotionCode or Coupon to the Subscription then it counts as a redemption. If the customer doesn't pay then you have to handle this accordingly afterwards. What you can do is remove the restrictions of "number of use" and deactivate it after it's been used once
hazy breach
I see, well the issue I can see with that is how to distinguish a "real" redemption and a redemption that has been done before the customer quits.
But thanks for your time
mild ibex
You know whether the Invoice that the Coupon/PromotionCode was applied to was paid successfully or not for example. Or the related Checkout Session
hazy breach
Alright, I'll try that out.
Thanks again
mild ibex
Sure thing!