Payment link

DEFINITION

A payment link is a URL that takes a customer to a hosted page where they can complete a payment, letting a business collect a payment or start a subscription without building a custom checkout.

A payment link is a URL that takes a customer to a hosted page where they can complete a payment, without the merchant needing to build a custom checkout flow or embed payment fields on their own website. In a subscription context, a payment link can point to a specific plan or subscription offer, letting a customer sign up and pay in a single click from wherever the link is shared.

Payment links are popular because they remove the development work usually required to accept payment online. A merchant, or a platform on the merchant's behalf, generates a unique link tied to a specific product, price, amount, or subscription plan, and can share that single URL anywhere a customer might be, in an email, a text message, a chat conversation, on social media, or encoded into a QR code. Recurly hosts the payment page itself, either a legacy Hosted Payment Page or a newer Checkout page, rather than linking out to a page built by the merchant or by a separate gateway.

Not every payment needs a full e-commerce checkout built around it. A sales team closing a deal over email, a support team collecting payment on a past-due invoice, or a small business selling directly through social media all need a fast way to collect payment without engineering resources. Payment links solve that by giving any team a shareable URL that handles the transaction end to end. Because the payment page is typically hosted by the payment provider or platform rather than the merchant's own servers, payment links also reduce the merchant's PCI compliance scope, since card data is handled on the hosted page rather than passing through the merchant's own systems.

The mechanics behind a payment link are consistent across most implementations:

  1. A merchant generates a link tied to a specific product, price, amount, or subscription plan.

  2. The link is configured as either single-use, intended for one transaction, or reusable, so multiple customers can pay through the same link, which is useful for a fixed-price product or a general offer.

  3. The merchant shares the link through whatever channel fits the situation, such as email, text message, chat, social media, an emailed invoice, or a QR code.

  4. When a customer clicks the link, they land on a hosted payment page that collects their payment details, which may include a card, a digital wallet, or bank transfer depending on what the provider supports, and processes the transaction through the connected payment processor.

  5. After payment, the customer receives a confirmation, and the merchant's system updates accordingly, marking an invoice as paid, an order as complete, or a subscription as active.

Benefits and examples

Payment links trade some customization for speed and simplicity, which makes them well suited to specific, high-value moments in the customer journey.

  • No development work required to start accepting payments, since the hosted page is built and maintained by the payment provider or platform.

  • Works across any channel a business already uses to reach customers, without requiring the customer to visit a website first.

  • Reduces PCI compliance scope for the merchant, since card data is handled on the hosted page rather than the merchant's own infrastructure.

  • Useful for collecting payment on overdue invoices, closing sales made over the phone or by email, and selling directly through social or messaging channels.

Illustrative example: imagine a customer support agent needs to collect a $150 past-due invoice from a subscriber whose card was declined. Instead of asking the customer to log into an account portal, the agent generates a single-use payment link for the exact $150 balance and sends it by email. The customer clicks the link, enters a new card on the hosted payment page, and the $150 is charged immediately, with the invoice automatically marked paid and the subscription reactivated.

A payment link and a hosted checkout page serve similar purposes but differ in how they are used. A payment link is typically generated ad hoc, for a specific amount, invoice, or subscription, and shared directly with one customer or a small group through a channel like email or chat. A hosted checkout page is usually a persistent, branded page a business embeds into its own website or app for ongoing self-service signups, offering more branding consistency and a more integrated buying experience since the customer may never fully leave the merchant's site. Payment links favor speed and reach across any channel; hosted checkout pages favor a consistent, on-brand experience for a business's own storefront or signup flow.

Frequently asked questions

What is a payment link? A payment link is a URL that takes a customer directly to a hosted page where they can complete a payment, without the merchant needing to build a custom checkout page.

Can a payment link be used for a subscription? Yes. A payment link can be tied to a specific subscription plan, letting a customer sign up and start paying immediately after clicking the link.

Is a payment link secure? Payment links are typically hosted by the payment provider or platform rather than the merchant's own servers, which means card data is handled on that hosted page and reduces the merchant's PCI compliance scope compared to processing card data directly.

Can a payment link be used more than once? It depends on how it is configured. A payment link can usually be set up as single-use, intended for one transaction, or reusable, so multiple customers can pay through the same link.

Does Recurly support payment links? Yes, but only pages Recurly hosts itself: a hosted invoice link for a specific invoice, or a Hosted Payment Page or Checkout page tied to a subscription plan. Checkout also supports one-time purchases; Hosted Payment Pages don't. Recurly doesn't generate links to a page built by the merchant or hosted elsewhere.