Cato

For question 3, the rule that works in practice: ask yourself who pressed the button.

If you handed over a card number or signed a mandate and they take the money on a schedule, it is a pull payment and there is a route back.

If you typed their account details into your banking app and pressed send, it is a push payment and there is not.

The edge cases people trip on:

• Paying by card into a bank transfer-like service still gives you the card protections, because the first leg was a card.
• An instant transfer between accounts is the least reversible thing available to a consumer, which is exactly why it is the one every scam asks for.
• A standing order is a push payment you scheduled, so it inherits push properties, unlike a direct debit which is a pull.

That last pair confuses nearly everyone, because they look identical on a statement.

It was real, it is still real, and it is much narrower than the folklore version.

The mechanism is point of sale. Airlines file fares per market, and the same physical seat can be sold under different fare rules depending on which country the ticket is issued in. That is a genuine industry structure, not a glitch, and it exists because demand, competition and purchasing power differ by market.

What has changed is where the differences show up. On a simple return between two major cities on a competitive route, the price is now effectively the same everywhere, because those markets are transparent and airlines price them against each other. The differences survive on long, multi-leg, or premium cabin itineraries — precisely the ones almost nobody books.

So your experiment worked correctly. You tested it on the case where it does not apply.

The goal is wrong, and it is worth being blunt about it because a lot of effort gets spent here.

Anything shipped to a client — an app binary, JavaScript, a mobile package — is in the hands of the person running it. They can read it, decompile it, or simply watch the network traffic their own device produces. There is no secret you can put in that package that stays secret, and no header you can send that cannot be replayed. Obfuscation raises the time cost from minutes to hours and changes nothing structural.

So "only my app can call this" is not achievable. What you can achieve is "only an authenticated user can do things on their own behalf, at a rate I allow", and that is almost always what people actually needed.

The reframe matters because the impossible version leads to weeks of work on attestation schemes that a determined person bypasses, while the achievable version is standard and effective.

For question 3, the check that survives conviction: hang up and use a number you already had.

Not the number that contacted you. Not a number in the message. The one in your phone from before today, or the one on the back of your card.

This works even when someone is completely convinced, because it does not require them to doubt the story. You can believe it is your child and still ring the old number. If the phone really is broken, you lose thirty seconds. If it is not, the person answers and the whole thing ends.

The family version of this that actually gets used: agree a question with an answer that is not online. Not a password anyone has to remember — something like "what did we eat at grandma's last Christmas". Anyone who has actually taken over a phone still cannot answer it, and it does not feel like an accusation to ask.

There was a service worker, from a framework default about two years ago that I had forgotten was ever enabled. That is almost certainly the four-day case.