更改付款資料前，先核對新受益人的 CLABE 姓名

A seller on your Mexico marketplace asks to change the CLABE that receives payouts. If you swap it without checking, the next payout may reach someone else's account. This article shows how a name comparison against supported bank evidence fits that decision. It covers task state, the name_match result, charges and why an inconclusive similarity goes to review. The example is a synthetic contract illustration, not a live check or proof of account control.

The problem and your decision

A payout change request is a high-impact edit. The seller submits a new 18-digit CLABE and expects the next payout to land there. Your team must decide one thing: does the name the bank evidence associates with this CLABE match the beneficiary you expect closely enough to apply the change, or does a person need to review it first? The comparison answers a narrow question. It is not document identity, it does not prove that the requester currently controls the account, and it is not business approval. Your application keeps the old payout details active until its own rule says otherwise.

What the product accepts and returns

According to the product contract, one request carries the CLABE, the expected beneficiary name, the holder type, the current quote, an authorization reference and a stable request UUID. The output is a task state and a name comparison, together with its evidence and charges. Uncertain similarity requires review. A quoted microtransfer may apply to obtain evidence; it requires explicit recipient authority and spending authority. Reuse the same request UUID when retrying so one payout change maps to one task. Merchant execution depends on current capabilities, a valid authorization and the accepted quote. Running a well-formed CLABE format check first avoids spending a paid request on an input that cannot pass.

Hypothetical scenario and expected fixture output

Hypothetical: a seller registered as a company changes payout details, and the expected beneficiary name differs from the evidence name by an abbreviation in the legal suffix. The synthetic contract example returns exactly: status review, name_match inconclusive, verified false, automatic_business_approval false. Read each field literally. status review means the task needs a human decision. name_match inconclusive means the similarity is neither a clear match nor a clear conflict. verified false means nothing was confirmed. automatic_business_approval false means the result never authorizes the payout change by itself. No live provider request is performed by this example, so it demonstrates contract handling only.

Proposed application design

This is a proposal, not implemented behavior. Store the change request as pending with the old CLABE still active. Record the request UUID, the accepted quote and the authorization reference before calling the check. On status review or name_match inconclusive, open a review case showing the expected name, the returned evidence and the charges, and keep payouts on the old details. Only a reviewer or an explicit policy should approve the switch; automatic_business_approval false must never be overridden by code. If a microtransfer is quoted, ask an authorized person to confirm both the recipient and the spend before accepting the quote. Notify the seller that the change is under review rather than rejected.

Failure handling

Treat a timeout or unknown task state as incomplete, not as a mismatch. Retry retrieval with the same request UUID instead of submitting a new task, which could create a second charge. An inconclusive result is not a conflict, and a conflict still deserves review before any account action. If the quote expired or authority is missing, stop and request a fresh quote or authorization instead of proceeding. Record charges exactly as returned, keeping any microtransfer separate from the check fee. Never treat the synthetic fixture as live permission or as evidence that production coverage exists for a given bank.

Acceptance checklist

Before enabling this flow, confirm: old payout details stay active until approval; every request has a stable UUID, holder type, authorization reference and accepted quote; the fixture yields status review, name_match inconclusive, verified false and automatic_business_approval false, and your handler routes it to review; retries reuse the UUID; microtransfers require recorded recipient and spending authority; charges are stored per task; timeouts do not become rejections; review screens show evidence, not just a score; and nobody describes the check as identity verification or proof of account control. Product feedback so far is aggregate observation only and proves nothing about outcomes.

Disclosure: this tutorial was drafted with AI and checked against executable local examples and an independent factual review. Sample values are test inputs, not verified people or accounts. Application policy remains the caller’s responsibility.