Typical payment system API errors

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



1. Anarchy in data formats. For example, the client sends the data as a key = value, receives xml in response. If you chose xml as a protocol, use it in both directions. In requests and responses use uniform coding and signing. If you don’t do this, client-side programmers will do the minimum working code, not as you planned. I will give an approximate dialogue with the support service of a single payment system:
')

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

support: it is! Because of this, we cannot fix the fact of receipt of this request by the client.

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

2. Bug when pasting data for signature. It seems that the payment system must necessarily get over this bug. Usually the signature is formed like this: we take all the request parameters, concatenate with the private key and calculate the hash. For example, the description field in concatenation order comes before the sum — we remove the first digit from the sum and add it to the description. Hash does not change. As a result, we pay the order with a smaller amount. Interestingly, programmers first resist admitting it as a bug, and then say, "well, we cannot change the protocol, it is already being used on a grand scale." A lot of projects suffer from this disease in various variations:

2.1 splicing using separators and non-filtering separators in parameters

2.2 optional parameters in the signature, problem: replacing one parameter with another with setting the same value

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

2.4 discarding invalid optional parameters

3. The invention of his timestamp - he got tired of writing his own parser for each system DDMMYYYYHCHMMSS, YYYY-MM-DDD left symbolCHH: MM: SS, etc. many options. Than standard time stamp does not suit?

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

5. Since your protocols are not transactional, consider 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 consequence, unprotected API methods. Usually they do not verify the signature, check on ip, etc. The secret will sooner or later become obvious - programmers often do not stay upstairs at the same place of work, and like this they will merge with beer:

- think for it, and ATMs went to us without checking the signature, because they had to break software to change thousands of ATMs.

7. Terrible documentation - you have to jump like a grasshopper around the document while you understand how it works. Although ... this is a common problem of any project.

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