Prevent users with multiple sessions using a single use voucher

Question

I'm working on a .Net eCommerce site that allows users to use vouchers to get free products, discounts etc. The problem I have is that there have been instances of users, who have been issued single use vouchers, using their voucher multiple times across several sessions. They add the voucher to their basket in different browsers when it hasn't been used, then they can check out all of their sessions and use the voucher multiple times.

I've thought of a couple of possible solutions to this problem, the most obvious is essentially a "last ditch tackle" - i.e. just before persisting the order, doing another check to see if the voucher is valid. What I don't really like about this idea is the potentially poor user experience. All seems well, you go to make a payment and it's been rejected due to the voucher now being invalid.

Another idea I had was to "quarantine" the voucher when a user adds it to the their basket. Then other users and other sessions are prevented from adding the voucher to their basket until the user who has it quarantined removes the voucher or their session expires. I think this would be a better experience for the user, but it's much more complicated to develop and test.

It's also probably not a bad idea to do both.

I bring this to you because this feels like a problem that has already been solved a thousand times. Does anyone know of a pattern, a .Net compatible framework or anything else that would solve this problem without me having to reinvent the wheel?

Answer 1

Any time you have validations like this, you need a "belts and suspenders" approach. If you don't have that validation at the point of the user clicking the purchase button, you will always have a means of exploiting that hole in logic. It's for this same reason that validation needs to be enforced in the UI as well as in the services supporting the UI.

While it is a poor user experience, these users are attempting to circumvent the typical use of your site in a way that costs you real money. Preserving a "good" user experience here is a lower priority than preventing abuse of your systems.

The next question is how does your system model the checkout process:

• Do you keep that in the back-end (i.e. in a database, key/value storage, etc.)?
• Do you keep that all in the front-end (i.e. in the browser itself)?
• Do you keep that in server Session variables?

The last option is the least preferable. It really does hamper the ability to horizontally scale.

Our company has adapted to use JWT tokens to track sessions, and the JWT is provided with every API call. That allows us to associate any activity to the same user regardless of the number of browsers or other "sessions" they have.

Using something like Redis key/value in memory server to handle the shopping cart, and you derive the key from the combination of the User's ID and the shopping cart they have, you can enforce one cart per user no matter how many sessions they have.

This approach does have some server side clean up, but at least you avoid the situation where you have multiple carts for the same user. For example, if the session token expires, or the user actively logs out, you can scan the Key/Value store for all keys that starts with the user's ID. That lets you kill the user's cart. Or you can simply have those keys expire after a set period of time so if the cart isn't used in say a week, it removes itself so you are no longer tracking it.