A stablecoin payment is more than displaying a wallet address. A merchant needs to explain what the customer is paying, choose a receiving network, check the result and connect it to the sale. PayIn provides a customer payment page and merchant records for receiving USDC directly to a chosen wallet.
Start with the business context
At a shop or market stall, the immediate task is to present an amount and check payment before handing over goods. On a website, event page or in an email, the task is to share a recognizable request and match the result to the right customer or order. These situations share a payment mechanism, but they need different instructions and fulfillment checks.
PayIn QR is designed for a counter display. PayIn Link is the receiving request shared across existing sales channels. Creating one request gives both a public payment link and a counter workflow. A shared link does not by itself reserve a place, issue a ticket, control stock or identify which invoice a payment belongs to.
Wallets and networks matter
The current PayIn product advertises USDC on Base, Polygon and Solana. Customers need a compatible wallet with USDC on the selected network. An exchange balance is not the same as a browser wallet that can approve the required action. Wallet support depends on the actual account type, adapter and signing method; a recognizable wallet brand alone is not a guarantee.
The merchant chooses a public receiving address. Matching the address format is only an input check: it cannot establish ownership or select an EVM network automatically. Confirm your receiving details in your own wallet before publishing the request. Do not put seed phrases or private keys into the creation form.
The Solana payment path currently stops before signing if the required receiving token account is missing. It does not automatically create the first token account or decide who should pay that cost. Check this condition before offering the flow to customers.
The four parts of the flow
1. Present a request
Show a business name that customers recognize, the network and a clear fixed or customer-entered USDC amount. Put a counter code where it can be scanned without confusion. On a sales page, explain what the payment is for and how a customer should reference an order if your integration requires it.
2. Let the customer review
The public page lets customers review before approving in their wallet. Approval is not the same as a final payment record. A cancelled wallet prompt should not be presented as a paid order; an uncertain response should not automatically invite the customer to pay again.
3. Check the result
Before handover, check the persisted payment status, amount and transaction. A sound, screenshot or customer return to a success page is not enough on its own. Foreground device settings affect counter alerts. Reconnected displays may recover older records; those records should not all sound like new arrivals.
4. Fulfill in your own system
Your order, booking or admission process stays under your control. With a developer integration, verify the event and the corresponding payment, then make fulfillment idempotent so repeated notifications cannot trigger duplicate deliveries. Keep a manual process for unclear outcomes and reconcile outages.
Understand costs, timing and refunds
Network or service fees may apply. Confirmation time varies with the wallet, network and payment services involved. PayIn's approximate two-second observation refers to prior tests from customer wallet confirmation to the success screen; it is not a guarantee for each transaction or a settlement SLA.
Funds are directed to the merchant's chosen wallet rather than a PayIn merchant balance. That also means the merchant manages wallet access, recovery and any refund. A refund is a separate transfer arranged with the customer; deleting a business order does not reverse an on-chain payment.
Choose your next step
Use the receiving guide to prepare your wallet, then create a request suited to a counter or sales channel. Read the payment-link and notification documentation before relying on automated delivery. If you want to operate a gateway, address pools and your own monitoring infrastructure, PayIn Open is the separate self-hosted project; its order/deposit APIs are not the hosted QR/Link API.
Receiving guide · Current documentation · Compare receiving workflows