Skip to main content

Core flow

Every Tazamatch verification follows the below core sequence: submit a verification request and retrieve the result. How you trigger it depends on your use case. Submit Verification → Verification Created → Act on Result
Use GET /v3/verification/payee/metadata to check whether a corridor is supported and see the required fields. This is optional — useful when integrating a new corridor or if you’re unsure of the fields.

Three verification modes

Tazamatch supports three modes depending on how you want to trigger verification in your workflow.

Mode A → Standalone

Verify a payee without creating a beneficiary object. Pass account details directly in the request. No beneficiary is created or modified. When to use: On-demand verification, bulk checks, or when you manage your own payee records outside Tazapay.

Mode B → Inline with new beneficiary creation

Verify at the point of creating a new beneficiary. Pass verify: true in POST /v3/beneficiary. Verification runs as part of the same request, no separate verify call needed. When to use: Verify payees at onboarding time. The beneficiary is created regardless of the verification outcome.

Mode C → Existing beneficiary

Verify a payee already added to Tazapay. Pass the beneficiary_id instead of raw account details. When to use: Re-verify before a high-value payout, periodic re-verification, or verifying a beneficiary added before Tazamatch was enabled.

Retrieving results

To view all verifications for your account, call GET /v3/verifications/payee. Call GET /v3/verification/payee/ to fetch a specific verification.

Key Concepts

Verification states and match types explained

API

Step-by-step integration guide