A crypto payment receipt is a merchant's acknowledgment of a verified payment for a specific order. It should tell the buyer what was paid, which purchase it covers and how to raise a question. A transaction hash alone does not provide that commercial context.
This guide gives merchants a receipt checklist and a reusable message structure. These are recommended business controls, not a claim that Yolfi generates downloadable receipts or tax invoices. Legal document requirements depend on your jurisdiction; ask your accountant which fields and document types your business must provide.
Distinguish an invoice, a receipt and a blockchain record
An invoice requests payment. A receipt acknowledges payment already verified. A blockchain record documents a transaction on a particular network. Keep them linked without treating them as interchangeable.
| Record | What it communicates | What it does not establish alone |
|---|---|---|
| Commercial invoice | Seller, purchase and amount due | That the buyer has paid |
| Merchant payment receipt | Payment accepted against a specified order | That every tax-document requirement is satisfied |
| Transaction hash and transfer details | Asset movement on a named network | Customer identity or which purchase it settles |
| Delivery confirmation | Goods or access supplied | The payment amount or tax treatment |
A provider's object named “Invoice” may also have a technical meaning. In Yolfi API Checkout, an Invoice is created after the buyer chooses a supported network and token. Do not assume that technical object is the commercial tax invoice your local rules require.
Send the receipt after verified payment, not after a redirect
For an integrated flow, verify the payment notification on your server before marking an order paid or sending a paid receipt. Yolfi's webhook documentation identifies payment.confirmed as the primary fulfillment trigger. invoice.created means a payment was initiated, not that money has been received.
Authenticate the event using the documented signature procedure, associate it with the correct order, and handle retries without sending multiple independent receipts. A test event must not create a live paid receipt. Keep a unique receipt reference and reuse it when resending the same document.
A browser success page, wallet screenshot or pending exchange withdrawal is not enough. If the evidence is unresolved, send a payment-status update instead of an acknowledgment that the order is paid. Use the customer support evidence checklist to investigate without requesting wallet secrets.
For a manually reviewed payment, record who checked the receiving address, asset, network, amount and confirmation evidence. Your internal procedure should state when that evidence is sufficient; this article does not prescribe one confirmation count for every chain.
Include enough detail to identify the purchase and payment
Keep the customer-facing receipt readable, with technical evidence attached or available through a private order record. A buyer should not need to interpret a token transfer log to recognize their purchase.
| Receipt field | Recommended content |
|---|---|
| Document identity | Unique receipt reference and issue date with time zone |
| Seller and buyer | Business identity and the customer details required for this transaction |
| Purchase reference | Order or commercial invoice reference, plus a short description |
| Commercial amount | Original amount and pricing currency, separate from crypto quantity |
| Payment accepted | Exact quantity, asset name and network actually verified |
| Payment evidence | Provider payment reference and relevant transaction reference where available |
| Allocation | Amount applied to this order and any remaining balance or unresolved excess |
| Next contact | Established support channel and receipt reference to quote |
For tokens, retain the verified contract or mint identifier in your underlying record. A ticker alone does not uniquely identify an asset. If the customer-facing document abbreviates a long address or hash, keep the complete reference in the private evidence record.
Separate the order price from the crypto amount accepted. If you show a local-currency equivalent, state the valuation basis and time appropriate to your records. Do not describe every USDC or USDT receipt as a bank-dollar deposit or silently treat token quantities as tax-reporting values.
Fees also need clear labels. A sender's network fee is not necessarily part of the amount the merchant received. Do not invent a fee breakdown from the difference between a wallet balance and an invoice total.
Use this receipt message structure
The following is a writing template, not a real customer receipt. Populate each line from your verified records rather than asking a language model to invent transaction identifiers.
Payment received — receipt reference: your unique receipt number.
Seller and purchase: your business identity, the order reference and a short description of what the customer bought.
Payment: the verified crypto quantity and asset, the network, and the original order amount with its pricing currency.
Applied to this order: the amount accepted against the purchase, with any remaining balance or separately reviewed excess stated explicitly.
Evidence: the payment reference and relevant transaction reference, plus the payment confirmation time and receipt issue time with time zones.
Questions or corrections: contact your established support channel and quote this receipt reference. Never send a private key or recovery phrase.
Add buyer details, registration identifiers and other mandatory fields only as required by your business and local rules. Avoid placing a customer's email address, name or purchase details into public blockchain notes.
Send the receipt through an authenticated order page or the verified customer contact for the purchase. Do not expose full order records through an unprotected public document link. A public transaction can still reveal financial activity when linked to a named customer.
Keep transaction evidence useful without overselling it
A transaction can contain more than one transfer. When a single hash covers multiple token movements, identify the relevant transfer in your internal evidence rather than attaching the same undifferentiated hash to several orders.
For EVM tokens, the Ethereum transaction receipt reference documents transaction status and logs. Successful execution alone does not prove that the expected token amount reached your merchant destination. Check the relevant transfer details; the top-level recipient may be a token contract.
Use a trusted explorer on the correct network if linking to public evidence. Opening a public transaction should not require a wallet connection, signature or token-spending approval. A receipt must not become an invitation to “verify” payment through an unfamiliar wallet-access website.
Record partial payments and refunds without rewriting history
For a partial payment, acknowledge only the amount verified and applied. Do not label the entire order paid while a balance remains unresolved. For excess funds, distinguish payment applied to the order from an amount awaiting review. The underpayment and overpayment guide covers those decisions.
A later refund needs its own linked record. Keep the original receipt, the refund decision and verified outgoing payment evidence; do not simply replace the original accepted amount with a smaller number. Follow the refund review procedure before transferring money to an address supplied in a message.
Correct clerical errors through a traceable correction process. Whether a formal credit note, replacement document or another adjustment is required is a jurisdiction-specific accounting question. Preserve the relationship between versions rather than deleting the earlier evidence.
Where Yolfi fits
Yolfi payment links provide a payment entry point for fixed-price offers. The API Checkout documentation distinguishes reusable Paylinks from server-created Checkout Sessions for dynamic orders; a standalone session does not require a Paylink.
Your business should retain the order description and customer relationship, then connect the available payment references to its own receipt process. Verify which fields your current flow exposes before automating documents. Neither a public coin page nor this article establishes a particular live asset-and-network combination, document export or accounting integration.
For end-of-day controls, the reconciliation checklist explains how to connect order allocations with wallet movements. Customer receipts answer “what did I pay for?”; daily reconciliation answers whether the business's records are complete.
Frequently asked questions
Is a transaction hash a crypto payment receipt?
Not by itself. It identifies a transaction on a network, but does not establish the buyer's identity, purchase description or allocation to an order. A merchant receipt adds that business context after verification.
Can I send a receipt while the transfer is pending?
Send a status update, not a paid receipt. Acknowledge verified payment only when your documented payment-confirmation process accepts it. Do not promise that a pending withdrawal will arrive at a fixed time.
Does a crypto receipt replace a tax invoice?
Not automatically. Payment acknowledgment and legally required invoicing can serve different purposes. Ask a qualified local adviser which information and documents your business must retain and issue.
Should the receipt show a full wallet history?
No. Keep evidence limited to the relevant payment. Use private records for necessary technical details, restrict access and never request private keys or recovery phrases.
Conclusion: acknowledge the payment, preserve the context
A useful receipt connects verified funds to a recognizable purchase without claiming more than the evidence supports. Start with clear payment instructions, issue one traceable acknowledgment per accepted payment record, and preserve linked corrections or refunds instead of rewriting the original sale.
