iValidate
What is iValidate
iValidate is a function provided by Alipay sandbox to help you check the correctness of your integration process and improve the integration efficiency. By analyzing the logs of your API call in sandbox, iValidate can automatically diagnose whether your integration satisfies the requirements suggested by Alipay.
By now, iValidate supports the following iValidate cases. By running iValidate, you can check whether your system properly handles the corresponding scenario.
In-store payment
Barcode payment
Case-001 Direct payment
This is the most typical payment case where, with a scanner to scan the customer's payment code, the payment succeeds without validating the customer's payment password. By running an iValidate test, you can check whether your system can properly handle the payment without a password entered.
Case-002 24-digit barcode payment
When dealing with the payment, some Alipay users might present a 24-digit barcode. By running an iValidate test, you can check whether your system can properly handle the 24-digit barcode.
Case-003 Payment with password authentication triggered
Sometimes Alipay users might be asked to enter the password to complete the payment. By running an iValidate test, you can check whether your system can properly handle the payment with a password entered.
Case-004 Payment expires
Sometimes Alipay users might choose not to continue when they are asked to enter the password to complete the payment, and the payment finally expires. This test case is to check whether your system can properly handle the payment expiration.
Case-005 Payment failed with SYSTEM_ERROR returned
SYSTEM_ERROR is returned when a payment request goes wrong. This test case is to check whether the system can handle the SYSTEM_ERROR according to the best practices recommended by Alipay.
Case-006 Payment timeouts
A payment request might timeout because of poor network or Alipay system error. This test case is to check whether the system can handle timeout errors according to the best practices recommended by Alipay.
Case-007 Cancel succeeds after multiple attempts
When a cancel fails, the merchant must keep calling CANCEL until the cancel succeeds. This test case simulates the scenario where cancel finally succeeds after multiple attempts.
Case-008 Cancel fails after multiple attempts
When a cancel fails, the merchant must keep calling CANCEL until at least more than 3 FAILs are returned, or until cancel requests keep failing for more than 10 seconds. If cancel still fails, the responsible person must be notified of the problem. In production environment, technical support must be contacted to confirm the transaction status and handle the problem.
Case-009 Query succeeds after multiple attempts
When a query fails, the merchant must keep calling QUERY until the query succeeds. This test case simulates the scenario where cancel finally succeeds after multiple attempts.
Case-010 Query fails after multiple attempts
When a query fails, the merchant must keep calling QUERY until at least more than 3 FAILs are returned, or until reque requests keep failing for more than 10 seconds. If cancel still fails, the responsible person must be notified of the problem. In production environment, technical support must be contacted to confirm the transaction status and handle the problem.
Merchant QR code
Case-001 Async notification handling on payment success
Alipay sends async notifications to the merchant after a successful payment. The async notification page (notify_url) must print "success" (without quote) after the notification is received. This test case is to check whether the merchant system can correctly handle the async notification.
Transaction QR code
Case-001 Successful payment
This test case is to validate whether the merchant system can properly handle the transaction in the scenario that a customer scans the transaction QR code and then pays successfully.
Case-002 Cancelled payment
This test case is to validate whether the merchant system can properly handle the transaction in the scenario that a transaction QR code is created but the customer fails to pay.
Case-003 Transaction QR code refreshed
This test case is to validate whether the merchant system can properly handle the transaction when the ECR refreshes the transaction QR code before the customer pays.
Case-004 Cancel succeeds after multiple attempts
When a cancel fails, the merchant must keep calling CANCEL until the cancel succeeds. This test case simulates the scenario where cancel finally succeeds after multiple attempts.
Case-005 Cancel fails after multiple attempts
When a cancel fails, the merchant must keep calling CANCEL until at least more than 3 FAILs are returned, or until cancel requests keep failing for more than 10 seconds. If cancel still fails, the responsible person must be notified of the problem. In production environment, technical support must be contacted to confirm the transaction status and handle the problem.
3rd party QR code (create interface)
Case-001 Successful payment
This test case is to validate whether the merchant system, after calling the create interface of the third-party merchant QR code payment solution, can properly handle the transaction when a customer pays successfully.
Case-002 Cancelled payment
This test case is to validate whether the merchant system, after calling the create interface of the third-party merchant QR code payment solution, can properly handle the transaction when a customer fails to pay.
Case-003 Cancel succeeds after multiple attempts
When a cancel fails, the merchant must keep calling CANCEL until the cancel succeeds. This test case simulates the scenario where cancel finally succeeds after multiple attempts.
Case-004 Cancel fails after multiple attempts
When a cancel fails, the merchant must keep calling CANCEL until at least more than 3 FAILs are returned, or until cancel requests keep failing for more than 10 seconds. If cancel still fails, the responsible person must be notified of the problem. In production environment, technical support must be contacted to confirm the transaction status and handle the problem.
3rd party QR code (pre-create interface)
Case-001 Successful payment
This test case is to validate whether the merchant system, after calling the create interface of the third-party merchant QR code payment solution, can properly handle the transaction when a customer pays successfully.
Case-002 Cancelled payment
This test case is to validate whether the merchant system, after calling the create interface of the third-party merchant QR code payment solution, can properly handle the transaction when a customer fails to pay.
Case-003 Cancel succeeds after multiple attempts
When a cancel fails, the merchant must keep calling CANCEL until the cancel succeeds. This test case simulates the scenario where cancel finally succeeds after multiple attempts.
Case-004 Cancel fails after multiple attempts
When a cancel fails, the merchant must keep calling CANCEL until at least more than 3 FAILs are returned, or until cancel requests keep failing for more than 10 seconds. If cancel still fails, the responsible person must be notified of the problem. In production environment, technical support must be contacted to confirm the transaction status and handle the problem.
Online payment
Website payment
Case-001 Payment success
This test case is to check whether the parameters passed to create_forex_trade interfaces are in compliance with the financial regulation requirements.
Wap payment
Case-001 Payment success
This test case is to check whether the parameters passed to create_forex_trade_wap interfaces are in compliance with the financial regulation requirements.
App payment
Case-001 Payment success
This test case is to check whether the parameters passed to mobile.securitypay.pay interfaces are in compliance with the financial regulation requirements.
How to use iValidate
Before using iValidate, you must have an Alipay merchant account. If you don't have one, go to Alipay portal to sign up. To use the iValidate function, see iValidate guide for details.
The following video explains how to create an Alipay merchant account:
iValidate guide
By now, Alipay sandbox provides 5 test scenarios. Refer to the following step-by-step guide for details:
The process of using iValidate for cases in each scenario are similar. We take the Case-001 Direct payment case in Barcode payment as an example.
Scenario description
This test case applies to a scenario where the payment succeeds by scanning the customer's payment code with a scanner, no need to validate the customer's payment password. The checkout terminal presents a successful payment status and the payment receipt (if any) can be printed out successfully.
Integration test goal
Implement the integration test to check whether your system satisfies the following two items:
1. The status of the transaction in Alipay server is TRADE_SUCCESS.
2. store_id and secondary_merchant_id parameters are passed in the request message.
Integration test steps
1. Leave the checkbox unselected to ensure that the password authentication switch was turned off, and click Next.
2. Create a payment request from your checkout terminal, use your scanner to scan the payment code of your test buyer account, and complete the payment successfully.
3. Ensure that the payment status shown on your checkout terminal is success and the payment receipt (if any) can be printed out correctly, then click Next.
4. Fulfill the partner_trans_id of the transaction, and then click Check. The iValidate function can then analyze and check your transaction request and data status.
5. The iValidate function collects related data, processes the corresponding calculations, and in the end delivers a test result.
a. If the result is Case passed, it means your integration system satisfies the integration test goal.
b. If the Actual result is not found, see the Suggestion provided on the screen to make corresponding changes.
