Here are some points that I came across while doing the integration and I think might need to be considered.
1. Signature verification failed
When polling the system to check for payments, I kept getting “Signature verification failed” for some time although I was pretty sure that the signature was correct! After some debugging time, I started to think of what could be an unexpected cause. It turned out to be the last thing I expected.
As you know, the signature is represented as a string with a large hexadecimal number; 64 digits. My code was using some standard .Net functions that returned the signature using upper case digits (ABCDF) while the API is expecting a hex string with lower case digits (abcdef).
So, the valid signature:
was rejected while this one:
was accepted, although it is the same hex number.
Since hex numbers are the same regardless of the case of the digits, I think we should either make the comparison case-insensitive or state it clearly in the API usage guide that the API expects lower case hex digits. This will save developers a lot of time.
2. Double Payment (not double spending)
When you have a successful payment with some payment id, you can scan the same QR code again from the App and send the same payment again with the same payment id. It gets accepted and processed.
Although this is not the fault of the API, I think it might cause a lot of trouble and support issues in life retail environment. More often than not, for some reason a customer will think the payment did not succeed, will scan the code again and the amount will be deducted twice, or even more! Or the customer will scan the wrong code, or due to a bug, the POS software will display an old code of a previous transaction. The possibilities are endless.
It would be great if the API will validate the payment request coming from the App to make sure that this payment has not been paid before. This will eliminate a lot of issues. Of course the payment id should be unique only on the vendor level or whatever.
3.Payment Id Uniqueness
This one is not an issue but might be considered as “nice to have”.
In more complicated retail environments with many physical stores with each store containing maybe tens of points of sale, it will be very difficult for people to generate a globally unique (and meaningful) payment id.
They might generate it from random numbers, or invent a local structure for the payment id string like the first two characters denoting the store, then 2 or 3 chars denoting the POS then a serial for the transaction? Or they will need to be connected to a central server where these payment ids are centrally managed (And this will be unacceptable in most cases, plus POS machines need to work even if the LAN is not available).
In all cases, it will be the responsibility of the retailers to generate unique payment ids, and I assure you, conflicts will occur much more than you might expect.
One idea to make their lives easier, is to add an additional field to the payment string and the payment checking request. It might be called PosId or whatever. And the payment id should be unique only for every POS which is way easier for them to achieve.
Since in retail environments, each POS normally have a unique id, this will make the developer’s lives much easier and will eliminate a lot of problems. A retailer will only need to number their points of sale from 1 to even 10000, and forget about duplicate payment ids forever.
What do you think?!
4.Dual screen availability
This one is not actually related to the API but, I thought I can mention it here, maybe someone comes up with a good idea.
Most of the retailers will not have dual monitors attached to the POS. They will have a hard time generating a dynamic QR code and showing it to the customer. Any ideas?! Use their mobile phones somehow?
Sorry for this lengthy post and thank you for reading.