Partner Certification
This certification suite provides a list of all required integration, validation, and sanity test cases to verify partners' portal integration.
Last updated
This certification suite provides a list of all required integration, validation, and sanity test cases to verify partners' portal integration.
Last updated
API Documentation -
Pay Engine Developers Documentation -
Test Data -
Test case 1 - Application forms are properly displayed/filled during the signup process.
Test case 2 - Application status is properly reflected for merchants while in process.
Test case 3 - Application Messages are properly displayed while in process.
Test case 4 - Information can only be modified when allowed.
Test case 5 - Payment is not enabled until the merchant’s account is activated.
Payment validation test cases are only applicable if partners are supporting specific payment types. For example, offline will not be applicable if only credit card payments are supported through partners' portal.
Test case 1 - Secure form validation
Test 1.1 - All secure fields (PAN, CVV, Card Holder and Expiration Date) are generated using PayEngine.createSecureField method.
Test 1.2 - Secure form is submitted through PayEngine.createCard method.
Test 1.3 - Secure form is not allowed to submit multiple times while processing.
Test case 2 - Payment validation
Test 2.1 - $100.00 (Normal flow)
Expected Result - Should successfully pass
Test 2.2 - $0.20 (Small amount flow)
Expected Result - Should successfully pass
Test 2.3 - $0.00 (Zero transaction flow)
Expected Result - Should fail or prevent submission
Test 2.4 - ($10.00) (Negative transaction flow)
Expected Result - Should fail or prevent submission
Test case 3 - Payment confirmation and failure reporting
Test 3.1 - Payment confirmation is successfully displayed
Test 3.2 - Payment failure is successfully displayed
Test 3.3 - Retry is only available when the previous action was fully completed.
Test case 1 - Refunds are not generic
Test 1.1 - Refunds are only issued against a payment i.e. Transaction ID is always provided.
Test case 2 - Refund amount
Test 2.1 - $0.00 refund (Invalid amount)
Expected Result - Should prevent refund processing
Test 2.2 - More than current available balance in the transaction
Expected Result - Should prevent refund processing
Test 2.3 - Negative Refund
Expected Result- Should Prevent refund processing
Test 2.4 - Positive value less or equal to transaction balance
Expected Result - Should successfully pass
Test 2.5 - Multiple refunds
Expected Result - Should pass as long as conforms to 2.1 through 2.4
Test case 1 - 3DS Integration sanity check
Test 1.1 - /api/sale requests have attempt3DSecure flag turned on.
Test 1.2 - browserInfo is properly collected using PayEngine.collectBrowserInfo Javascript API.
Test 1.3 - 3DS action is properly handled by invoking PayEngine.perform3DSFlow Javascript API when triggered.
Test case 2 - 3DS Process flow validation
Test 2.1 - All tests from “Test case 2” of Credit Card Payment above.
Frictionless 3DS Success
Expected Result - Transaction should be approved without challenge
Frictionless no 3DS Success
Expected Result - Transaction should be approved without challenge
Manual Challenge
Expected Result - 3DS Challenge screen is displayed for manual interaction
Successful challenge response (option displayed) should approve the transaction
Incorrect challenge response (option displayed) should decline the transaction
Automatic Challenge Success
Expected Result - Transaction should be approved after the challenge screen automatically passes the challenge.
Automatic Challenge Failure
Expected Result - Transaction should be declined after the challenge screen automatically fails the challenge.
Test case 1 - Secure form validation
Test 1.1 - All secure fields (First Name, Last Name, Routing Number and Account Number) are generated using PayEngine.createSecureField method.
Test 1.2 - Secure form is submitted through PayEngine.createBankAccount method.
Test 1.3 - Secure form is not allowed to submit multiple times while processing.
Test case 2 - Payment validation
Test 2.1 - $100.00 (Normal flow)
Expected Result - Should successfully pass
Test 2.2 - $0.20 (Small amount flow)
Expected Result - Should successfully pass
Test 2.3 - $0.00 (Zero transaction flow)
Expect Result - Should fail or prevent submission
Test 2.4 - ($10.00) (Negative transaction flow)
Expected Result - Should fail or prevent submission
Test case 3 - Payment confirmation and failure reporting
Test 3.1 - Payment confirmation is successfully displayed
Test 3.2 - Payment failure is successfully displayed
Test 3.3 - Retry is only available when the previous action was fully completed.
Test case 1 - Refunds are not generic
Test 1.1 - Refunds are only issued against a payment i.e. Transaction ID is always provided.
Test case 2 - Refund amount
Test 2.1 - $0.00 refund (Invalid amount)
Expected Result - Should prevent refund processing
Test 2.2 - More than current available balance in the transaction
Expected Result - Should prevent refund processing
Test 2.3 - Negative Refund
Expected Result- Should Prevent refund processing
Test 2.4 - Positive value less or equal to transaction balance
Expected Result - Should successfully pass
Test 2.5 - Multiple refunds
Expected Result - Should pass as long as conforms to 2.1 through 2.4
Partners can optionally integrate with our Plaid API that can help facilitate ACH transactions using Plaid to obtain bank account information i.e. routing and account numbers.
Note: Prior to production launch, make sure you have a live Plaid account enabled.
Test case 1. Plaid integration sanity check (Web-Component)
Test case 1.1 - Web-Component has an id element and right component type i.e. plaidconnect
Test case 1.2 - At least success and error callbacks are handled to receive account or error information
Test case 2. Plaid integration sanity check (Javascript)
Test case 2.1 - Plaid is invoked through PayEngine.connectWithPlaid JS API.
Test case 2.2 - Success and error handling has been implemented.
Test case 3. Execute all Test cases 2 and 3 from ACH Payment section
Test case 4. Production plaid account availability.
Test case 4.1 - Partner’s own plaid account credentials were updated via the partner console.
Test case 4.2 - Partner’s own plaid account has been activated by Plaid.
Test case 1 - Payment validation
Test 1.1 - $100.00 (Normal flow)
Expected Result - Should successfully pass
Test 1.2 - $0.20 (Small amount flow)
Expected Result - Should successfully pass
Test 1.3 - $0.00 (Zero transaction flow)
Expect Result - Should fail or prevent submission
Test 1.4 - ($10.00) (Negative transaction flow)
Expected Result - Should fail or prevent submission
Webhooks are the way this platform notifies partners for certain events so it is important for Webhooks to respond with HTTP 200 within 3 seconds. Multiple failures will result in Webhooks being disabled.
Test case 1 - Send a health check event
Expected result - HTTP 200 within 3 seconds.
Test case 1. Private (secret) key security
1.1 - Private key is only used in server to server communication.
1.2 - Private key is not exposed through publicly available source code or by making direct API calls from client-side application.
Test case 2. Web components have been secured for production environment
3D Secure is not activated by default for any credit card transactions unless /api/sale call enables 3DS by passing attempt3DSecure: true . For integration details please use PayEngine’s .
Test 2.2 - 3DS Sandbox Validation . For following test cases, use the appropriate test cards listed in this
Offline payments are recorded by calling /api/payment/offline
For detail informaion please see our developer's guide