I have written an article on how to connect to third-party payment and how to efficiently connect to third-party payment . Because most of the connections are overseas payment companies, these companies have many magical problems and often bury them, so before development, sort out a list of problems , In order to find and solve the problem as soon as possible, and ensure that it is online on time.
Questions are as follows
1. Payment
a. With the same order number, before the payment is successful, can the order number be used to initiate payment requests repeatedly?
b. Can the same order number be guaranteed to be successfully paid only once?
c. Are there other restrictions in the payment process that cause the payment to fail? For example: region, ip, etc.
d. Whether to support setting the url address of synchronous/asynchronous notification when requesting
e. The third party needs to set the order expiration time when requesting support
f. Does the data requested for payment need to be signed, what are the signature rules, and if not, how to prevent the data from being tampered with?
g. Can you provide credit or debit cards for user testing?
2. Synchronous/asynchronous notification
a. Is the result of the synchronization notification credible? Do you need to check the payment result once when the notification arrives? The check result shall prevail
b. Whether there is a time delay between the queried transaction status and the actual status of the transaction (for example: after the user pays, we will immediately query whether the consistent result will be obtained)
c. Asynchronous notification strategy, the time interval of notification, the number of notifications, the conditions for triggering asynchronous notification
d. Whether the notification data contains the transaction number, that is, the unique identification of a transaction in the third-party system, and the type of notification field (transaction success notification/refund success notification/other notifications)
e. For asynchronous/synchronous notification, how to judge whether the payment is successful and whether there is a pending state (the state that can be shipped out of the library)
f. Which method of synchronous/asynchronous request is GET/POST, and the method of data transmission is json/xml/formdata
g. Is the data returned asynchronously/synchronously signed, and how to verify it? If not, how to ensure that the data is safe and not tampered with?
h. Is there a risk control process? How long is the time interval? How to solve the loss after delivery after receiving the notification of success or failure if the interval time is exceeded?
i. Which status can be considered as a successful payment?
j. Whether the processing failure will block
3. Inquiry
a. Whether to support order status query, through our order number or third-party transaction serial number
b. Whether to support the query of the status of the refund order, if not, how to check whether the previous refund was successful, mainly used to detect whether the refund will be repeated
c. Are the inquiry of payment order and the inquiry of refund order isolated? For example: If the payment order is successfully paid, regardless of whether the order is refunded or not, the query status is that the payment is successful, and the refund status needs to be obtained through other interfaces
d. Does the interface have signature-related security measures, and if not, how to ensure security?
e. The amount of the query will not change due to changes in the transaction status
4. Refund
a. Whether partial refunds are supported and whether the refund interface contains a unique refund order number indication. For the same refund order number, a third party must ensure that it does not exceed the refund and does not repeat the refund. Whether the refund is an idempotent operation.
b. Refund interface, just call the refund interface directly, or there will be asynchronous notification after calling the refund interface
c. Refunds need to be refunded the same way, confirm the refund time limit and refund period
d. Are there any restrictions on refunds? For example, how long does it take for a certain payment channel to refund before payment, a certain channel does not support partial refunds, etc., and whether there are restrictions on the number and frequency of partial refunds.
e. Refunds must only be made by Xiaomi Mall through the interface or manually in the background, and cannot be refunded directly by the user upon application
f. If the refund amount in the third party is insufficient, how will the third party deal with it? In theory, it should automatically retry when funds are sufficient
g. If it is a card payment, can the user directly apply for a refund to the bank? If so, how to deal with this part of the process?
5. Reconciliation/settlement
a. Obtain the complete transaction records of the third party the day before on T+1 day, provide api or ftp
b. Whether to provide the details of the settlement statement: the details of each fund settled to mi.com, which transactions constitute, and the handling fees charged by the third party, the resulting rate, etc.
c. After the transaction is generated, the data of the statement should not change the value of each field. For example, after a partial refund of a transaction, its payment transaction amount should remain unchanged.
6. Online configuration
- How long does it take to configure an online account
- What information is needed to configure an online account, and whether there are special requirements for this information
7. How big is the qps supported by the payment system
a. The qps of regular system payment
b. Whether large-scale events need to communicate in advance, and estimate transaction-related values
c. The deployment location of the other party's service
8. Development & Testing
a. The development stage needs to provide a complete test environment and test account
b. Test how to simulate various scenarios
At last
If you like my article, you can follow my official account (Programmer Mala Tang)
My personal blog is: https://shidawuhen.github.io/
Review of previous articles: