When a payout bounces, someone pays for it in hours and fees. A typo in an account number, an account the payee closed months ago or a name that belongs to someone else all end the same way: returned funds, a waiting recipient and extra reconciliation work for your team. Tazamatch is the Tazapay tool built for that problem [1]. It tells you whether a payee's account is real and whether the name you hold lines up with the bank's records, and it does so while the money is still in your balance.
Below is a plain-language walkthrough of how Tazamatch works: what it checks, where it slots into a payout, the three ways to run it, how to read what comes back, how to use it from the dashboard or the API, and where it is available.
The point of Tazamatch is timing. Problems get caught when a payee is added to your records, rather than after a transfer has already gone out. Tazapay positions this as a way to cut down on failed payouts, spot suspicious payees sooner and give recipients more confidence, all without slowing your payout process down [2].
A check never moves money. Running Tazamatch sends nothing, holds nothing back from your balance and adds no beneficiary to your account. You simply get an answer to act on [1].
Payouts carry on while checks run. Verification sits alongside your payout operations rather than in front of them, so nothing already in motion is held up [2].
Every corridor answers the same way. Banks in different countries report very different data. Tazapay converts all of it into one standard format, so the rules you build for handling results work wherever your payees are [2].
Use it where it suits you. A check can run as you onboard a new payee, just ahead of a payout, or any other time you want one. Your developers can call it through the Tazamatch API, and your operations team can run it from the merchant dashboard [3][4].
Think of Tazamatch as a checkpoint between onboarding a payee and paying them. The product overview lays the journey out in four stages [1].
Under the hood, each check has the same three beats [5]. You send the payee's account details, Tazamatch opens a verification record with an ID beginning pyv_, and your team decides what to do: pay, review or reject. If you are adding a new country, or you are unsure what a corridor needs, you can first ask Tazamatch whether that corridor is supported and which fields it expects. That step is optional.
How you start a check depends on where it sits in your process, and Tazamatch offers three modes to match [5]. Whichever you pick, you get back a verification record that starts out as pending [3].
Whatever the corridor, a check ends up described by one of a handful of states, plus a match type when the account is found [6]. It opens as pending and then settles into a final state.
The API pages add one more outcome, failed. This is when the check itself could not finish, for example because the provider timed out or returned an error. You are not charged for a failed check [7].
A valid result also carries a match type, which tells you how close the name you sent is to the name the bank holds.
Valid plus no_match is a signal to look closer, not proof of a bad payee. The account is open, but the bank has a different name on file. Tazapay recommends a careful review before you pay. Whatever the result, including a partial_match or no_match, the decision to go ahead with the payout is still yours.
A finished check hands back a verification record. The full list of what it holds is in the API overview, and some corridors return more than others [2][6].
To see what a verification in a given corridor can return, look at its verification metadata [8]. It flags support for account existence, name check, match score, match type, corrected name, translated name and transaction activity.
If Tazamatch is switched on for your account, you can run checks straight from the Tazapay merchant dashboard [4]. There are three things you can do there.
Run a check. Open Tazamatch > Verify Payee, fill in the bank and payee details your corridor asks for, and submit. You see the state and match type on screen. It does the same job as the Create Verification API call.
Look back at past checks. Tazamatch > Verifications lists every check on your account with its state, match type, corridor and time. Open any entry for the full record, including its pyv_ ID and every field that came back.
See what a corridor needs. Under Tazamatch > Capabilities, pick where the money is going, the currency and how it will be paid, and the dashboard shows the fields that corridor requires and what it can check. You only need this when you are unsure.
On the API side, the Tazamatch API guide breaks integration into two main steps, with an optional corridor lookup before them [3].
Before you start (optional): look up the corridor. Send the destination country, plus the currency if you want to narrow it down, to Fetch Verification Metadata [8]. You learn whether the corridor is covered, which bank fields and bank codes it needs, which payee fields it needs (tax ID included), what it can check and its coverage figure. If a corridor is not covered, leave verification out for it.
Step 1: send the check. Call Create Verification in whichever mode suits your process [9]. You get a pyv_ ID back, with the state set to pending.
Step 2: collect the result. Use that ID with Fetch Verification, checking again until the state settles on valid, invalid or not_supported [10]. For a view across all your checks, List Verifications can narrow results by state, match type, destination country, currency, beneficiary, payout rail, date range or a keyword [11].
Let webhooks tell you instead. Rather than checking repeatedly, you can listen for verification webhooks [7]. One event, payee_verification.completed, arrives when a check ends as valid or invalid. The other, payee_verification.failed, arrives when a check could not finish, such as after a provider timeout or error, and carries no charge. Every webhook endpoint you set up receives both unless you turn them off. A not_supported result sends neither, because no check was actually attempted.
Plan for errors. The Tazamatch error codes fall into three groups [12]. The first covers bad or missing inputs, such as the payee type, name, email, phone, destination, country, currency, account number, bank identifier, or fields a particular corridor insists on. The second is a single code for corridors Tazamatch does not cover. The third covers provider-side trouble: rate limits, outages or an internal fault. For that last group, wait a moment and retry, and reach out to [email protected] if it keeps happening.
Tazamatch is available in 50+ corridors, with more being added, and what it can do differs from country to country [13]. The table shows, market by market, whether the name is checked, whether the bank's name for the account holder comes back to you, and the coverage figure Tazapay publishes.
Next on the roadmap. In Asia Pacific: China for business accounts, Hong Kong, the Philippines, Singapore and Taiwan. Turkey is next in Europe, and Canada in North America.
Countries ask for different bank and payee details. You can pull them per corridor from Fetch Verification Metadata, or use the table below, which carries the same information [8].
A few markets come with conditions. In China, only personal accounts can be checked for now, with business accounts planned. India is covered through two corridors: IMPS, which reaches every live IMPS member bank, and UPI. Poland works for business accounts only. Nepal sends back the account holder's name only on a strong match, and Uruguay sends it back partly hidden.
Five markets need a tax number. Saudi Arabia takes the National ID for a person or the Unified Number for a company, and also partly hides the returned name. Brazil takes a CPF for a person or a CNPJ for a company. Chile needs a RUT, Colombia a NIT and Ecuador a RUC. In Bangladesh and Bulgaria, reach is still limited, and Tazapay is working to widen it.
