4 ms·

> Let’s say your app also allows promotional codes to be used, and that promo codes in your app live outside Stripe, because Stripe does not support promo codes

> Let’s say your app also allows promotional codes to be used, and that promo codes in your app live outside Stripe, because Stripe does not support promo codes for your type of product. What this means in practice is that before calling Stripe’s confirmPayment, you have to send a request to your server with the promo code that the user wants to apply. This request can respond in one of two ways - either the promo code is valid, or it isn’t. If it is valid, then you can go ahead and call confirmPayment. If it isn’t valid, then you need to render validation errors. This is an extremely trivial bit of JavaScript, but it is made difficult because it is trying to use a JavaScript framework developed by people who hate JavaScript. Do the form validation on the client side to give users instant feedback and then do final validation on the server side where you enforce business rules. These are two different kinds of validation and it's not actually effort saving to try to combine them. If you have good client side validation, you can just be a hard ass on the server side because you know that anyone who gets the server side error is already bypassing client side validation, so they are being naughty to begin with. It makes like easier to keep the validation separate.

tomhallett 3y ago
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.
- earthboundkid 3y ago
  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.
  - cassiogo 3y ago
    > 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

tomhallett 3y ago

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.

earthboundkid 3y ago
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.
- cassiogo 3y ago
  > 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