PAYIN JOURNAL

How to Verify a USDC Payment Before Handover

· PayIn

To verify a USDC payment in PayIn, open your private management link, find the payment in Payments, and check the status, amount, network and transaction against the sale. An unfinished attempt, wallet signature or customer screenshot is not confirmation that your money arrived.

This guide covers payments made through the PayIn checkout. A separate manual transfer to your wallet can require separate wallet or explorer checks; it is not guaranteed to appear in the link's payment history.

Start with the right record

Open management yourself rather than using a page supplied by a customer. Check the receiving setup's title so you know which product, shop or event you are managing. Payments includes attempts as well as completed payments; you can filter the list without losing the underlying history.

Find the record that corresponds to the purchase. If several customers pay the same amount through a shared link, the amount and timing alone may be ambiguous. Match the transaction reference with your own order or attendee record before delivery.

Never send the private management URL to a customer as a way to prove receipt. They should receive only the public payment link and any receipt you issue through your own business process.

Read the status before the amount

Status What it tells you What to do
Awaiting payment A checkout attempt was started, but confirmed payment is not recorded Keep the sale unpaid until the result is established
Confirming Processing or verification is unresolved Reconcile the existing transaction; do not immediately collect again
Paid PayIn recorded a completed payment Check the amount and transaction against the sale
Expired An unsubmitted attempt reached its deadline Keep it in history; the customer can start a new attempt when the page offers it
Failed The attempt has a failed result Read the result and check any transaction evidence before deciding to retry

The current unsubmitted-attempt deadline is 15 minutes from creation. Repeating a request does not extend it. Already submitted transactions continue to be checked; waiting longer than 15 minutes does not by itself make them failed or safe to repeat.

Verify four details

For an illustrative 18 USDC sale, check:

  1. Amount: the confirmed amount is 18 USDC, not a smaller completed payment.
  2. Asset and network: the payment uses the intended USDC asset on an accepted network.
  3. Recipient: the transaction corresponds to your configured receiving destination.
  4. Reference: the payment or transaction is matched to this sale and has not already been used to fulfill another order.

These are check steps, not a real payment example. A wallet balance alone can also be insufficient if it includes older receipts.

Use a network explorer when the result is unclear

Take the transaction reference from the record and inspect it on the corresponding network's explorer. Verify the transfer details, not just that a transaction hash exists. A transaction can contain approvals or other actions without being the USDC receipt you expect.

If there is a submitted transaction and management still says Confirming, preserve that reference and reconcile the same operation. Do not create a fresh payment simply because the browser disconnected or a notification did not arrive.

For a manual transfer outside checkout, inspect the actual receiving wallet and the relevant chain. Explain to staff that it may not produce the normal PayIn POS announcement.

Treat POS sound as a cue

The customer-facing POS briefly shows a newly confirmed amount and can play a chime or spoken amount. Staff can use that cue to check the sale. A sound heard earlier is not proof of a new payment, and silence is not proof of failure.

If the screen was hidden or disconnected, open management to reconcile receipts. The display is designed to avoid treating old history as new checkout success. For device checks, use the POS sound troubleshooting guide.

Keep payment and fulfillment separate

A reusable payment link groups transactions under that receiving setup; it does not identify your orders automatically. Track fulfillment in your own order process, and make any automated delivery idempotent so one receipt cannot release goods twice.

Refunds are separate transfers arranged after you verify the customer and receiving network. Editing an order or payment page does not reverse a blockchain transaction.

Read the payment link setup guide.