A payment is only part of the purchase.

01 / The order

Separate the purchase from the payment

Before thinking about a token, describe what you are buying. Is it a physical product, a subscription, a digital file or merely a chance to receive something? Those are different arrangements. A page that sells a ticket should not be read as a product order with guaranteed delivery. Write down the item, quantity, price, delivery method and seller’s stated obligations in ordinary language.

A useful checkout gives you an order reference that you can use outside the wallet. Save it before leaving the store. If the store hands you over to a payment provider, check which organisation is responsible for the invoice and which one will answer a delivery question. A payment processor and a seller can be separate businesses, even when their screens appear in one continuous flow.

For your own records, keep two columns: what the seller agreed to supply, and what you were asked to send. This is an organising tool, not a legal guarantee. If either column remains unclear, pause before payment. A countdown or a promotional banner does not fill in missing order terms.

02 / The destination

Read the wallet, network and token separately

A wallet is an application or device used to manage an account and authorise actions. Its public address is not its recovery phrase. The address can be used to receive assets; the recovery phrase or private key can give control of them. Neither a shop nor a support agent needs that secret to locate an order.

Next identify the network. A token ticker is only a label, and the same label may appear on several networks. Record the network named at checkout and, where relevant, the full token contract address. Do not infer compatibility from a logo, a search result or the fact that two addresses look alike. Use the merchant’s documented payment options rather than improvising a transfer route.

Also distinguish a self-custody wallet from a balance held by a service. In self-custody, you manage the credentials that authorise transactions. With a hosted service, withdrawals depend on that service’s process as well. This distinction helps explain why a withdrawal request, a wallet signature and a confirmed transfer are not interchangeable events.

A stablecoin aims to track a reference asset or currency. The word “stable” does not turn a token into an insured bank deposit or remove issuer, market and technical risks. For a purchase, the practical question remains precise: which asset does this particular invoice accept?

03 / The request

Read an invoice as a complete set of instructions

Treat the invoice as a collection of fields, not simply a large “Pay” button. Check the merchant name, order reference, network, accepted asset, recipient, amount and any expiry time. If a QR code is offered, compare the details your wallet displays with the written request. A copied address alone does not explain what the payment is for.

Some hosted payment flows let a customer choose among supported wallets, tokens and networks. The available choices depend on the provider and merchant setup. A feature offered by one provider is not evidence that another shop supports it. Read the options in the real checkout at the time of the purchase instead of relying on an old screenshot or a general guide.

A short pre-payment note can be useful: “Order reference recorded; destination compared; network matched; total understood.” This note is your own record of what you checked. It is not proof that the seller is trustworthy. If a support message supplies a new destination, return to the independently verified merchant channel before treating it as a replacement invoice.

Do not use an expired request by guessing the new amount. Ask for a fresh invoice and keep the old reference so that the two requests are not confused later.

04 / The transfer

Distinguish a quote, a fee and a confirmation

An order price and a network fee serve different purposes. On Ethereum, gas pays for computation on the network. A transaction can consume gas even if its execution fails. Other networks and payment services have their own rules, so avoid assuming that every fee is charged in the token being purchased or that every failure has the same outcome.

A quote may state how long a conversion rate or requested amount remains valid. Record that condition along with the amount. If your wallet asks for more than expected, look at the separate fields instead of assuming the difference is a merchant surcharge. Where the checkout does not explain the total, seek clarification before signing.

After a transfer is submitted, use its transaction hash to distinguish it from a screen that merely says “processing.” Network inclusion, execution success and merchant order recognition are separate checks. A transfer visible on an explorer does not by itself demonstrate shipment, delivery or acceptance of the order.

For a support conversation, a short timeline is clearer than repeated screenshots without context: invoice issued, transfer submitted, transaction recorded, order status checked. Include the relevant time zone. Do not send a second payment merely because the first screen has not refreshed; first reconcile what already happened.

05 / After checkout

Plan for refunds and keep a usable record

A refund policy belongs to the actual merchant and payment provider. Read it before paying: what is refundable, how a request is made, which asset may be returned and whether any stated fees are excluded. Do not assume that the return route follows card payment rules. Stripe’s stablecoin documentation, for example, describes refunds but no card-style dispute support for this payment method; that is a provider-specific example.

On-chain refund workflows may involve a separate transaction rather than an undo button on the original transfer. Ask for a refund reference and, if applicable, the return transaction hash. Keep the original order and payment records connected to that reference. A message claiming “refund approved” is not the same record as a completed return transfer.

Make a small folder for each order: invoice, receipt, delivery terms, transfer details and relevant correspondence. Use filenames that make sense later, such as “invoice” and “merchant-reply,” rather than relying on a chat search. Keep sensitive wallet recovery information somewhere else; it is not part of a purchase receipt.

If a payment cannot be matched, provide the network, token, amount, destination, hash and order reference through the verified support channel. This gives the merchant a concrete reconciliation task without handing over control of your account.

06 / Boundaries

Understand what a wallet request authorises

Reading a page, connecting a wallet and granting a spending allowance are different actions. An allowance can remain after a website session is disconnected. Review the asset, spender and amount in a permission request; a broad or unlimited allowance deserves particular attention. Follow trusted wallet guidance to review or revoke an existing permission. Revocation is an on-chain action and may require a fee.

Be wary of a seller that changes a shopping conversation into an investment pitch, promises guaranteed returns or demands more cryptocurrency to “release” a refund. The FTC describes these kinds of warning signs in its cryptocurrency scam guidance. A familiar brand image, a busy group chat or a screenshot of other buyers does not establish who controls a wallet address.

Keep the support task narrow. A purchase query should concern an order or transfer, not require a recovery phrase, remote control of your device or installation of an unexplained wallet tool. If you suspect fraud, preserve messages and transaction details before reporting through the appropriate official channels. Do not pay a stranger who promises guaranteed recovery.

07 / Quick answers

Questions before checkout