Comment by lxgr
8 hours ago
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.