Hacker News Reader

Comment by tomhallett | Hacker News Reader

In this case, are you recommending the serverside validations (is a promo code still active and not expired) run after the call to stripe's confirmPayment, because you have a clientside validation (promo code matches a regex)? If so, that seems problematic because your severside validation could have prevented stripe from ending up in a dirty state. If not, then I'm not following what you are recommending.

View on HN

I find the setup as described confusing. What is stopping a customer from just triggering the Stripe call with an invalid code? Presumably, the answer is they can do it, but after the Stripe call, the order will be rejected at fulfillment time. So, the check is just a preflight, but the real validation comes later. (Or is there a signature involved? Could be, but TFA doesn't specify it.)

Either way, you can just do a quick JSON fetch call on the client side as part of client side validation once customers type the code into the box and then pass it along to the server for the final POST.

> Could be, but TFA doesn't specify it

If I understood correctly it does. They are handling promo codes outside of stripe.

I feel like you are missing the point of the article

> This is an extremely trivial bit of JavaScript, but it is made difficult because it is trying to use a JavaScript

Yes, it is trivial javascript, and it was trivially solved by a couple of javascript lines

Reply on news.ycombinator.com