Common Payment System API Errors

If you are going to write an nth payment system, I recommend that you familiarize yourself with the typical errors in the implementation of the API that I collected in the process of writing modules for my project.



1. Anarchy in data formats. For example, the client sends data as key = value, in response receives xml. If you selected xml as the protocol - use it in both directions. For queries and responses, use consistent coding and signing. If you don’t do this, the programmers on the client side will create minimally working code, and not as you planned. I’ll give an example dialogue with the support service of one payment system:

I: guarantee that no store will send you an answer at the final stage of the request

support: it is! because of this, we cannot fix the fact that

I received this request by the client : it’s natural - the client received the information he needs, and giving you a valid answer is to understand the non-standard subtleties of this answer that you invented. Therefore, no one writes code for this

2. A bug when gluing data for signature. It seems that the payment system must definitely be ill with this bug. Typically, the signature is formed as follows: we take all the request parameters, concatenate with the private key and calculate the hash. Suppose, the description field goes in front of the sum in the concatenation order - we remove the first digit from the sum and add to the description. The hash does not change. As a result, we pay for the order with a smaller amount. Interestingly, programmers at first resist to admit it as a bug, and then they say “well, we cannot change the protocol, it is already being used in a big way”. A lot of projects suffer from this disease in various variations:

2.1 gluing with separators and non-filtering of separators in parameters

2.2 The optional parameters in the signature, the problem: the replacement of one parameter to another with the installation of the same value of

2.3 using different actions API with the same set of mandatory parameters, problem: sending a legal request to another API point (for example, after payment to send the same package to reverse)

2.4 discarding invalid optional parameters

3. Inventing your own timestamp - tired of writing your own parser for each system DDMMYYYYYYHHMMSS, YYYY-MM-DDlevysymbolChCh: MM: SS, etc. a lot of options. What does not suit the standard timestamp?

4. Error codes. I understand that your payment system works perfectly and for the error codes you have provided only errors on my side. Please provide the error code “incorrect data from the payment system”, which client code

5 can respond to . Since your protocols are not transactional, provide a mechanism for processing duplicate requests. At least describe in the documentation what you need to answer in this case.

6. Undocumented and, as a result, insecure API methods. Usually they do not verify the signature, ip verification, etc. The secret will sooner or later become apparent - programmers often do not stay at one place of work and merge something like this for a beer:

- Estimate, and ATMs went to us without verification of the signature, because they were broke to change software at thousands of ATMs.

7. Awful documentation - you have to jump like a grasshopper throughout the document until you understand how it works. Although ..., this is a common problem of any project

8. Do not give bad examples: do not give a simplified example in the documentation, the code of which provides for the explicit presence of a secret key in the html page - believe me, some of this code will be copied to the sites of their stores.