Snapshot 1 — payout approval
Situation: submitted route points to the wrong chain for the approved payout request.
Result: DO_NOT_SEND
Operational value: the transfer stops before release instead of becoming support cleanup or manual recovery work.
USDC / USDT payout verification · no custody · pilot from $399/mo
Check stablecoin payouts before funds move.
PayeeProof adds a no-custody verification layer before USDC and USDT payouts are released. Check expected network, asset, and destination, then return one clear operator action — SAFE_TO_SEND, DO_NOT_SEND, REVERIFY, or SEND_SMALL_AMOUNT.
Catch wrong-network payouts
Catch wrong-destination payouts
Create a decision record
USDC / USDT first
Why teams buy
Payout release gatePlace a deterministic verification step before contractor, creator, affiliate, or vendor stablecoin payouts are released.
No custodyYour team keeps approval and execution control. PayeeProof adds verification, not fund handling or transfer execution.
Clear outputSAFE_TO_SEND / DO_NOT_SEND / REVERIFY / SEND_SMALL_AMOUNT gives humans and systems one standard language for action and escalation.
Live coverageEthereum, Arbitrum, Base, Polygon, BNB Chain, and Solana. Public checker supports USDC and USDT.
Built first for payout approval workflows where a wrong network, wrong destination, or ambiguous recipient detail should stop the release.
Reduce payout mistakes before release
Add a verification step where mistakes are still stoppable — before a USDC or USDT payout leaves the workflow.
Keep humans in the control loop
Operators get a simple verdict, a risk level, a destination class, and a next step instead of raw blockchain noise or ad-hoc wallet review.
Create a decision record
Each result is built as a control record your team can reference during approval, exception handling, partner review, and post-incident analysis.
Best first operational fit
Start with payout workflows where mistakes are expensive.
The strongest first rollout is narrow: contractor payouts, creator or affiliate payouts, and stablecoin batch releases. Treasury and recovery can come later after the payout check proves useful.
Primary wedge: contractor payouts
Use PayeeProof at the last operator or system pause before release, where one wrong network or destination detail is still stoppable.
Primary wedge: creator and affiliate payouts
Use REVERIFY or SEND_SMALL_AMOUNT when a wallet is new, changed, memo-sensitive, route-dependent, or operationally ambiguous.
Good second wedge: batch payout release
Add one more control step before a payroll, marketplace, or partner payout batch moves.
Not a first-fit promise
Do not sell the first rollout as a general fraud suite, custody product, recovery service, or support for every network and asset combination.
Representative workflow snapshots
What a useful payout pilot signal should look like.
These are representative workflow snapshots, not named customer testimonials. They show the kind of control signal a narrow pilot should produce before stablecoin payouts are released.
Snapshot 2 — exchange-like destination
Situation: address pattern looks custodial, memo-sensitive, or still depends on venue confirmation.
Result: REVERIFY or SEND_SMALL_AMOUNT
Operational value: the operator gets a clear pause signal instead of vague uncertainty or a false SAFE_TO_SEND state.
Snapshot 3 — clean personal-wallet route
Situation: network, asset, address, and context line up cleanly and the destination looks operationally normal.
Result: SAFE_TO_SEND
Operational value: teams keep approval moving with a readable proof record instead of ad-hoc reassurance in chat or email.
Use cases
Where PayeeProof fits in payout workflows.
The strongest starting point is narrow: contractor payouts, creator or affiliate payouts, and stablecoin batch releases where teams need a final verification gate before release.
Payout ops
Use PayeeProof at the last approval pause before funds move, especially when lean teams handle wallet details manually or semi-manually.
Creator and affiliate payouts
Use REVERIFY when a recipient wallet is new, changed, route-sensitive, or still needs extra confirmation.
Batch payout controls
Add one narrow verification layer before release while keeping final approval and execution with the operator.
Recovery guidance
Keep post-send guidance as a secondary module for cases where something already went wrong and support needs a faster starting point.
Proof format
A verification result should read like a control record, not an AI guess.
The product is built around a compact payout control record: stable verdict, reason code, decision confidence, risk level, destination class, and a clear next step.
What the record captures
Stable outcome languageSAFE_TO_SEND, DO_NOT_SEND, REVERIFY, or SEND_SMALL_AMOUNT — one clear status language for action and escalation.
Control fieldsChecked at, confidence level, decision confidence, risk level, reference, destination class, and next action.
Operational contextShort explanation for why the decision was returned and how an ops team should react.
ReviewabilityA result that can be used in a workflow, ticket, or approval log without rewriting it.
Format preview only. Signed records are produced inside controlled workflows.
Record id
ppf_demo_2026_03_24_001
Time checked
2026-03-24T19:12:08Z
Verdict
SAFE_TO_SEND
System reference
OK
Confidence
High
Destination type
Personal wallet
Source
Live RPC lookup
Next action
Approve payout
Why this verdict
Network, asset, address, and memo checks matched. The destination classified as a personal wallet.
Before sending
Pre-Send Risk Control
Use this at the approval step before funds move. The service compares expected and provided transfer details, validates the address format, and runs a live lookup to classify the destination and return one operational verdict.
Run a live pre-send verification
Expected vs provided chain, asset, address, and memo/tag. The current public checker supports USDC and USDT across six live networks.
Live verification
Expected by payer
Provided by payee
Open example scenarios (optional)
These review scenarios stay available for inspection, but remain outside the main product path.
Ready for a live check.
READY
No verification record yet.
Run a live check to generate a proof-style result card. Pilot review scenarios stay available below if you need examples.
READY
Next step
Run live check
Time checked
—
Confidence
—
Decision confidence
—
Risk level
—
System reference
—
Why this verdict
Waiting for a live or pilot-review result.
Destination type
Unknown
Risk flags
—
AI risk context
Fast execution environment detectedHuman verification reducedWaiting for live result
Run a live check to generate the final recommendation.
Checks
Live verificationWaiting
After a mistake
Recovery guidance after a bad send
Use this after something already went wrong. Recovery is the secondary module: it looks up the live transaction and returns practical next steps based on the network, transaction status, recipient type, and issue type.
Analyze a real transaction
Paste a real transaction hash to get live status, recipient analysis, and practical recovery guidance across current live network coverage.
Live analysis
Recovery input
Optional hint. Leave this on Auto-detect if you are not fully sure what went wrong.
What the guide returns
StatusConfirmed / failed / not found / unavailable
What was detectedNetwork, status, recipient, transfer hints, and whether the recipient is a wallet, contract, or app
Recovery outlookPossible / manual review / unlikely / depends
Next actionsPractical steps for the user or support team
Recovery packetA copy-ready summary and support message built from the live result
Open recovery example
A single sample case stays available for review without turning the main page into a sandbox.
Ready to check a transaction.
READY
No transaction checked yet.
Paste a real transaction hash to see what likely happened and what to do next.
—
Quick answer
What this means
Run a check to get a clear answer.
Contact first
We will suggest the right contact path after a live check.
First step
Start with a live transaction lookup.
Recovery verdict
—
Recovery chance
—
Recipient type
—
Contact path
—
Detailed next step
—
On-chain status
—
Checked at
—
Confidence
—
Case reference
—
Why this result
Waiting for a live or pilot-review result.
Action plan
—
Support message
Run a check to generate a ready-to-send support message.
Recovery packet
Run a check to generate a copy-ready packet.
Security model
PayeeProof should be a control layer, not a new trust problem.
The safest version of this product explains its answer clearly, does not hold funds, and blocks mismatches instead of letting fast automation turn uncertainty into a transfer.
No custody
PayeeProof does not hold funds and does not execute transfers. It exists to verify or analyze, not to move money.
Block when details do not match
If details are invalid, mismatched, or suspicious, the safe answer is block, reverify, or escalate — not “probably fine.”
Live network checks
Uses live blockchain lookups to identify the recipient type and analyze transactions instead of relying only on static form checks.
Integration flow
How PayeeProof fits into a modern payout workflow.
A short integration story is stronger than a wall of raw JSON: collect payout details, run the control check, read the risk context, then approve, block, reverify, or test small.
Step 1
Workflow captures details
Network, asset, address, memo or tag, and route context are collected before a transfer is approved.
Step 2
PayeeProof checks risk
The service compares expected vs provided details, runs a live destination lookup, and returns AI risk context.
Step 3
Clear verdict
The result returns one public language standard: SAFE_TO_SEND, DO_NOT_SEND, REVERIFY, or SEND_SMALL_AMOUNT, with decision confidence, risk level, and AI risk context. UNAVAILABLE stays a system fallback, not a green-light state.
Step 4
Ops takes action
Approve the payout, stop it, re-confirm details, or ask for a small test transaction before size moves.
Live today
Pre-Send verificationLive validation for network, asset, address, memo or tag, and destination classification.
Policy presetsPayout Strict, Deposit Review, and Treasury Review for clearer rollout fit.
Pilot intakeTeams can submit one workflow and get a practical pilot fit review through the request form.
Exchange-side verification still depends on direct partner integrations. Public chain checks and guided recovery are already live.
Technical overview (optional)
Public API positioning stays pre-send first. The technical page is there for teams that want request and response shape, record fields, and rollout boundaries without turning the main page into a developer manual.
Public API v1Pre-send first, with risk-control records and account endpoints for authenticated clients.
Recovery pathDocumented separately as a secondary module so the main offer stays focused.
Policy presetsPayout Strict, Deposit Review, and Treasury Review help align the risk-control layer to a real workflow.
Verification scenarios
Common outcomes, shown in one control language.
These are the scenarios a payout team usually cares about first: clean match, route mismatch, risky destination class, and recovery cases that need escalation instead of guesswork.
Pre-Send
SAFE_TO_SEND
Wallet details match
Network, asset, and destination align, and the recipient looks like a personal wallet rather than an ambiguous service endpoint.
Pre-Send
DO_NOT_SEND
Wrong network or invalid address
The safest answer is to stop immediately when the address format fails or the provided network does not match the intended route.
Pre-Send
REVERIFY
Exchange-like deposit destination
Some addresses behave more like service endpoints than self-custody wallets. They should be confirmed before a full transfer is approved.
Pre-Send
REVERIFY
Contract or app destination
Funds may technically arrive, but recoverability and ownership depend on contract logic, permissions, and whether the destination was truly intended.
Recovery
NOT FOUND
Transaction hash not found
When the lookup cannot find the transaction on the selected network, the right move is to verify the hash and chain first instead of improvising recovery steps.
Recovery
MANUAL REVIEW
Missing memo or ambiguous recipient
Some failures are not solved by chain data alone. Service-side records, support workflows, or destination-owner confirmation may still be required.
Pricing & pilot packages
Start with one risk-control pilot, then expand only if the workflow proves useful.
The strongest commercial path is usually not a giant rollout. It is one defined finance workflow, a reviewable control layer, and a clear next step after teams review real records, policy examples, and trust boundaries.
Pilot evaluation
Best for one workflow, one operational pain point, and one success criterion. Good for a fast review.
Custom integration
Best for teams that already know the workflow and want policy, verdicts, and outputs aligned to real operations.
Enterprise path
Best for broader operational usage, repeated verification, and a longer-term commercial relationship.
Pilot
Request a pilot
Use the form to describe the stablecoin payout workflow you want to protect. Share enough detail for a serious fit review and a clear next-step recommendation.
Best fitContractor payouts, creator payouts, affiliate payouts, vendor payouts, and stablecoin batch releases.
What to includeNetworks, assets, destination types, where manual wallet review creates risk today, and what decision your team needs before approval.
Pilot review outputA practical fit check, an initial pilot direction, and clear next steps.
Request pilot
Use a work email and include enough context for a serious fit review, not just a one-line intro.