Partner Certification
This certification suite provides a list of all required integration, validation, and sanity test cases to verify partners' portal integration.
Test cases are only applicable if a feature is integrated or implemented. For example, if a partner is not integrating 3DS then all 3DS test cases are considered āNot Applicableā.
API Documentation - http://docs-api.payengine.co/
Pay Engine Developers Documentation - http://docs.payengine.co/
Test Data - https://docs.payengine.co/payengine-api-reference/transactions/testing
Onboarding Validation
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
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.
Credit Card Payment
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.
Credit Card Refund
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
If using Credit Card 3D Secure
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 3D Secure developerās guide.
Test case 1 - 3DS Integration sanity check
Test 1.1 -
/api/sale
requests haveattempt3DSecure
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.
Test 2.2 - 3DS Sandbox Validation . For following test cases, use the appropriate test cards listed in this testing page
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.
ACH Payment
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.
ACH Refund
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
If using ACH with Plaid
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.
If using this platform to track Offline Payments
Offline payments are recorded by calling /api/payment/offline
https://docs.payengine.co/payengine-api-reference/transactions/record-offline-transaction/offline
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
Webhook Validation
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.
For detail informaion please see our developer's guide Build a webhook endpoint
Test case 1 - Send a health check event
Expected result - HTTP 200 within 3 seconds.
Security Review
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
Last updated