Overseas e-commerce payment gateway avoidance guide

foreword

Hi friends, my name is CrazyCodes

In the last article, I roughly described the basic process of payment system development, but in contrast, although the domestic process is similar, the necessary steps are still complete, and the technical level is relatively high. Not as smooth as we thought.

This chapter still follows the normal process, the basic steps of payment, notification (including synchronous notification and asynchronous notification), inquiry, refund and reconciliation to explain the difference with overseas.

It is recommended to cooperate with the article on the basic process of payment system development to understand the differences

Payment

The above picture is a complete payment process. Compared with the particularity of overseas payment, there are the following points

1. The three-party confirmation payment may not be real-time. The non-real-time representation here is not at the minute level, but may be in hours or days. I don’t know why the delay is so large. It may be the length of the link, or Regarding the level of technological development, of course, this is also in some countries. In more developed countries like the United Kingdom and France, generally speaking, the process is quite normal.
2. For example, the supermarket payment in Taiwan can be understood as an offline payment method. The general process is that after the user places an order on the website, we can only provide the user with a payment code, and the user needs to take this payment code to the offline store to pay. , and finally complete the transaction. In this process of our payment, this method can only complete a pre-payment function, and the payment process is offline .
3. Secondly, we should not trust any system and user operations, not to mention overseas, the recovery of goods or funds is more difficult, so we need to do various verifications. Sometimes overseas three-party systems do not have verification functions, and fraud may occur. We can Add the verification code through the additional parameters provided by the third party (similar to the order description). Of course, if you don't even have this, you can only resign.
4. Finally, the question about the order number is that some third-party system order numbers may not support idempotency, which means that when a user initiates a payment with a certain order number and has not paid, the payment will fail when the order number is used again. In this case, we can use one order number to correspond to multiple transaction numbers to solve the problem, which means that a unique transaction number is generated after each initiation, as a substitute for the order number, to pay.

Notice

Payment is so difficult, so notification is even more difficult, list a few core differences

1. First of all, there may not be any notification , then without any notification, we can only get the payment result through active inquiry.
2. It may also be the lack of one type of notification, the lack of synchronous notification, or the lack of asynchronous notification. Generally, there is a lack of asynchronous notification. If there is a lack of asynchronous notification, if your system thinks that you can fully trust the synchronous notification, you can selectively ignore this defect. Synchronization + active query, I personally think that it can be selectively ignored. If there is no active query interface, it is necessary to ask whether the three-party system can provide an interface for reconciliation. In a word, it is necessary to achieve information symmetry before the payment can be determined to be successful.
3. The last one is the most bizarre, although it is an online payment process, but the three-party system may not have active query interface, synchronous notification, asynchronous notification and reconciliation interface. You are not mistaken, except for one payment, there is nothing. This kind of Under normal circumstances, the three parties will generally provide you with a merchant background where you can manually download the bill, and then you can only verify it by importing the form, which is similar to the domestic bank card conversion or public-to-public.

Refund

After going through complex and changing payments, here are some differences in refunds

1. First of all, there is no refund interface, which means that users can only go to the third party for a refund, and the third party will reflect the status of an order from the statement.
2. The second is that there may be no asynchronous notification of refund, then we can only use active query to verify the order status, which is back to the problem of no interface. If there is no active query interface, we will go to the merchant's background to export it manually. re-import into the system.
3. Finally, there is the most primitive way, called financial payment (meaning there is no automated refund process).

reconciliation

After untold hardships, we finally reached the link of reconciliation. Generally, there are the following differences

1. (Self-seeking and more blessed type) No bills to provide
2. (Self-reliant type) The tripartite system provides a merchant background that can be exported, and the reconciliation is completed by importing the form
3. (Semi-automatic type) There are two types: FTP is provided for downloading the statement, and the other is to send the statement regularly by mail, and the program completes the reconciliation by reading the mailbox.
4. Last but not least, keep the principle of not fully trusting the tripartite system, and be cautious about reconciliation, and try to keep the risk out of the user's payment.

Thanks

Thank you for being here, I hope this article can help you, thank you.