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 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

    • 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

  • https://docs.payengine.co/payengine-developer-docs/getting-started-1/3.-securing-embeddable-uis