Agree the network first: documenting USDC payment proof with clear disclosure
USDC is a token label, not a complete payment instruction. For a company, the useful question is not “which network do we usually use?” but “which network, token, recipient and reference did the merchant explicitly name?” This guide sets out a disclosure-first routine for Skavio Payment Proof: confirm those details before money moves, then document only the transfer facts that are actually observed—and label everything else unresolved.
The network belongs in the instruction
Payment instructions should be issued before the transfer, in a durable channel, by the party expecting payment. Require five details: the network name, the exact token identity, the recipient address, the amount and the payment reference that links the transfer to an order or invoice. Add a confirmation or timing rule only if it is explicitly part of the instruction. A wallet’s default network, an earlier payment or a checkout page for a different product is not a substitute. If the sender and the merchant name different networks, stop and resolve the discrepancy in writing. Skavio Payment Proof is a separate noncustodial USDC payment confirmation and evidence product for companies. Payment verification through Skavio Payment Proof does not itself constitute a tax invoice.
- Name the network in the instruction, not after the transfer.
- Specify the exact token used, not only the ticker.
- Confirm recipient, amount and business reference.
- Treat conflicting instructions as a stop condition.
Evidence is a match, not a hash
Once a transfer is claimed, assemble an evidence set around the original instruction. Record the network, token, recipient, amount and transaction hash; add a timestamp and confirmation status only when you have observed them or they are supplied by the interface you are using. Match every item to the instruction. The payment reference supplies business context—what the transfer is supposed to pay for. A transaction hash is a pointer to inspect, not a conclusion. A screenshot is a claim; it should lead back to the primary record. If a confirmation interface reports a fact, use that report only within its stated scope. Do not extend it to a different network, token or business purpose.
- Use the transaction hash to locate the primary transaction record.
- Compare network, token, recipient and amount line by line.
- Record timestamps and confirmation status only when observed.
- Keep the payment reference attached to its order or invoice context.
Unresolved is a valid status
Not every transfer claim belongs in the paid column. If the named network is missing, the token identity is unclear, the recipient does not match, the amount differs or the transaction cannot be found, record the item as unresolved. Pending confirmation is not the same as confirmed. A mismatch does not become acceptable because the hash looks real. Do not infer a fiat value, tax treatment or service entitlement from the transfer alone. In customer support, say what is known, what is missing and what the next human action is. Escalate wrong-network or lookalike-token cases for manual resolution rather than improvising a fix.
- Label missing, pending and mismatched evidence separately.
- Do not acknowledge settlement from a hash alone.
- Escalate network or token mismatches for human review.
- Avoid implying that blockchain confirmation settles an invoice.
Proof is not revenue
Payment proof is one record among several. Reconcile it to the order or invoice, the customer identity and the commercial terms. A transfer observed on-chain may still be a test, an internal movement or a duplicate; those categories need different treatment. Historical owner-funded or test transactions are not customer sales and must not be presented as revenue or adoption. Keep access to evidence records limited, and avoid storing wallet secrets in support tickets or shared documents. If a payment is real but the reference is wrong, ask for a corrected reference and preserve the original evidence. Tax-invoice issuance and bookkeeping conclusions require separate review—use qualified advice where necessary.
- Reconcile proof to the order, invoice and customer context.
- Never count owner-funded or test transfers as sales.
- Keep wallet secrets out of evidence files and tickets.
- Route tax-invoice and accounting decisions to the right reviewer.