In my previous post (https://arifunal.com/yazi/visa-yurtdisi-contactless-islemlerde-yasanan-sorun-uzerine/), I talked about response code 70, which Visa uses to redirect contactless transactions to PIN after a limit is exceeded. To recap briefly, code 70 represents an approach that, instead of saying “transaction declined,” says “continue with PIN,” that is, it moves the process one step forward instead of cutting the transaction off.
Based on this approach, we made the necessary changes in our authorization messages on the issuer side and updated the system to return response code 70 in limit-exceeded scenarios. Technically, everything was quite clear; this was the model Visa recommended, and we had implemented it correctly.
However, once we went out into the field, we saw that the matter does not end there. In fact, the real story begins right after this point.
We said continue with 70, but not everyone understood the same thing
The flow in our minds was actually very simple. The POS device would receive code 70, interpret it correctly, ask the user for a PIN, and the transaction would complete smoothly.
In some countries and on some POS devices, this is exactly what happened. Code 70 was handled correctly, the PIN was requested, and the transaction completed without problems. In this scenario, everything worked as it should.
But on some overseas POS devices, we did not see the same result. Despite the same card, the same transaction and the same limit excess, we encountered different behavior. Some POS devices did not understand code 70, some returned an unexpected error, and some ended the transaction outright.
We even saw some transactions end with 96 (System Malfunction) or 50 (a Not Supported scenario behaving like a generic error). In other words, while we were sending the message “we can continue” on the issuer side, the other side interpreted it as “transaction failed.”
What we noticed at that point was this
This job does not end with simply returning the right response code.
Because we had done the right thing. We had returned 70. We had implemented the flow Visa described exactly. Yet we were still not getting the same result everywhere in the field.
This led us to a much more fundamental point. The problem was not in the card, and it was not on the issuer side either. The problem was actually somewhere broader, that is, within the ecosystem.
The problem is not in the card, it is in the ecosystem
A contactless transaction is not actually a one-sided process. The card, the issuer, the acquirer and the POS device are all parts of a system that works together.
You may have produced the right thing on the issuer side, but if there is no structure on the other side to understand it, the result can change. Especially in overseas transactions, outdated kernel versions on some POS devices, differently implemented response code mappings, or implementation gaps on the acquirer side directly affect this type of problem.
This causes the same transaction to work smoothly in one country and end completely differently in another. Even if everything looks technically correct, behavior can differ in real life.
Why issuer-acquirer alignment is critical
At this point, a reality we often see in payment systems comes back to us. Both sides may be doing the right thing on their own, but that does not mean they will work together smoothly.
As an issuer, by returning 70 we actually set up the correct flow. But we saw that some acquirers did not handle this code correctly. The POS device treated this code as an error instead of a redirect to PIN and ended the transaction.
As a result, the same card and the same behavior produced completely different customer experiences. In Europe the transaction continues with PIN, while in another region the customer may run into an error.
What is the difference between 65 and 70, really?
This is how I clarified this topic in a simpler way for myself.
65 basically means “we are closed.” The transaction ends here and does not continue.
70, on the other hand, means “the door is open, but you must show ID to come in.” In other words, the system wants to continue processing but adds a verification step.
By using 70, we try not to cut the customer off from the transaction. But if the other side interprets it like 65, that is, if it still behaves as if “we are closed,” the whole flow you built loses its meaning.
So what is the solution, is switching to 70 enough?
Short answer: it is not enough.
Switching to 70 is the right step and is something that should be done anyway. But from this point on, things largely slip out of your control because the other side’s behavior comes into play.
From here on, what needs to be done is a somewhat more operational process that requires somewhat more ecosystem management.
First, you need to correctly identify where the problem occurs. It is important to clearly establish in which country, at which acquirer and on which POS devices this behavior is seen.
Then you need to analyze how transactions returning 70 end up. You need to separate which transactions enter the correct flow and which fall into unexpected results such as 96 or 50.
With this data, the issue needs to be taken to Visa. Sharing the affected acquirer bank and the POS behavior clearly, and having Visa assess the compatibility of these structures, is the most critical step.
After this process, actions such as POS or kernel updates and response code handling improvements usually come into play on the acquirer side, and the real lasting solution emerges there.
In other words, most of the time the solution is not making more changes on the issuer side, but bringing the acquirer side closer to the right behavior.
Conclusion
70 is a correct approach and one of the most meaningful methods for moving to PIN in the contactless world. But it is not a magic solution on its own.
There is a truth we see again and again in payment systems. Doing the right thing is not enough; you also need to manage how that right thing is understood on the other side.
The hard part of the job begins right here. Because you are no longer just solving a technical problem; you are also managing how different systems, different countries and different implementations work together.
But frankly, this is also the most instructive and most enjoyable part of the job.
