# Partner Certification {% hint style="info" %} 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”. {% endhint %} **API Documentation -** **Pay Engine Developers Documentation -** **Test Data -** ### 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](https://docs.payengine.co/developer-docs/processing-payments/3d-secure). * **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. * Test 2.2 - 3DS Sandbox Validation . For following test cases, use the appropriate test cards listed in this [testing page](https://docs.payengine.co/payengine-api-reference/transactions/testing#id-3ds-testing) * 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. {% hint style="warning" %} *Note: Prior to production launch, make sure you have a live Plaid account enabled.* {% endhint %} * **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` * **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 information please see our developer's guide [Build a webhook endpoint](https://docs.payengine.co/developer-docs/webhooks/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** * --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.payengine.co/developer-docs/certification/partner-certification.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.