Two customers each owe 20 USDC. Two payments arrive. The wallet balance increased by 40 USDC, but that total does not tell you which customer paid which order—or whether one customer paid twice.
For a merchant, receiving funds and identifying a paid sale are separate jobs. A payment tool provides useful context and records; your business still needs a way to connect each receipt to the right handover or order.
AI-generated concept illustration with fictional orders and abstract screens. The QR-like pattern is nonfunctional. It does not show actual payment records.
Start with the sale, not the wallet balance
Keep a sale reference before requesting payment. At a counter, that might be a numbered paper order. Online, it might be your existing invoice or booking reference. These are examples of merchant records, not fields that a shared PayIn link automatically creates.
For each fulfilled sale, retain a connection to the verified payment record. Useful details include the payment identifier or transaction reference, amount, network and the outcome of the check.
A balance change is too broad for that job. It can reflect several payments or other wallet activity. A completed transaction provides more specific evidence, but it still needs to be associated with the correct sale.
At the counter, use the announcement as the start of matching
Imagine two customers buying 20 USDC boxes. The first is packing their bag while the second scans. A sound announcing 20 USDC tells staff a payment event needs attention; it does not identify a named buyer.
Keep the handover sequence clear. Check the newly confirmed amount against the sale in progress, mark the sale handled in your own records, and use management when the sequence becomes ambiguous. If needed, ask the buyer for the transaction reference and compare it with the completed receipt.
Do not ask customers to expose seed phrases, private keys or unrelated wallet activity. A full reference is more useful than a cropped “success” screenshot.
The busy-counter guide explains how display and audio support this routine without constant wallet checking.
Online, a shared link is not a unique invoice
A reusable payment link can collect payments from many customers. Its title and amount help explain the request, but they do not automatically say which invoice each customer intended to settle.
For manual collection, send the payment request in the same conversation as the invoice and ask for the transaction reference if matching is unclear. Verify that reference against the actual completed payment rather than marking an invoice paid from the customer's message alone.
For automated fulfillment, create and validate an explicit relationship between your order record and the supported payment flow. A callback can help your system process a result, but cannot recover an order relationship you never established. See callbacks versus redirects.
Separate payment facts from order decisions
| What you observe | What still needs checking |
|---|---|
| A completed 20 USDC payment | Which 20 USDC sale it belongs to |
| Two completed payments | Two different buyers, or a duplicate payment |
| A customer's receipt screenshot | Actual transaction, recipient and completed record |
| An expired attempt | Whether a different attempt completed |
| A customer returning to your website | Server-verified payment and order status |
Two payment records can belong to one sale; one amount can be shared by many sales. Avoid using the amount as a unique order key.
Resolve uncertainty before collecting again
When a buyer says they paid, preserve the reference and inspect the existing operation. A submitted or confirming transaction needs reconciliation before another request. A missing POS sound or a lost browser connection does not prove nonpayment.
An external manual wallet transfer also needs its own check. Do not assume it will appear in the PayIn checkout history or trigger a normal POS notification.
Use the verification guide for status, amount, network and transaction checks. If a duplicate payment is confirmed, arrange any refund separately and record it against the original sale; changing an order status does not reverse a blockchain transfer.
Finish the day with receipts that explain the sales
Review completed receipts against fulfilled orders and investigate unmatched items. Keep unsubmitted, expired and failed attempts separate from received funds. A count of attempts is not a count of paying customers.
The goal is a clear answer to two questions: which sales have a verified receipt, and which verified receipts still need a business decision? A payment history becomes useful when it supports that answer.
Create a payment link after deciding how your team will associate receipts with sales.