Integration Guides
  1. Merchant - PSP Integrations
  2. Merchant Onboarding

Onboarding testing

How to test the merchant onboarding flow end-to-end before you point your production automation at it.

Test your onboarding integration in the sandbox before pointing production automation at it. This page walks through the test merchant lifecycle and the formal acceptance test pack you'll work through with the EFT Corp test team.

For the API itself, see Onboarding overview. For general sandbox info, see Sandbox and test cards.

Get sandbox credentials

Email [email protected] to request sandbox onboarding credentials. Include:

  • Your company name
  • Whether you're a PSP, an aggregator, or an acquirer
  • The administrator email for your sandbox profile

You'll receive:

  • A link to set your sandbox Portal password (expires in 24 hours)
  • Your sandbox PSP ID (if PSP) or acquirer credentials (if acquirer)
  • Instructions to retrieve your API password from the Portal

Sandbox credentials are entirely separate from production. There's no migration step — you'll get a new set of production credentials when you go live.

Build through the lifecycle

Run your onboarding automation against the sandbox end-to-end:

  1. Create a sandbox merchant via POST /portal/restful/merchant/create.
  2. Add a notification URL that points at your sandbox webhook receiver.
  3. Generate the merchant's API password.
  4. (Optional) Generate a Lib Lite token if your merchant integrates the SDK.
  5. Use the merchant's credentials to create a code, simulate a payment using the test cards on Sandbox and test cards, and verify your webhook receiver acks correctly.
  6. Suspend the merchant and verify scans return 434 CLIENT_SUSPENDED.
  7. Unsuspend and verify payments resume.
  8. Update the merchant's URL to confirm updates propagate.

Once you've exercised every step you'll use in production, you're ready for formal acceptance testing.

SIT (System Integration Testing)

After your sandbox build passes self-test, the EFT Corp test team runs SIT with you. They:

  • Verify your test merchant transacts cleanly across positive scenarios (success, partial refund, full reversal)
  • Test negative scenarios (insufficient funds, declined card, expired card)
  • Confirm your webhook handler acks within the 45-second window across realistic latency
  • Validate your idempotency — running the same merchantReference twice fails on the second attempt as expected

SIT is co-ordinated by email and typically takes 2–5 business days, depending on your availability. There's no formal pass / fail certificate at this stage — it's a collaborative sanity check.

UAT (User Acceptance Testing)

UAT is the formal sign-off stage. The acceptance test pack covers two categories:

Branding tests (B1–B20)

These confirm that Scan to Pay is presented to end customers consistently with the scheme rules and EFT Corp guidelines:

GroupExamples
Brand presenceScan to Pay branding on the merchant's checkout page (B1), in the merchant's app (B2), before the checkout page (B3, B4), as a payment option (B5, B6)
App-to-app & USSDApp-to-app call executed correctly (B7), Scan to Pay payment option on USSD menu (B8)
Customer engagementCustomer referred to mobile to authorise (B9), advised to have phone unlocked (B10), info graphics present (B11)
Terms & ConditionsT&Cs present on website (B12), present in the app (B13)
Back-officeScan to Pay keys loaded in Back Office (B14)
NotificationsHTTP notification loaded (B15), SMS (B16), email (B17)
Notification acknowledgementMerchant accepts notification (B18) and acknowledges with HTTP 200 (B19)
Reversal handlingMerchant handles reversal correctly (B20)

Transaction tests (T1–T17)

Test cases covering positive and negative transaction scenarios across debit and credit cards, on-us and off-us:

CardResult tested
Debit (DC)Successful, incorrect PIN (response 55), 3DS, expired card (response 54)
Credit (CC)Successful, incorrect PIN, incorrect CVV (response 05), 3DS, insufficient funds (response 51)
BothCard on/off-us, reversal, partial refund, full refund

Each test case is exercised against the sandbox, results signed off by both your team and the EFT Corp test team. Failed tests must be remediated and re-tested before sign-off.

Acceptance certificate

Once SIT and UAT are complete and signed, the EFT Corp test team issues an acceptance certificate. This is the gate to production access — without it, production credentials won't be issued. See Going live for the cutover steps that follow.

Reset sandbox state

If you need to restart from a clean state (e.g. after a failed UAT cycle), email [email protected] with your sandbox merchant ID. The test team can reset:

  • Transaction history for a specific merchant
  • Sub-user accounts under your Portal profile
  • API password and notification key (alternatively, do this self-serve from the Portal)

Sandbox merchants themselves are not automatically deleted — they accumulate over time. Many integrators keep one sandbox merchant per integration variant (web, in-app, in-store) for ongoing regression testing.

What's next

Updated 3 days ago