Receiving workflows
PayIn vs a wallet address
Both receive USDC in your wallet. Compare payment instructions, confirmation and order matching.
Keep USDC in your wallet.
You need a payment page, counter display and records for customer payments.
Handle transfers yourself.
You know the payer and can manage occasional transfers yourself.
What changes in practice
| Decision | PayIn | A wallet address |
|---|---|---|
| Funds arrive | At the receiving wallet you set. PayIn does not hold a merchant balance. | At the address you share, provided the asset, network and address are correct. |
| Customer instructions | A web page brings the merchant name, amount and selected network together. | Supply the address, exact asset, network and amount separately, or encode supported details in a wallet request. |
| Merchant confirmation | Review payment status and transaction details in the private management page. | Check wallet history or the network explorer; add your own monitoring if needed. |
| At the counter | A dedicated browser display and optional sound or spoken amount on a compatible foreground device. | Show your wallet request or address QR and follow your wallet’s notification behavior. |
| Matching an order | A shared link is reusable; a record is not automatic order attribution. | Match the transaction to your sale manually or build an integration. |
| Refunds and cash-out | Arrange a separate refund transfer. No built-in bank payout. | Arrange a separate refund transfer and your own cash-out. |
Beyond the QR code
Wallets can show an address QR. PayIn QR opens a browser payment page for review and approval in a compatible wallet on the selected network. Scanning alone does not complete payment.
At the counter: display the request, let the customer approve, then check your record before handover. Payment sounds prompt that check; they do not replace it.
Official sources: Ethereum: how to use a wallet
Records in both flows
Ordinary transfers already have onchain records showing recipient, asset, amount and transaction. PayIn adds a payment workflow and merchant page around supported payments.
Use your own payment status, amount, network and transaction details to confirm a sale. A customer screenshot or wallet signature alone is insufficient. If a display disconnects or the result is unclear, inspect the receiving wallet before requesting another payment.
Official sources: Ethereum: how to use a walletEthereum: wallet and transaction security
Same amount, different orders
Imagine two customers each paying 24 USDC from the same shared link. The amount alone does not tell you which order belongs to which customer. Use the transaction, time and customer context to reconcile each sale. Keep registration, admission and stock decisions in your business process.
For automated fulfillment, a developer must associate a checkout identifier or supported metadata with the order, verify the payment result and handle duplicate notifications safely. PayIn supports completion callbacks when configured, but a callback is not a complete order system or a guaranteed delivery queue. Do not fulfill from a redirect alone.
Wallet control and responsibility
PayIn currently supports USDC receiving flows on Base, Polygon and Solana. Both sides need compatible wallets and the correct network. Creating a request does not require buying USDC, but customers need the supported asset. Network costs may apply.
Creating a PayIn request does not require a merchant account. The private management URL controls access to that request: keep it secret and protect wallet recovery information separately. PayIn never needs your wallet’s private key.
Neither option automatically converts receipts to a bank balance. Include transfer, wallet, conversion and cash-out costs. Choose PayIn for its customer and merchant workflow, or a plain transfer when manual handling is enough.
Start receiving
QR or payment link.
Prepare a compatible wallet and test before serving customers.