Skip to Content
Payment LinksOverview

Payment Links — Overview

A Payment Link is a shareable URL that drops a buyer into a hosted checkout you’ve already configured. No SDK, no server integration — issue it in the dashboard, share it, and the same payment.settled webhook fires when funds confirm on-chain.

Under the hood, a Payment Link is a CheckoutSession — “Payment Link” is just the dashboard-side name for a session that wasn’t created by a buyer-driven SDK flow. Same webhook contract, same on-chain settlement, same fees.

Common uses:

  • Invoicing a one-off customer without writing code
  • Sales pages where the dev team isn’t going to wire a custom cart this quarter
  • B2B follow-ups — paste the link into an email and call it done
  • “Buy me a coffee”-style fixed-amount tipping pages

Create one

Today this is dashboard-only:

  1. Sign in to the merchant dashboard 
  2. Payments → Payment Links → + New link
  3. Pick one of two paths:
    • New order — enter line items, currency, customer info, and optional metadata. The dashboard creates the Order and the Payment Link in a single call.
    • Existing order — pick a PENDING order (e.g. the buyer abandoned the previous link). Re-issues a fresh link backed by the same order, so the order history stays intact.
  4. Save → the dashboard shows the https://checkout.infraio.xyz/cst_… URL with a copy button and a QR code download. Test-mode links use checkout-dev.infraio.xyz so the environment is encoded in the hostname.

Each Payment Link is single-use today: once a buyer pays, the session is COMPLETED. If a session expires before payment (default TTL is 30 minutes), open the order detail page and click Re-create link to issue a fresh one against the same order.

What the buyer sees

  1. They land on checkout.infraio.xyz/<session_key> — the same hosted checkout UI you’d get from an SDK-issued session.
  2. They go through the standard pick-asset → send funds → wait for confirmation flow described in Checkout — Overview.
  3. payment.settled fires on your webhook with the order, intent, receipt, on-chain tx hash, and confirmation count — same payload as any other settled payment. See Webhooks for the schema.

What the dashboard gives you

The Payment Links surface today ships with:

  • List view — every link you’ve issued, cursor-paginated, with status, amount, parent order number, customer, expiry, and a one-click open to the buyer URL.
  • Filters — status (ACTIVE / COMPLETED / EXPIRED / CANCELED), date range, and full-text search across order number, customer name, email, or external ref.
  • CSV export — one click, respects the current filters.
  • KPI strip — counts per status, scoped to the current environment (live vs test) via the X-Environment header so the numbers always match what the table is showing.
  • Detail page — order summary, sessions history (every attempt for this order), on-chain history with block explorer links, and a Re-create link action for sessions that expired before payment.

Limitations today

  • No programmatic API — links must be created in the dashboard. The SDK can create equivalent single-use sessions via POST /b2b/v1/checkout-sessions/quick (see API reference), but the “long-lived shareable URL” UX is dashboard-only for now.
  • No per-buyer authentication — anyone with the URL can pay. The single-use model partially mitigates this; full buyer identity binding is on the roadmap below.
  • Branding is global — the link uses your merchant-wide logo, brand colour, and border radius from Settings → Branding. Per-link branding overrides aren’t surfaced in the dashboard UI yet.

Roadmap

Items we know we want, prioritised highest to lowest:

  • Programmatic creation — a POST /b2b/v1/payment-links endpoint that mirrors the dashboard’s two-tab dialog and returns the same checkout_url. Pairs naturally with listing + revocation.
  • Time-based expiry — link stays valid until a specific date, not just until the session TTL elapses. Needed for invoicing flows where “due in 14 days” is the natural deadline.
  • Reusable links — Stripe-style multi-buyer pages (donation, tipping, recurring tabs). Today every link is single-use.
  • Per-buyer identity — lock a link to a specific email or wallet so it can’t be forwarded.
  • API-side QR generation — the dashboard renders QR codes client-side today; surfacing this on the API for label printing and embedded receipts is on the list.

See also

OverviewJavaScript / Browser