Last time, I wrote an article titled “Do you not want to know the principle behind payment code with a simple sweep?” I thought this kind of article would not be read, but after it was released, I did not expect that the reading data was good. So today little black brother to talk to you about payment.

Although our mainstream payment method is alipay/wechat payment, when our balance is insufficient or we choose to deduct from the bank card, we will use the bank card payment.

So today we will talk about the related principles of bank card payment, popular science about the whole process of bank card payment.

Bank card payment can be divided into online payment and offline payment. The classification of offline payment is relatively simple, that is, when we shop in the mall, POS machine swipes the card to pay.

And online payment classification is more, according to the bank card category, can be divided into credit card payment and debit card payment. According to the payment behavior, we can divide it into quick payment, e-bank payment and Token payment.

Today we are going to talk about quick payment and online bank payment, which are two popular ways at present. Other ways, we can talk about that later.

E-currency payment

First, let’s talk about e-bank payment, which was the most popular online payment method 10 years ago.

Let’s take e-commerce shopping as an example. After placing an order on the website, choosing a bank card to pay usually leads to a cashier page. Then on the cashier page, we select the relevant bank and click on the bank to pay. Finally, we will jump to the corresponding bank page.

This cashier page may be the page of the merchant or the page of the payment institution, which is related to the online banking payment docking mode.

After jumping to the bank page, we first need to download according to the bank security control, so that we can enter the relevant information of the bank card. Secondly, we also need to use the security equipment provided by the bank, such as USB shield, token, token code and so on.

After successful payment on the bank website, you can click back and jump back to the e-commerce website synchronously. The whole process is as shown in the picture below:

Background payment process is as follows:

It can be seen that the whole link of e-banking payment is very long, and failure may occur at any step, so the success rate of payment is not very high. In addition, some bank online banking pages can only be opened in IE, and there may be a very old VERSION of IE. In addition, in order to ensure the security of online banking payment, it is necessary to use U shield and install security plug-ins.

This process is still very complicated to tell the truth, I still remember that when I used a line of online banking to recharge and buy yellow diamonds, I did not succeed in the afternoon, and all kinds of certificates failed to install what. My first online recharge ended in failure.

Thanks to some action I saved 10 yuan pocket money ~

Quick payment

Quick payment refers to that users provide card information to e-commerce merchants and other merchants will transfer the card information to payment institutions in the background for binding. Once the binding is successful, the next payment does not require the user to provide the card number and other information.

Or take e-commerce shopping payment as an example, the first payment, need to go through the card binding process.

After successful deduction, you can check the binding record between the card and the payment institution by going to the bank APP.

In previous times, when placing an order and paying on the e-commerce website, the e-commerce website has kept records, so there is no need to input card information. The previous payment process is as follows:

The figure above shows the case that verification code is also required in the previous payment process, which can actually achieve a certain amount of secret-free payment.

Quick payment interfaces can generally be classified into two categories:

  • Contract/payment
  • Withholding payment

Contract/payment

Signing/paying requires two steps:

  • Signing application/signing verification
  • pay

The signing process requires the input of bank card information, bank card number, account name, ID number, mobile phone number, and perhaps CVV2 and expiration date for credit cards. This process basically is to authentication authority, check the correctness of bank card information.

Once the verification is successful, SMS messages will be sent. Users backfill SMS, on behalf of the agreement to open the fast payment, the establishment of binding relationship. After successful binding, the payment agency will return the agreement number to the merchant.

During the payment process, the merchant can take the agreement number to deduct money.

The whole background process is as follows:

Withholding payment

The process of withholding payment is relatively simple compared with signing/payment. Every time you send your bank card information directly, you can directly deduct the money. In principle, the whole process of withholding payment can be made without secret payment, that is, verification code is not required to complete the deduction.

The process is relatively simple, please refer to the quick Payment payment process for details.

Compared to the signing/payment process, withholding payment seems to be faster, but this method has greater security risks than signing payment, which may lead to the phenomenon of swiping. Originally, the withholding interface should have been applied to water, electricity and coal deduction scenarios, but in the development process, it was once used for financial payment scenarios.

These interfaces are slowly being phased out and replaced by new business delegation interfaces (similar to signing/paying).

Although the quick payment payment experience is good, the whole process does not need to jump to the bank page, the payment process will not be interrupted, and the payment success rate is high.

But ease of use and security are always at odds. Because of this process, users provide merchants with information about their cards, which, if stolen, could lead to money being stolen. In addition, quick payment, mobile phone verification code may be the last line of defense, if the phone is lost, then bank card funds may also be stolen.

Bank payment related issues

Generally speaking, the whole process of connecting the bank card payment channel is not very difficult. It is nothing more than splicing parameters according to the interface document, and then doing some corresponding debugging. But there are a few things to note about this process.

Add/check

Generally, bank card payment is transmitted through the Internet. In order to prevent the packets from being changed in a series, encryption algorithms such as RSA2 and National secret are used to encrypt the packets to obtain the signature string and then send it together to the payment institution.

The payment agency will conduct the corresponding visa inspection. If the visa inspection fails, the payment request will be rejected, which can effectively ensure that the payment request is initiated from the legitimate merchant. So for merchants, we must keep the corresponding public and private keys, do not leak at will.

