This is indeed one of the biggest weaknesses of "pull-based" payment cards, and something most if not all natively phone-based methods do better.

The best credit and debit cards can do is PIN verification or biometrics (for Apple/Google Pay), but even there you still trust the terminal to not show you a different amount than you'll be charged (assuming the screen is even pointing towards you; I've often been asked to tap without seeing what I'm even consenting to).

Online, there's 3DS, but that's not required everywhere and for every transaction.

There once was a vision to extend both positive cardholder approval and cardholder authentication for each card transaction, but it turns out the friction of that is higher on average than just letting everything but the most egregiously suspicious fraud go through by default and handle the rest via the disputes process.

Out of curiosity:

> you open the app on your phone and it gives you a 6 digit BLIK code, you give that code to the seller

Is this the flow for online payments as well, or only for in-person payments?

> Is this the flow for online payments as well, or only for in-person payments?

On-line, too. Or should I say, first, because AFAIK on-line came first. I've been using it for years as my default on-line payment method where available, before noticing it becoming an option on POS terminals.

>>Is this the flow for online payments as well, or only for in-person payments?

works for both

Interesting, I wonder if there is some other initiation channel then? The chance of collisions with random 6-digit codes seems non-negligible.

I've been wondering this too. As I understand it, BLIK codes are generated on the back-end, so I imagine they have some clever anti-collision measures in place. What I know is:

- The TTL of the code is variable; on some days I've noticed it to be as low as 60 seconds, on others around 3+ minutes. Not sure if it depends on the type of transaction or time of day.

- After entering the code in charging widget/terminal, or giving it to a merchant, you still get a screen on which you need to explicitly confirm the transaction; it displays the amount and name of charging entity, so this would presumably reduce the impact of possible collision.

- Sometimes the codes generate instantly, sometimes it takes a few seconds; I always assumed it's network connection lag and/or usual webshit performance issues, but it would also be consistent with an anti-collision measure - if you run out of 6-digit codes, wait a second or two, some will free up.

- Not once I've heard any report or rumor about a collision.

IIRC a few years ago I saw some store asking for 6 or 8 digit BLIK codes, I guess the latter was how they were planning to expand from supporting just Poland to supporting whole EU. But that effort seems to have died out.

BLIK rocks. In addition to being a payment system for goods and services it can be used for instant private money transfers between individuals.

That's the problem. Every country has an alternative or ten, but what people actually need is one system that works across borders. That's the only way it reaches enough critical mass to be useful internationally beyond the EU, which nowadays is a requirement for it to be able to replace Visa/Mastercard in a decade or so.

Visa/Mastercard is the system right now. European banks issue these US debit cards often as the primary card for an account.

Yeah but approving every purchase from a merchant I trust, like Amazon, would be annoying. Gotta allow for one tap to purchase, like eg apple pay does

IIRC BLIK asks you if you want to skip the verification next time you buy from the same merchant.

I misread blik as “bilk” which is… probably the last word you’d want associated with your credit card or payment processor in English.

There used to be a beer designed to be mixed with milk called bilk. Last I heard, it was terrible. Maybe it's still around - I think it's Japanese, so it's unlikely I'd happen across it.