Payment Link

What Is a Payment Link?

A payment link is a URL that directs a customer to a secure, hosted payment page where they can complete a transaction. The merchant generates the link through a payment processor dashboard or API, sets the amount and description, and shares it via email, SMS, social media, or QR code. The customer clicks, pays on the hosted page, and receives a confirmation: no e-commerce site, shopping cart, or checkout integration required.

Payment links emerged as a way to lower the barrier to accepting digital payments. Before their widespread adoption, merchants needed either a full online storefront or a physical point-of-sale terminal. Payment links collapse that requirement into a single URL that works on any device with a browser. Stripe launched its Payment Links product in May 2021, and PayPal introduced PayPal.Me links as early as September 2015. Today, nearly every major processor offers some form of shareable checkout URL.

How It Works

The lifecycle of a payment link follows four stages: creation, distribution, payment, and confirmation.

1. The merchant creates a link through their processor's dashboard or API. They specify the amount, currency, description, accepted payment methods, and an optional expiration time. The processor generates a unique URL pointing to a hosted checkout page.
2. The merchant distributes the link: embedded in an invoice email, sent as an SMS, posted on social media, printed as a QR code, or shared in a messaging app like WhatsApp.
3. The customer clicks the link and lands on a secure (HTTPS/TLS) payment page hosted by the processor. They enter their card details, select a digital wallet like Apple Pay or Google Pay, or choose another supported payment method. No account creation is required.
4. The processor handles authorization and settlement. Both parties receive confirmation: the merchant via a webhook notification or dashboard alert, the customer via an on-screen receipt or email.

API Example

Most processors expose payment link creation through a REST API. A typical Stripe implementation looks like this:

// Create a payment link via Stripe API
const paymentLink = await stripe.paymentLinks.create({
  line_items: [
    {
      price: "price_1abc123",
      quantity: 1,
    },
  ],
  after_completion: {
    type: "redirect",
    redirect: { url: "https://example.com/thanks" },
  },
});

// Share the generated URL
console.log(paymentLink.url);
// => "https://buy.stripe.com/aB3fZ..."

// Listen for payment via webhook
// Event: checkout.session.completed

The generated URL can include additional parameters for tracking and prefilling customer data:

https://buy.stripe.com/aB3fZ...
  ?client_reference_id=order_456
  &prefilled_email=customer@example.com
  &utm_source=invoice_email

Crypto-Native Payment Links

In the Bitcoin ecosystem, several protocols function as payment links with different tradeoffs around reusability, privacy, and infrastructure requirements.

A standard BOLT11 Lightning invoice is the simplest form: the receiver generates an invoice string containing the amount, payment hash, node information, and expiry time. It can be shared as a URL or QR code. However, BOLT11 invoices are single-use: the merchant must generate a new one for each payment, and they expire if not paid within the specified time window.

LNURL-pay solves the reusability problem by wrapping a Lightning payment flow in a standard HTTPS URL. The merchant runs a web server that responds to each request with a fresh Lightning invoice. A single QR code or link can serve unlimited customers because the server dynamically generates invoices on each interaction. The tradeoff: LNURL requires a web server, introducing a centralized dependency.

BOLT12 offers achieve reusability natively within the Lightning protocol. The receiver publishes a static offer string (prefixed with lno1) that any payer can use to request a fresh invoice directly through the Lightning Network's onion message layer. No external web server is needed, and blinded paths protect the receiver's node identity. For a deeper comparison of these invoice formats, see the BOLT11 vs. BOLT12 research article.

Self-Hosted Bitcoin Payment Links

BTCPay Server offers self-custodial payment links through its Payment Request feature. Merchants generate a shareable URL that displays a payment page with the current BTC exchange rate. Unlike traditional payment links, BTCPay Server is open-source and self-hosted: no third party holds the funds or controls the infrastructure. Customers can pay on-chain, via Lightning, or split across both, and the link supports partial payments until the full amount is received.

Traditional vs. Crypto Payment Links

Use Cases

Invoicing and Freelance Payments

