Who this section is for

Developers validating their Onboarding-as-a-Service integration before going live. This page covers what test keys do, what mock data to expect, and what behavior differs between test and live.

Test secret keys

All Onboarding-as-a-Service endpoints accept a test secret key (sk_test_…). Test calls hit the same API surface as live but return mock responses, so you can validate request and response shapes end-to-end without creating real accounts.

Authorization: Basic <base64-encoded(sk_test_yourKey)>

Find your test secret key in the PayMongo Dashboard under Developers → API keys. Test keys are scoped to your account — your test data is isolated.

What test mode returns

Validating each step

Create

Confirm your handler:

• Persists the returned org_* ID.
• Stores activation_status and identity_verification_status.
• Handles idempotency on retries.

Identity verification

For hosted identity verification in test mode, PayMongo serves a sandbox microsite where you can simulate passed and failed outcomes without taking real photos. Use this to exercise both branches of your UI.

For API-only identity verification in test mode, post any HTTPS-accessible images. Test mode does not run real liveness or document checks; the outcome is determined by deterministic rules that you can use to force passed or failed. Contact [email protected] for the current test-mode simulation reference.

Update

Update validation is identical to live. Use this step to:

• Verify your enum value mappings (industries, states, source of funds, nature of work). See the Appendix.
• Validate that you collect every required-at-activation field before calling Activate.
• Exercise partial-PATCH behavior.

Activate

In test mode, Activate does not go through manual risk review. It either succeeds (and emits merchant.activated / consumer.activated) or fails with a parameter_required listing missing fields.

Use this to:

• Confirm your handler reads the activation webhook and marks the child as ready.
• Confirm your retry loop on missing-field errors.
• Verify that you persist any keys returned in the activation event.

Webhooks

Register a webhook endpoint with a test key to receive test events. Use the Dashboard's webhook log to:

• Inspect delivered events.
• Manually re-deliver an event to test idempotency.
• Confirm signature verification works end-to-end.

Sandbox limits and caveats

• Sandbox mode for identity verification livemode flag. Today, identity verification webhooks carry livemode: true regardless of the key used. Sandbox flagging for identity verification events is on the roadmap; for now, treat the source of the event (test webhook endpoint vs. live) as authoritative.
• Manual risk review. Test mode skips manual review entirely. The first time a live activation goes through review, expect a longer turnaround than test.
• Capability provisioning. Test mode does not provision capabilities that require external onboarding (for example, card acceptance). The capability appears in features, but the live equivalent goes through scheme onboarding.

Going live

Before flipping to your live keys:

• All five steps of Quick start pass end-to-end in test.
• Webhooks are registered on a live endpoint and signature verification is wired up.
• You have a plan for declined activations — error path in your UI and an internal review process.
• You have a plan for missing-field activation errors — your Update + Activate retry loop is in place.
• You have requested any opt-in features you need (Auto-configuration, Partner Verification, Account capabilities) for the live account.
• You have switched the Authorization header in production to your live sk_live_… key.

Related

• Quick start
• Onboarding webhooks
• Troubleshooting
• Authentication