> ## Documentation Index
> Fetch the complete documentation index at: https://developer.tazapay.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Flow

> The end-to-end verification journey and three ways to trigger Tazamatch

<Warning>
  Tazamatch is coming soon. The APIs listed here are for reference only and are not yet available in production or sandbox.
</Warning>

## Core flow

Every Tazamatch verification follows the below core sequence: check coverage, submit a verification request, and retrieve the result. How you trigger it depends on your use case.

**Check Corridor Capability → Submit Verification → Verification Created → Act on Result**

| Step                         | What happens                                                                                               |
| ---------------------------- | ---------------------------------------------------------------------------------------------------------- |
| 1. Check corridor capability | Call GET /v3/verification/payee/metadata to confirm the corridor is supported and retrieve required fields |
| 2. Submit verification       | Call POST /v3/verify/payee with the payee's account details                                                |
| 3. Verification created      | A verification object is created and a pyv\_xxxx ID is returned                                            |
| 4. Act on result             | Proceed with payout, flag for review, or reject the payee                                                  |

## 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/{id} to fetch a specific verification.

<CardGroup cols={2}>
  <Card title="Key Concepts" icon="gear" href="/tazamatch/overview/key-concepts">
    Verification states and match types explained
  </Card>

  <Card title="API" icon="code" href="/tazamatch/how-to-use/api">
    Step-by-step integration guide
  </Card>
</CardGroup>

***