Service providers embed payment links directly in invoices, proposals, or project completion emails. The client clicks and pays without manually entering bank details or navigating a separate portal. This reduces the time between invoice delivery and payment, a persistent friction point for freelancers and small businesses. For Bitcoin-native invoicing, a Lightning address functions as a permanent, human-readable payment link (e.g., name@domain.com).

Social Commerce

Merchants without a full e-commerce site share payment links in Instagram bios, WhatsApp messages, tweets, or direct messages. A link posted in a social media caption turns any platform into a sales channel. This pattern is particularly valuable for small sellers, creators, and businesses in regions where building an online store is cost-prohibitive.

In-Person Payments Without POS Hardware

Printing a QR code that encodes a payment link lets merchants accept payments at market stalls, pop-up shops, or events without purchasing a card terminal. For Bitcoin payments, this same pattern works with LNURL or BOLT12 QR codes: the customer scans, their wallet fetches a fresh invoice, and payment settles in seconds over the Lightning Network. For more on merchant Bitcoin acceptance, see the merchant payments guide.

Donations and Nonprofits

Payment links simplify donation collection by letting organizations share a single URL across fundraising emails, social posts, and printed materials. Bitcoin-native options like BTCPay Server payment requests and BOLT12 offers enable self-custodial donation acceptance without platform fees.

Stablecoin Payments

As of late 2025, processors including Stripe support stablecoin payments (USDC and USDB) through their existing checkout flows, including payment links. Merchants receive USD settlement at a flat 1.5% fee. This bridges the gap between crypto-native payment rails and traditional commerce: customers pay with stablecoins, merchants receive fiat. For integration patterns, see the embedded stablecoin checkout guide.

Why It Matters

Payment links are the lowest-friction path from "I want to sell something" to "I can accept money." They eliminate the need for a website, an app, a point-of-sale terminal, or a complex payment orchestration stack. For a one-person business, a freelancer, or a nonprofit, a payment link is the entire checkout experience.

In the Bitcoin and stablecoin ecosystem, payment links take on additional significance. LNURL and BOLT12 offers turn Lightning payments into something shareable and reusable: a merchant can print a single QR code and accept unlimited payments with instant settlement, no intermediary custody, and near-zero fees. Platforms like Spark that provide wallet infrastructure can enable developers to embed crypto-native payment link flows directly into their applications, combining the simplicity of a hosted checkout URL with the benefits of self-custodial, programmable money.

Risks and Considerations

Phishing and Spoofing

Payment links are inherently trust-dependent: the customer must believe the link leads to a legitimate payment page. Attackers exploit this by sending fake payment links that mimic real invoices, subscription renewals, or overdue payment notices. The hosted page can be cloned to capture card details or redirect funds. Merchants should use recognizable domains, consistent branding, and clear communication channels. Customers should verify the URL domain before entering payment information.

Link Expiration and Tampering

Payment links without expiration dates remain valid indefinitely. If a link leaks or is shared beyond its intended audience, unauthorized payments can occur. Most processors support configurable expiration times, and merchants should set them. URL parameters like amounts or reference IDs can also be tampered with if the processor does not validate them server-side. Reputable processors lock the amount at creation time and ignore client-side modifications.

Chargebacks on Traditional Links

Traditional payment links that accept card payments are subject to chargebacks. Because the transaction is card-not-present, the merchant bears the burden of proof in disputes. Crypto-native payment links (Lightning, stablecoin transfers) settle with finality and are not reversible, which eliminates chargeback risk but also removes buyer protection.

Infrastructure Dependencies

Traditional payment links depend entirely on the processor's uptime: if Stripe or Square goes down, the link stops working. LNURL-pay depends on the merchant's web server. BOLT12 offers depend on the merchant's Lightning node being online. Only pre-generated BOLT11 invoices (within their expiry window) work independently of any server, but they sacrifice reusability. Each approach trades some degree of availability for functionality.

Privacy Tradeoffs

Traditional payment links route through a processor that collects customer data (name, email, card details, IP address) and is subject to PCI DSS requirements. LNURL exposes the merchant's server to every payer. BOLT12 offers provide the strongest privacy through blinded paths, concealing the receiver's node identity while still enabling reusable payment flows.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.