Skavio Payment Proof: Document a confirmed USDC transfer for a remote client
A useful payment acknowledgment connects a verified transfer to the right business request—without claiming that blockchain evidence proves customer identity or replaces an invoice. Skavio Payment Proof supports that distinction through a noncustodial receiving-wallet workflow, payment matching and evidence exports. This hypothetical walkthrough does not describe an actual client transaction or sale.
1. Start with the receiving wallet and a precise request
In Skavio Payment Proof, customers pay the business’s receiving wallet directly. You confirm control of the receiving wallet by signing a message; Skavio does not request private keys or recovery phrases. Create the payment request with the receiving wallet, amount and description. Add the optional customer or reference information so the request can be connected to the relevant business record. Keep that attribution distinct from the on-chain facts: a customer name entered in a request is not independently verified by the blockchain. The request link adds a matching amount of less than 0.01 token. For this Base native-USDC workflow, the payer must follow the exact total, token contract and network displayed—not substitute a rounded invoice amount. Preserve the original agreement or invoice separately, including the terms needed to interpret the payment.
2. Check the token transfer—not merely the transaction hash
When the client reports sending funds, treat the transaction hash as a reference for verification, not confirmation by itself. Ethereum’s JSON-RPC documentation distinguishes successful and failed transaction receipts; pending transactions do not yet have a receipt. Payment Proof’s help guide describes checks for native USDC, network, recipient, amount and blockchain confirmation. If a known-sender address was supplied, sender matching is also part of the check. Token identity matters. Circle lists native USDC on Base mainnet at the contract below. A familiar token label is not a substitute for checking the network-and-contract pair. The ERC-20 Transfer event identifies the token sender, recipient and value, so inspect the relevant token movement rather than relying only on the transaction’s top-level destination or success label.
- Network: Base mainnet.
- Native USDC contract: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913.
- Recipient and transferred amount: match them against the payment request, including its exact matching amount.
- Sender: apply the known-sender check when that address was supplied; do not infer a person’s identity from an address alone.
3. Read the request status before acknowledging payment
A detected transfer is not necessarily a matched payment. Use the actual Payment Proof request status to decide what can be communicated, and keep unresolved questions visible. Base documents multiple confirmation stages, from preconfirmation through L1 batch finality. Report the status actually observed rather than promising a fixed confirmation time. PAID describes Payment Proof’s successful verification and matching; do not translate it into a claim that a particular Base finality stage has been independently established.
- AWAITING: verification or matching is incomplete. Do not acknowledge settlement yet.
- REVIEW: evidence identifying the payer is required before treating the request as resolved.
- PAID: verification and matching succeeded. Business attribution and accounting review remain separate.
- EXPIRED: the status does not establish acceptance of a late transfer. Resolve the case before sending a settled-payment acknowledgment.
4. Export the evidence and preserve its context
For a PAID request, the help guide provides a downloadable PDF receipt. The Documents area also provides PDF reports and CSV exports. These are payment-evidence outputs, not substitutes for a sales invoice or the underlying agreement. Before sharing the evidence, check that a colleague can trace the conclusion back to the request and transfer. The checklist below is a recommended companion record—not a claim that every item appears in the generated PDF. Add missing context separately rather than assuming the export contains it. Mark anything that could not be verified as unresolved. Retain the relevant business documents alongside the evidence under your company’s recordkeeping policy. Share only what the client or bookkeeper needs; avoid including unrelated wallet activity or other customers’ records.
- Payment request identifier and business reference.
- Network, token contract, transaction hash, recipient and exact transferred amount.
- Block number or timestamp where available, observed confirmation status, and the date and time of review.
- The basis for connecting the transfer to the client, plus any unresolved attribution or accounting questions.
5. Send an acknowledgment that says only what was verified
Once the request is PAID and the business reference has been reviewed, send a short acknowledgment with the relevant evidence. Replace the placeholders below only with checked facts. Suggested wording: “We have verified a transfer of [exact amount] native USDC on Base to [receiving address], matched to payment request [reference]. Payment Proof shows PAID as of [review timestamp]. Transaction: [hash]. The payment evidence is attached; the invoice or agreement remains a separate document.” Do not expand that statement into a claim about legal invoice discharge, fiat valuation, tax compliance or service delivery unless those matters have been separately established. A verified transfer may be a customer payment, an internal movement or a test; its business classification requires supporting context. For unresolved technical or payment-evidence issues, contact support@getskavio.com without sending wallet secrets or sign-in codes.