At closing time, the useful question is not just “How much is in the wallet?” It is “Which completed payments belong to today's sales, and which items still need attention?”
A wallet balance can include earlier funds and unrelated transfers. A payment record gives a more specific starting point. PayIn management provides payment history, a received-USDC summary, date and status filters, and a CSV export of the filtered records. Your sales ledger supplies the order relationship.
AI-generated concept illustration with fictional records. It is not a PayIn screenshot, financial statement or evidence of real revenue.
Fix the period before comparing totals
Open the private management link for the receiving setup you are reviewing. Check that payment history has synchronized successfully; if updates are interrupted, retry before relying on its totals.
Use Filter by date to set From and Through values for the shift. The page identifies the browser's time zone. Record that zone with your closeout so a colleague does not interpret the same day using a different local time.
In the current interface, the date filter uses the confirmed timestamp when present, otherwise the attempt's creation time. A payment started before closing but confirmed after the boundary can therefore fall into a different period. Preserve that distinction when reconciling late results.
The overview's Received amount and paid count describe completed USDC payments in the selected date range. They do not become a customer count or profit figure, and the status filter on the activity list does not redefine the date-range overview.
Separate received funds from attempts
Use Paid to focus on completed receipts. Review Confirming separately for operations that need verification, and do not add waiting, failed or expired attempts to the received total.
A customer can start more than one attempt for one sale. Conversely, one customer might complete two payments by mistake. Counts of attempts, paid records, customers and fulfilled orders answer different questions.
For an illustrative closeout:
| Sale | Verified receipts | Decision |
|---|---|---|
| Order A, 18 USDC | One completed 18 USDC receipt | Match and mark fulfilled in your own ledger |
| Order B, 20 USDC | Two completed 20 USDC receipts | Investigate possible duplicate collection |
| Order C, 12 USDC | Confirming only | Keep unresolved and reconcile the existing operation |
| Order D, 15 USDC | No linked checkout receipt | Investigate before concluding unpaid; it might be an external transfer |
These are fictional examples. They show why a completed-payment total alone cannot tell you the day's correctly fulfilled sales.
Match each receipt to a business record
Keep the payment reference with your order, invoice or paper sale number. Expand a payment in management to inspect details, including its transaction reference when available. Check amount, currency, network and receiving context before treating a disputed sale as paid.
Two equal amounts are not interchangeable receipts. A standard reusable link does not automatically assign each payment to a customer or order. Use the equal-amount matching guide when several buyers owe the same total.
If you used several payment links during the shift, review them individually and combine the results in your own ledger without counting a receipt twice. This article does not claim a cross-link business analytics dashboard.
Export the records you actually filtered
After setting the date range and intended status, use Export filtered CSV. The export uses the filtered records, rather than only the rows visible on the current screen page. If the export control is disabled during loading or an error, restore synchronization first.
Current columns are paymentId, status, amount, currency, network, settledAt, createdAt and metadata. The timestamp values are exported as ISO date-time strings, so retain their time-zone meaning when comparing them with local shift records.
The CSV does not currently include transaction hashes or payer addresses. Preserve needed transaction references separately from the expanded payment detail, and do not invent missing order metadata for a shared link. Treat the file as merchant data, not something to attach to a public support post.
Keep an exception list for the next shift
List unmatched paid receipts, confirming operations, possible duplicates and transfers made outside checkout. Record who is investigating each item and its reference. Silence from a POS or an interrupted browser is not enough to mark an operation failed.
A manual wallet transfer might not appear in the checkout's history or sound notifications. Inspect that transfer separately and label its source in your ledger. For submitted operations, follow payment verification before asking the buyer to pay again.
Refunds are separate verified transfers. Keep their reference and original sale relationship in your own records; changing an order status or disabling collection does not reverse a payment. The Received summary is not automatically a net-after-refunds number.
Close the shift with a record someone else can follow
Save the period, time zone, receiving setup, matched sales and unresolved items. A handover should let the next operator understand which payments have already been checked without needing to guess from wallet balances or old announcements.
This is an operational receipt-matching workflow, not an accounting or tax calculation. Inventory costs, off-ramp conversions, fees and other business expenses belong in the appropriate records outside this payment summary.
Review PayIn's receiving workflow, and use the counter display guide to help staff notice the next shift's receipts.