Payment link

A payment link is a merchant-generated URL that, when opened, presents a customer with a checkout for a specific payment — amount, currency, and merchant context already filled in — without the merchant needing to integrate a checkout flow into their own site or app.

The link encodes the invoice in the URL itself (or in a server-side record the URL references). When the customer opens it, the gateway renders a hosted checkout page with the payable amount, the supported payment methods (in the crypto case, the supported coins and chains), and any merchant branding the link carries. The customer pays; the gateway notifies the merchant via webhook; the merchant's order moves to fulfilled.

Payment links collapse a multi-step integration into a URL. A merchant who runs a Telegram-based business or a one-off freelance invoice can accept payment without writing a single line of code — just paste the link in a chat or an email. A merchant who runs a full e-commerce stack can still use payment links for edge cases: a custom-quote invoice, a refund test, a partial payment, a marketplace order routed to an individual seller.

Why it matters

• Zero-integration acceptance. Payment links work for merchants who have no website, no plugin, no developer time, and no inclination to manage one. A creator on social media can drop a payment link into a post and start accepting crypto on the same day they sign up for a gateway account.
• Per-invoice routing. Each link carries its own invoice metadata — amount, currency, merchant reference, optional buyer info — so the merchant can reconcile every payment against an internal order without an integration in their order system. The merchant's webhook handler reads the metadata field that came back from the gateway and matches it to their own database.
• Disposable URLs for sensitive flows. Payment links can be configured with expiry times, single-use semantics, or per-link recipient locking — useful for high-value invoices where the merchant wants the link to stop working after the customer has paid (or after a deadline has passed).
• Cross-channel distribution. The same payment-link URL works in an email, a chat message, a QR code, an embed iframe, or a deep link from a mobile app. Distribution is decoupled from the checkout itself, which means the merchant can experiment with how they reach customers without changing the underlying payment plumbing.

How MixPay implements payment links

MixPay generates payment links via two paths:

• Dashboard — the merchant logs in, creates an invoice (amount, currency, optional metadata, optional expiry), and the dashboard returns a URL pointing at the MixPay-hosted checkout page. This is the zero-code path used by merchants who don't run their own backend.
• REST API — the merchant's backend calls POST /payments with the invoice fields and receives back a payment-link URL plus a payment_id. The URL is what the merchant shares with the customer; the payment_id is what the merchant's webhook handler matches against incoming notifications.

The hosted checkout page presents the customer with a coin-and-chain selector spanning 100+ supported cryptocurrencies across 20+ chains. The customer picks an asset, the page renders the exact amount in that asset (the gateway runs the rate feed), and the customer's wallet broadcasts the on-chain transaction. MixPay settles the equivalent value into the merchant's Mixin Wallet as a stablecoin at receipt; see stablecoin settlement for the conversion model.

A merchant who wants to embed a custom-styled checkout (rather than redirect customers to the MixPay-hosted page) can use the same /payments API and render their own UI against MixPay's payment status and webhook contract.

Common misconceptions

• A payment link is not a recurring-billing primitive. Each link is one invoice for one payment. Recurring billing is a separate integration that creates a new payment link each period and reconciles each one. Some gateways layer recurring helpers on top of the payment-link API; the underlying flow is still per-invoice.
• A payment link does not authenticate the payer. Anyone with the URL can attempt to pay. If a merchant needs to lock a payment to a specific buyer (e.g. for KYC reasons), they pass the buyer identifier in the link metadata and verify it in the webhook handler, or use a separate authenticated-checkout flow.
• An expired payment link does not roll back a completed payment. Expiry stops future attempts; it does not refund a payment that landed before expiry. If the customer paid milliseconds before the link expired, the payment is valid and the merchant should fulfil. Reconciliation logic must accept the gateway's paid event as authoritative regardless of expiry timing.
• A payment link is not the same as a hosted checkout. The payment link is the URL; the hosted checkout is the page the URL points at. The terms are often used interchangeably because most gateways offer both bundled, but they decompose: a merchant can generate payment links that resolve to a custom (non-hosted) checkout, and a merchant can use a hosted checkout without ever sharing a link (the link is embedded in the merchant's own redirect flow).

Related terms

hosted checkout, webhook, idempotency key, payment_id, crypto payment gateway, stablecoin settlement, non-custodial crypto payment — additional entries will be added as the glossary grows.