why do websites, where you buy stuff, still need that “don’t use the browser back button to click away when you are making a purchase”. Have we not got a better solution?
In: 52
[removed]
Sooo there are a few things at play.
First, the payment system is one of those systems where if it works, you don’t wanna screw with it cause you don’t wanna break it.
Second, not everything is in the control of the site. A lot of it is driven by your browser, which the site makers can’t reliably account for ahead of time. This makes ensuring appropriate edge case behavior more challenging.
Third, many of these sites DO have a better solution and may have implemented it already. It’s a payment system, so getting it right is crucial. Even so, there’s a difference between fixing a problem and being confident you’ve fixed a problem. Especially with that second problem at play. If the problem is “probably fixed” but everything still works, the developers may leave the message in since it’s not harming anything, but it is reducing the number of times that fix gets field tested.
There are better solutions, and they’re likely being used with the warning left just because it’s easier that way.
The idea is called idempotency, which is a fancy word that just means doing a thing multiple times works the same as if you only did it once. For example, setting your phone’s background to a particular image is idempotent – you can change your background to that image again and again, and it won’t be any different than if you did it once.
Idempotency is a big deal in computers because things go wrong and it’s important to be able to try them again when they do. But, sometimes certain things just aren’t easy to make idempotent – sending an email, for example, is really tricky to make idempotent. If there’s an error sending the email, does that mean it got sent? Did it not?
A common solution to this is what’s called an idempotency key. It’s usually a random series of letters that should only ever be used once. So for example with the email, what you could do is decide ahead of time with the person that you’re sending the email to that any emails with the same idempotency key as a previous email should be ignored. That way, if sending the email gets an error you can try sending the same email again with the same idempotency key, and be confident that only one email will be seen by the person you’re emailing – if both emails actually go through, one will just get ignored.
The trouble with this, though, is maybe it’s slow or expensive to send those emails. There’s a lot of processing and double checking that needs to be done, so even if the recipient won’t get two it’s still a waste of time to send a second email if you don’t need to.
That’s likely what’s happening with those pages that warn not to press back while making an order – if they’re designed well they should have checks in place to try to make sure the order is idempotent, but they probably still have that warning because even if things don’t break it likely still slows their stuff down having orders done twice when they don’t need to be.
We do have better solutions. You definitely don’t get that on Amazon.com.
The problems are:
1. Designing websites is hard, and it’s easy to screw up or use poor practices
2. Many *many* websites were designed years ago, and haven’t been updated for modern best practices
Well…. No.
We used to be in the position where that didn’t exist and the payment site would just forward you to a URL that indicated that payment was complete.
But then people would go to that URL without actually paying and getting free stuff….
So now the website itself waits for the payment to complete (during which time you would still get charged (or at least a hold on the money) regardless of you leaving the site, which is a problem for the customer and not the website).
Basically it’s there so you don’t leave the site, get charged and then have to have the site cancel the transaction, which would upset you.
There does exist better solutions, and most of the times clicking the back button will not have an adverse affect in most websites designed using modern solutions.
Suppose you have two individuals (A and B) who are performing some work. And suppose that for B to perform their work, A must finish theirs. Let’s also suppose that there is some runner who takes a non-instantaneous amount of time to transfer A’s work to B.
Let’s say that A finished their work, and handed it to the runner, who began to go to B. And while they’re on the way A calls out “wait come back I need to change something.” What happens?
Well if the runner is close enough, maybe they’ll go back and transport the updated work, and discard the old one. If they’re halfway between, maybe they finish giving the work to B, but also have someone takes A updated work (I.e duplicate items were created.) And lastly, if they’re already almost at B, they’ll just ignore A and continue on.
Notice how all of these scenarios is dependent upon where the runner is at in the process, rather than A’s statement of “come back.” That’s essentially what is going on with a lot of payment screens.
When you click the back button, what happens is dependent upon where in the process you was already at. Maybe it’ll cancel the previous order, and let you place a new one, Maybe you’ll accidentally be double charged for both orders. Or maybe it’ll ignore the fact that you went back, and just finish the order.
To account for this, websites try to implement a single policy of “don’t go back,” so that the user knows nearly 100% of the time what will happen. Your payment is going to be processed, and the order fulfilled.
simply put, the “why?” is because their app is crappy
if designed properly, it should be idempotent. (eye-dem-potent) i know it’s a big crazy word for ELI5, but it’s an important word. it basically means if you have an app or program or a form that you submit from a webpage, you can run it over and over and over and nothing bad will happen. including hitting the back button after you click submit.
the problem is, in some poorly designed apps, when you click submit, the app writes a “task” into a task queue. (queue just means a list of tasks that need to be processed, in the order they were created) bad apps will just add a second identical task to the queue if you click the back button, so if you’re buying something, you’ll get two orders, and your credit card will get double charged. the good news is, some banks actually detect identical amoutns submitted within a short period of time and will deny the second one because they know that 99% of the time, it’s a mistake.
if they designed it better, they would have the app check to see if an identical request is already waiting to be processed. someone could possibly buy something, then realize a minute later “crap, i needed to buy two”, then buy another one, making a nearly identical order, but in that case, you WANT both orders. so you’d still want the app to be smart enough to know the difference, so probably something like “if an identical order is currently in the queue, and it’s been less than 2 minutes, cancel this one, we’ve already submitted”
there’s way more to this story, like the actual reason WHY pushing back button can cause you to get double charged. the important key takeaway is how the app is designed to be able to handle this
Those websites may store your important data but they want nothing to do with your credit card info as that is something they send straight to a payment processor. On your invoice you often see the last four digits because again they don’t want to store that info. It would require extra security and a lot more liability than just your name and address.
Why does my eraser allow me to rub out stuff I want to keep? Finding l sometimes function cannot account for intention. On top of which in this case you’d be asking the browser to be prevented from doing something outside of the page it’s displaying and essentially within your PC environment. I’m trying to think of anything else where a website would be expected to be able to have that control over the users environment with explicit permission.
The back button makes the browser send the request it sent before the previous one (if you click multiple times, it will go back deeper in the past). It doesn’t undo the last request.
If you did a request before that added something to your cart or bought something, you can’t undo it with the back button. If ever you go back on them, you might either get them again or it might realize it’s the same request and not redo it, but it will still not undo it. If you go back to your request before that, you’ll go to where you were before the getting the item in your cart or purchasing it, but it don’t cancel that, since the back button never send undo request.
If you got a item in your cart, it should be trivial to remove it by clicking on a delete button or an x button. Those will send request to remove them.
If you purchased an item you don’t want. You’ll need to cancel the purchase, which can be a bit more complex, and not always be accepted.
Latest Answers