Quick answer: A pay-by-link is a short, tokenized URL that opens a hosted checkout page — sent to the buyer inside whatever conversation you are already having with them. Instead of redirecting a customer to a storefront, you arrange the payment where the customer already is: WhatsApp, RCS, SMS, or email. On Devotel Orbit the pay-by-link center (Messages → Commerce checkout → Pay-by-link) mints a tokenized hosted link, renders it for any conversation channel, moves it through its lifecycle, and reconciles the payment provider's capture — all from one page. Your buyer's card number never touches Orbit; the buyer pays on your own hosted checkout surface, which is what keeps the PCI scope on the controls you configure.
What a pay-by-link is, and where it fits
A pay-by-link collects a one-off, arbitrary-amount payment with nothing more than a URL. The four rails merchants reach for in conversation commerce split cleanly once you name what each does:
- Pay-by-link — a hosted checkout URL. The merchant mints it, the buyer opens and pays, the provider captures. Good for one-off invoices, deposits, and on-demand charges inside a running conversation.
- Direct carrier billing (DCB) — the charge lands on the buyer's mobile phone bill instead of a card. Suited to low-value digital goods where asking for card details loses the buyer, at the cost of higher processing fees and operator-level settlement.
- Subscriptions — recurring payments where the buyer's payment method is vaulted with the provider and charged on a schedule. The wrong tool for a one-off charge, the right tool once the same buyer pays repeatedly.
- Native in-thread checkout — platforms such as WhatsApp that host the payment UI inside the chat itself. Convenient, but tied to one channel. A pay-by-link is channel-agnostic, so the same link travels with the customer as the conversation moves channels.
Reach for a pay-by-link when the payment is one-off and the customer relationship lives in messaging. That covers most B2C service businesses — clinics collecting deposits, contractors collecting milestone invoices, logistics collecting customs charges — without standing up a storefront.
The pay-by-link center in Orbit
In the dashboard, the pay-by-link center (Messages → Commerce checkout → Pay-by-link) runs the full lifecycle of a link from one page:
- Mint. Enter the amount, currency, and your hosted checkout base URL, with an optional description, buyer reference, and expiry. The mint returns a tokenized link — a bearer token on the URL, so anyone holding the link can open it until it expires — plus the payment request record.
- Render. The same link is rendered for a chosen conversation channel and you see exactly what the buyer receives before handing it to your send pipeline.
- Advance the lifecycle. As buyer signals arrive, the operator moves the request through pending → viewed → paid, or to the terminal expired/cancelled states. Every legal transition is guarded server-side — a terminal request accepts nothing, and an illegal event is rejected with the reason.
- Reconcile. When your PSP reports a capture, you match it against the request with an exact amount-and-currency check plus the provider reference.
Under the dashboard surface, the same flow is available over the API: POST /billing/pay-by-link mints a hosted checkout session and returns a channel-ready request-to-pay message, POST /billing/pay-by-link/preview renders a known link without minting, and the payment-request endpoints drive the transition and reconcile steps. Both tiers agree on the same rules: channel capability decides where a link can be rendered, the server guards the lifecycle, and reconciliation is an exact match, not a fuzzy one.
Tokenization and PCI posture
The PCI question comes first in every pay-by-link evaluation, and the answer is about who touches the card number, so it deserves precision.
- Orbit never handles cardholder data. The buyer pays on your own hosted checkout page — your PSP's hosted form, or your own checkout surface. Orbit mints the URL and renders the message around it. Card digits do not enter Orbit's logs, recordings, transcripts, or analytics.
- For phone payments, keep the digits off the line. The masked-keypad secure-payment control on the live call page captures DTMF tones without letting digits into call recordings or transcripts — the control you enable when pay-by-voice is in play.
- What you configure is what determines scope. The link token is a bearer credential until it expires or is paid — so set an expiry window that matches your collection cycle, and point the mint at hosted checkout origins you trust. Which PSP hosted page you hand buyers, and how long the link stays open, are your controls.
Framed correctly: Orbit provides the rail and the guardrails; the PCI posture is defined by the tenant-owned controls above. Your payment provider stays the entity that sees card data.
One link, every channel
The same minted link renders differently per channel, and the renderer shows you the differences before anything goes out:
- WhatsApp and RCS — an inline message body carrying the link, appropriate to rich chat surfaces where the customer taps through.
- SMS — a compact plain-text body, tight enough to keep the URL intact within the segment count.
- Email — a subject line plus a body, for the channel where buyers are most likely to pay on a desktop.
- Voice (pay-by-voice) — an SSML read-out an agent can send during a live call, with an optional QR payload so the caller can scan their way to checkout.
Because a link is a URL, the decision rule is a fallback order, not a hard choice: prefer the richest reachable channel (RCS or WhatsApp), fall back to SMS, and treat email as the surface where the buyer finishes on a bigger screen. The rendered message is handed to your existing channel send pipeline — outbound SMS and voice continue to exit only via the Devotel softswitch. The link is a payload; the routing does not change.
Reconciliation and webhooks
Minting a link is half the job. The other half is proving the money arrived and tying it back to the conversation:
- Order-status webhook on every real status change. Each lifecycle transition that actually moves the request fires the order-status webhook to your subscribed endpoints — your systems hear that a link was viewed, paid, or expired as it happens.
- Exact-match reconciliation. When your PSP reports a capture, the reconcile step accepts it only on an exact amount-and-currency match plus the provider reference. A partial capture or a currency mismatch does not silently settle; it is rejected loudly enough to act on.
- Settlement back to the conversation. The routing context — the organization, conversation, and contact the link was minted for — travels with the payment so the settled amount lands on the right conversation timeline, not in a spreadsheet.
Frequently asked questions
Is a pay-by-link the same thing as a payment gateway?
No. The payment gateway (your PSP) authorizes and captures the card. A pay-by-link is the delivery and lifecycle layer in front of it: mint the URL, send it in the channel the conversation is on, track the buyer signals, and reconcile the PSP's capture back to the request.
Does the buyer's card data pass through Orbit?
No. The buyer pays on your own hosted checkout page — your PSP's hosted form or your own checkout surface. Orbit mints and renders the link; the card number never enters Orbit. For phone payments, the masked-keypad secure-payment control keeps keyed digits out of recordings and transcripts.
Can the same link go over WhatsApp, RCS, SMS, and email?
Yes — that is the point of the rail. You mint once and render per channel: inline bodies for WhatsApp and RCS, a compact plain-text body for SMS, a subject plus body for email, and an SSML read-out for pay-by-voice. The recipient opens the same hosted checkout regardless of the channel it arrived on.
What happens if the PSP capture does not match the requested amount?
Reconciliation is exact: the reported capture must match the request on amount and currency, keyed by the provider reference. A mismatched capture is rejected rather than partially settled, so an operator sees the discrepancy instead of discovering it in month-end reporting.
When should I use DCB or a subscription instead of a pay-by-link?
Use DCB when the charge is low-value and card entry would lose the buyer — the cost shows up on their phone bill instead. Use a subscription when the same buyer pays on a schedule. Use a pay-by-link for the one-off, arbitrary-amount payment inside an ongoing conversation.
Resources
- Open the pay-by-link center: Messages → Commerce checkout → Pay-by-link in the Orbit dashboard.
- The conversational commerce pillar and how cart recovery, wallet passes, and payment requests share one conversation spine: Conversational commerce on Orbit.
- Choosing the fallback order across WhatsApp, RCS, and SMS: Channel fallback matrix.