Skavio Payment Proof: Check the recipient and amount before acknowledging payment

Skavio Payment Proof helps companies verify whether a direct-to-wallet USDC transfer matches a payment request. The question is not simply whether a transaction succeeded, but whether the expected token reached the approved recipient for the exact requested amount. This guide focuses on native USDC on Base and a review-first workflow: establish what was requested, inspect what transferred, then acknowledge only what the evidence supports.

1. Start with the payment request—not the payer’s screenshot

Before checking a transaction, open the original payment request and establish the expected network, token, complete receiving address and full amount. Keep the request reference and any customer or business reference available for reconciliation. Compare the complete receiving address with your company’s approved payment instructions; a shortened address alone is not enough. Payment Proof’s public interface lets users select a receiving wallet and token, enter an amount and description, optionally add a customer or reference, and create a payment link. It also says the link adds a matching amount below 0.01 token. Use the full amount displayed on the actual link—not just the original round-number amount.

2. Check the token transfer and its complete recipient

For a native-USDC-on-Base request, verify both the network and the token contract. A familiar token name or logo is not enough. Circle’s official directory lists Base-mainnet native USDC at 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913. Check the network-specific contract against Circle’s current directory when reviewing the transfer. When inspecting on-chain evidence, use the relevant Transfer event emitted by the correct token contract. ERC-20 Transfer events identify the sender, recipient and token amount. The transaction’s top-level destination can be a contract rather than the wallet receiving the tokens, so it is not a substitute for checking the transfer recipient. Compare the complete recipient address with the approved receiving address. If the request uses the optional known-sender restriction, sender matching is another required check. A successful transaction receipt alone does not establish that the expected token, recipient and amount matched.

3. Match the amount without rounding away the difference

Compare the transferred token amount with the full amount shown on the payment link, including its matching decimals. Do not round both values to two decimal places or silently treat a near match as an exact match. For illustration only, if a fictional request displays 125.0042 USDC, a transfer of 125.0000 USDC is not an exact amount match. The point is to preserve the full requested amount during review. If the recipient, token, network or amount differs, record the discrepancy and investigate before acknowledging the request as paid. Do not promise recovery or reversal, and do not instruct someone to send a second payment blindly.

4. Read the request status before saying “received”

Payment Proof’s help guide documents four request statuses. Use those states rather than inventing a separate “detected” status or treating a payer’s transaction link as completed verification.

• AWAITING: the request is awaiting payment verification. This can include a detected transfer still awaiting confirmation.
• REVIEW: payer-identification evidence is required. Keep the unresolved review visible rather than presenting it as completed verification.
• PAID: verification and matching succeeded.
• EXPIRED: the request has expired. Investigate any associated transfer rather than assuming it matched the request.

5. Retain the evidence and make a separate business decision

Base documents multiple stages of increasing confirmation assurance. Initial detection or block inclusion should not be equated with every later stage of finality, and network estimates are not a Skavio settlement-time guarantee. A PAID request records successful verification and matching; do not expand that meaning into a guarantee of every later finality stage. If confirmation cannot yet be established, say so explicitly. For a PAID request, Payment Proof offers a PDF receipt. Its Documents area provides reports and CSV exports. Retain the request reference and transaction identifier alongside the reviewed evidence, noting any discrepancies and their resolution. Before acknowledging a particular invoice as settled, also confirm that the transfer belongs to that business obligation and has not already been acknowledged elsewhere. Keep the acknowledgement precise: identify the matched request, amount, network and transaction. A verified transfer is not automatically a customer sale—tests, internal transfers and unrelated payments need separate classification. Payment evidence also remains distinct from a tax invoice.

Open Skavio Payment Proof to review your payment request and its verification status. →