Faruk

Worth adding what actually protects you before you send, since the reversal question only arises after.

Many banking systems now check the name you typed against the name on the destination account and warn you if they do not match. That check is the single most effective protection for a push payment, and it is also the one people click past when they are in a hurry or being rushed by someone on the phone.

If your bank offers it, the warning is not a formality. It is the last point in the process where anything can be undone.

For question 3, the things that actually work, roughly in order of value per hour spent:

Authenticate the user, authorise every request. Each request should be checked against what that user is allowed to do, server-side, every time. This is the one that matters. Most real incidents are not "someone used our API" but "someone changed an id in a request and got another customer's data".

Rate limit per user and per address, with something stricter for unauthenticated endpoints.

Keep the expensive and dangerous operations behind your own server. If the client never has the ability to do the costly thing directly, no amount of replaying its traffic gets there.

Monitor for shape, not identity. Abuse looks different from use: bursts, sequential ids, odd hours, one account from many places. That is what catches the real cases.

Platform attestation services exist and do raise the cost for casual copying. They are worth considering after the above, never instead of it.

"A default is a lie you have written on their behalf" settles our argument, because both of our examples were facts and we were arguing about effort.

The part the folklore leaves out, which is why your conversions came out level: changing the country on the website is usually not changing the point of sale.

Most airline sites change the display currency and the language, and issue the ticket from wherever you actually are, based on your card and your address. So you see a converted price, you convert it back, and unsurprisingly it matches. You have changed the label on the shelf, not which shop you are in.

Genuine point-of-sale differences generally require the ticket to be issued in that market, which usually means an agent there, a card issued there, or a booking channel that is actually local. That is a lot of friction for a saving that may not exist.

This is why the trick has a reputation for not working: nearly everyone who tries it does the version that cannot work.

There are usually four copies and you have to know which one is biting you, because the fixes are different and only one of them is under your direct control.

1. The browser cache. The visitor's own disk. You cannot clear it remotely. You can only influence it with the headers you sent last time, which is the trap, because the headers that are causing the problem are the ones on the old file, already delivered.
2. A CDN or proxy. Your edge network holds a copy. This one you can purge, and most deploy tools do.
3. An intermediate cache, a corporate proxy, an ISP appliance. Rare now that nearly everything is HTTPS, but it exists.
4. A service worker, if you have ever had one. This is the four-day person almost every time. A service worker serves from its own cache and can keep doing so indefinitely, entirely ignoring your headers and your CDN purge.

Start by asking the stuck person to open developer tools and check for a registered service worker. If there is one, that is your answer and nothing else you do will help.