Contactless card payment on a POS terminal abroad

From the outside, the Visa contactless world looks very simple. You tap the card, and the transaction either goes through or it doesn't... But once you get a little deeper, especially at the point where the limit is exceeded and the PIN comes into play, the subject suddenly becomes more complex. And we ran into an interesting problem at exactly such a point.

I would like to describe in some detail a situation we encountered recently with contactless transactions made abroad with our bank's cards, for customers who had reached their contactless transaction limit. The tricky part is that the problem did not occur in every country. While everything worked as it should in some countries, errors in others made things even more complicated. For example, in transactions made in the Netherlands, the POS device showed a very clear and guiding message such as "Contactless limit reached, please use contact", whereas in transactions made in Saudi Arabia, the POS device showed an error screen directly.

Same card, same limit, same scenario... but a completely different user experience.

At first glance, the classic questions come to mind: is the limit different, is the country different, is risk kicking in? But as you dig deeper, you realize the issue is actually at a much more fundamental place: the response the issuer gives and how the POS interprets it.

With PSD2, Visa made an important change of approach on the contactless side. In the past, the logic was simple: if the limit was exceeded, the transaction was declined. But in the new model, Visa says "don't decline, verify the user and continue." In other words, instead of cutting off the transaction, it adds one more step.

This brings us to response code 70.

70 is actually a very human message:
"I'm not saying no to this as it stands, but enter your PIN first and then let's continue."

In other words, the system is not saying "no" to you, it is saying "one moment."

The 65 we are used to is the exact opposite:
"This transaction is not possible."

The difference between these two sentences completely changes the behavior in the field.

But the really interesting part starts from here. Because no matter how correctly you act on the issuer side, if the POS device on the other side does not understand it the way you do, the story goes somewhere else entirely.

In Europe, things go quite "by the book" in this respect. POS devices know 70, understand what it means, and continue the transaction by asking for the PIN. In other words, the flow you designed really works.

But once you step outside EMEA, things get a bit more like real life. Some POS devices interpret 70 correctly, some treat it like an ordinary error, and some simply cut off the transaction without bothering. You are actually saying "we can continue", and the other side says "okay, I closed it."

The problem we experienced was exactly this. When we returned 65, some POS devices retried, but others ended the transaction right away. Yet that is not the flow Visa has in mind. The goal there is to direct the user to PIN and complete the transaction.

Let me explain this with a more everyday example.
65 is like ringing the doorbell and nobody answering.
70 is more like this: the door opens, but you are asked for ID before you can come in.

Now, while you actually want to say "come in, but show your ID", you end up saying "we're closed." And the POS behaves accordingly.

So what is the solution? Switching to 70?

Short answer: yes, largely. But it is not a magic wand.

Because even though 70 is a global Visa code, it is not implemented with the same maturity everywhere in the world. In Europe it works very stably. In other regions the behavior is more of a "hit and miss". Most of the time it gets fixed, but not always.

At this point, it should be said that similar topics are also being regulated on the Turkish side. The regulations BKM (Interbank Card Center) has made regarding contactless transactions, and especially the flow changes concerning below-CVM-limit transactions, play an important role in standardizing this behavior. So this is not just a global problem, but also an area that is actively managed locally.

You can find the details of the Turkish side of this topic in the post I wrote earlier, below:

In this post, I tried to explain in more detail how the domestic flow changed and how below-CVM-limit transactions are handled.

At this point, the reality I like the most, but which is just as hard, is this:

In payment systems, doing the right thing is not enough.
You also need to manage how the other side understands that right thing.

In other words, it is not just about being "spec-compliant".
It is also about constantly observing "what actually happens?".

In the end, where we arrived is this:
For switching to PIN in contactless transactions, the correct semantics is 70.
But the moment you use it, everything will not be fixed automatically.

From there, the job is to observe, measure and, when necessary, adapt.

And frankly, I think the hardest but most instructive side of payment systems is exactly this.

And I guess the best part of the job is this too.

These kinds of topics are explained very clearly and cleanly in books. But when you get down to the field, with different countries, different POS devices and different acquirers, things turn out completely different. And that is where most of the learning actually begins.

For me, the most enjoyable part of this episode was this: on one hand you are trying to solve the technical side correctly, and on the other hand you are trying to understand how the rest of the world applies that correctness. Managing both at once is what really makes the job "payment systems engineering".

If you work on similar things, you probably feel the same way.
"I'm doing the right thing, so why doesn't the same result come out everywhere?" is an unchanging part of this job.

But that is precisely why it is enjoyable.

Because every problem teaches you to dig a little deeper, to understand the system a little better, and sometimes to "reach a more correct result by bending the correct a little".