Begin with the sale you need to support. A customer at a stall needs a clear request and a quick handover check; an event registration needs a way to associate payment with a person; an online order needs a reference your system can reconcile. PayIn provides a payment request and records, while your business controls what happens next.
At a shop, stall or event check-in
Choose a receiving network and verify the public address from a wallet you control. Create a QR request with a recognizable business name. A fixed amount suits a particular offer; a customer-entered amount suits totals that vary. Review the resulting request before printing a code or opening a counter display.
Keep private management access away from the public counter. If a staff device is used, use the capabilities supported by the application rather than handing every person an unrestricted credential. Keep the display in the foreground if you rely on sound, test its audio on the actual device and maintain a visible way to check payment records.
Before handing over goods or admitting a guest, verify the amount, status and transaction. Two payments for the same amount are still separate payments. A record recovered after reconnection should not be mistaken for a new arrival. If the result is uncertain, investigate the existing attempt before asking the customer to try again.
On a website, event page or in email
Place a public payment link beside the offer and explain what the customer is paying. State whether the amount is preset or entered by the customer. Tell the customer which network they need and how an order or registration will be associated with the result.
A shared link does not automatically identify a customer, allocate a place or update your stock. For a small manual workflow, keep a clear reconciliation process. For an integrated workflow, carry a supported business reference, verify the payment server-side and make fulfillment idempotent. A return URL is navigation, not payment evidence.
Before the first customer
Check the receiving network and address, business name, amount behavior and public link. Save management access and recovery material using your own secure process. Customers need a compatible wallet with USDC on the matching network; exchange balances and every wallet account type are not interchangeable.
Confirm current network limitations. The Solana path stops before signing if the receiving token account is missing; automatic first-account creation and cost handling are not supplied. Network or service fees may apply, and confirmation time varies. Do not promise a guaranteed two-second result based on the website's prior average observation.
When a payment is unclear
Keep the payment identifier and check the existing record. Do not rely solely on a wallet signature, screenshot, sound alert or customer statement. Avoid asking for another approval while a settlement outcome remains uncertain. If your counter lost connection, reconcile persisted records before treating recovered events as new activity.
A refund is a separate transfer arranged with the customer. Cancelling an order in your business system does not automatically reverse an on-chain payment. Keep the payment and the business action linked in your own records so your team can explain what happened.
Choose current or self-hosted documentation
Current PayIn QR and Link are two workflows for the same hosted receiving setup. PayIn Open is a separate gateway operated on your own infrastructure, with address pools and order/deposit interfaces. Historical Cloud and Pro documentation does not establish feature compatibility with the new hosted product.
Read the current getting-started and integration guides for hosted receiving. Use the Open reference when you are actually deploying and operating that gateway. The blog supplies longer examples and protocol background, with original publication context clearly marked.