📃
Developer Docs
  • Overview
  • Integration Options
  • Webhooks
    • Build a webhook endpoint
    • Check signature
  • Getting Started
    • 1. Creating User Accounts
    • 2. User Account Types & Permissions
    • 3. Generate Access Tokens
    • 4. Choose Integration Options
    • 5. Securing Embedded UIs
      • 5a. Securing Embedded UIs Using HMAC (deprecated)
    • 6. Loading the frontend library
      • 6a. Preloading PayEngine Web-Component in SPA
    • 7. Custom styling the Web-Components
    • 8. Handling Callbacks from Web-Components
    • 9. Available Web-Components
    • 10. Available Webhooks
  • Merchant Onboarding
    • Overview
    • Integration Options
    • Onboarding/Payments Application Workflow
    • Embedded Onboarding UI
    • Merchant onboarding APIs
    • Partner's Onboarding UI
    • Merchant Lifecycle
    • Onboarding to Partner Relationships
  • Processing Payments
    • Introduction
      • Transaction Flow and Status
    • SecureFields JS
      • SecureFields Bank Account
      • Using tokens
    • Credit Card Form
    • Connect with Plaid
    • Connect Mailgun
    • 3D Secure
    • Payments API
    • Searching Transactions
    • Registering a cloud connected device
    • Apple Pay
      • Apple Pay in your native app
    • Google Pay™
    • Level 2 and Level 3 Data
    • Fraud Prevention
    • Reporting
    • PCI Compliance
    • Address Verification Service (AVS) Check
    • Hosted Payments
      • Embedded Payments Session Integration
    • Tap to Pay
  • Card Account Updater
  • ORCHESTRATION SYSTEM
    • Orchestration Overview
    • Onboarding Orchestration
    • Transactions Orchestration
    • Omnicommerce Orchestration
    • Merchant Servicing
    • Universal Reporting
  • TOKENIZATION
    • Automatic Network Tokenization
    • Token Migration Process
  • DISPUTE MANAGEMENT
    • Retrieval Requests & Chargebacks
  • Certification
    • Partner Certification
  • Data Sharing
    • Secure Data Sharing with PayEngine
  • eCommerce Integration
    • PayEngine Payment Gateway for WooCommerce
Powered by GitBook
On this page
  • Onboarding Validation
  • Payment Validation
  • Webhook Validation
  • Security Review
  1. Certification

Partner Certification

This certification suite provides a list of all required integration, validation, and sanity test cases to verify partners' portal integration.

PreviousRetrieval Requests & ChargebacksNextSecure Data Sharing with PayEngine

Last updated 1 month ago

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 -

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

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

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

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

  • 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

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 information please see our developer's guide

http://docs-api.payengine.co/
http://docs.payengine.co/
https://docs.payengine.co/payengine-api-reference/transactions/testing
3D Secure developer’s guide
testing page
https://docs.payengine.co/payengine-api-reference/transactions/record-offline-transaction/offline
Build a webhook endpoint
https://docs.payengine.co/payengine-developer-docs/getting-started-1/3.-securing-embeddable-uis