In addition, the payment institution will also sign the response information of the payment request or the asynchronous notification of the e-bank result. Merchant end must be checked, only through the check can proceed to the next step.

The transaction cannot proceed without a signature, so this step will definitely be done.

But if you return a message and you can process a message without doing a check, that might be ignored.

When I first connected with the relevant payment channels, I didn’t check the visa because it was too troublesome. Now think about it, really heart big…

Final decision

For the synchronous interface such as quick payment, we need to determine whether the request is successful for the payment interface request response message according to the response code returned by the interface. Some interfaces may also return response codes and payment status, so we need to judge based on the combination of the two.

This process does not mean that everything except the successful response code is a failure. We need to classify them according to relevant interface documents. Some error codes, such as insufficient balance and incorrect card elements, can be clearly classified as failure.

However, for example, some processing, or system exceptions and other return codes, such as failure or success is not clear, we can not set it as failure, we need to combine the payment query or asynchronous notification results, and then do the processing.

For such synchronous interface as e-bank payment, this kind can only wait for asynchronous notification on the channel side. Generally speaking, the channel side will only be notified of successful payment orders.

This is according to the channel side interface documentation.

Generally speaking, the channel asynchronous notification interface, if the channel side asynchronous notification does not return a successful response, the notification will be repeated until a certain number of times or a successful response is received.

Therefore, after receiving the asynchronous notification, the success response code can be returned to the channel end only after the internal logic processing is successful. This allows the internal logic to be processed again through asynchronous notifications even if it fails.

Also note the idempotent nature of the internal processing logic.

Request parameter correlation

Pay the amount

The request process must pay attention to the unit of payment in the interface document, whether it is minutes or yuan. If you do not pay attention to the unit, it is likely to cause less, more.

For successful response information, we also need to take care to verify that the amount sent is consistent with the amount deducted (if any). If not, ** must not update the order as successful, ** timely manual intervention check.

Finally, after the launch of the payment channel, we need to do some real deductions, such as a small amount of 0.1, the channel maximum amount test. After successful deduction, check whether the real amount of deduction of bank card is consistent with the amount sent in time even.

See below for reasons.

Request Serial Number (Order No.)

In addition to the payment amount, we also need to pay attention to the unique request sequence number/order number, use a unique ID as the request sequence number, do not use time stamps and other methods.

For duplicate serial numbers, if unsuccessful, duplicate payments are allowed. If successful, no further payment is allowed. But there are also some institutional interfaces that have not done this part of the verification.

Cite a pit he waded into, a tens of thousands of lessons. Before the pair took over the system of a bank, when testing for convenience, they directly used the time stamp as the serial number.

I didn’t find this problem in time when I went online. One day, two orders with the same serial number were generated in the same second and sent to the bank. Then the other party returned that both payments were successful, but when checking accounts the next day, it found that only one order had been received. Fortunately finally recover this capital through artificial, otherwise sold me at that time, also cannot afford to compensate…

Although the bank side of this example is certainly a problem, not reprocessing, but as long as we do a good job of unique sequence number logic, can also avoid the problem.

Real sad example

The above attention to the problem chat so much, actually want to attract the attention of the docking channel technology students. Do not think that payment institutions or banks and other systems are stable, there will be no problems.

After all, the program was written by a human, and one update could lead to a bloodbath.

Therefore, do not trust the stability of the other system too much. What we can do is to do a good job of the stability of our own system and add various parameters to check, so as to reduce the occurrence of risks as much as possible.

To give you some painful examples:

Once docking a bank, small test, completely no problem. But when we test the limit, let’s say the limit is 1000 yuan, and when we test 1000.01, it makes sense that the payment should fail.

But the deduction was successful, and a check of the bank’s deduction record showed only 0.01.

Seeing this, do you have a lot of question marks?? Quota overflow has occurred…

Alas, this kind of problem, can only emergency offline channel, and then wait for the bank side repair.

Finally, a few more examples from the Internet about payment loopholes.

Address: wooyun.js.org/drops/

conclusion

Today we mainly talk about two mainstream modes of bank card branch payment, quick payment and online bank payment.

Fast payment is now the most mainstream bank card payment method, because the user experience is the best, the payment process is not easy to be interrupted. However, this mode is relatively less secure. But now the payment institutions and banks will have corresponding risk control means, we do not need to worry too much.

Another quick payment, the general amount is small, usually the maximum amount may only be tens of thousands.

Therefore, for the scenario with a large amount of payment, only e-bank payment scheme can be adopted.

Finally, I talked about some problems in the process of bank card payment docking. Some examples can be integrated into the test cases. Whenever a channel is connected, the case can be executed.

Finally (attention, likes, retweets)

Pay for the series of articles, black brother has been updated several, historical articles can be viewed below related reading.

In the future, Xiao Hei will update several articles, talking about alipay/wechat payment related payment methods, talking about repeated deductions in the payment process and so on.

If you want to know more about payment related topics, please leave a comment in the comments section.

reading

Alipay/wechat Pay payment code principle wechat/Alipay pay related concepts of multi-payment channel routing method balance update step pit experience chat bank-enterprise direct link service those things reconciliation system design scheme unfinished to be continued…

Reference documentation

www.woshipm.com/pd/477150.h…

Welcome to pay attention to my public account: procedures to get daily dry goods push. If you are interested in my topics, you can also follow my blog: studyidea.cn