#jasperste_api

1 messages · Page 1 of 1 (latest)

marble wedgeBOT
#

👋 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/1342105321543565322

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

upper lion
#

It currently will throw a 400 (which is logical, but it saves a lot of checking if Stripe can just ignore it if it's not applicable in the checkout session)

burnt lark
#

There is not, no. That'd be a feature request as it isn't how it works today. Also, not sure I agree with your design – your explicitly tell us to apply discount X so it'd be weird if we just silently dropped it instead of throwing an error, IMO

upper lion
#

Yeah, I tend to agree with that.

We would like to create a link with a prefilled coupon, but for some situations the coupon will not apply. Stripe does these checks when a customer enters it, but throws a 400 when we apply. Meaning we likely have to do all these checks ourselves before applying

#

I thought maybe there was something smart to do here

burnt lark
#

Yep, gets tricky with multi-currency prices like your example. I agree it's not great, but neither is dropping the discount

upper lion
#

The payment link page has a prefilled_promo_code to support a prefilled field. This would be most ideal but isn't supported for checkout session.
This would mean it's prefilled but would still yield a problem to the user if not applicable after all.

#

But I do understand the reasoning here, I will check what's best. Thanks

burnt lark
#

But the 'prefill' via a URL param is a PL specific concept

upper lion
#

Yes indeed. Thanks for thinking along here. it's a bit extra work to check these codes in advance