Self-Serve Links

Self-serve pages are token links sent to customers for verification, signup, waiver completion, booking blocked recovery, invoice review, PDF download, and payment link collection.

What this page is for

Self-serve pages are token links sent to customers for verification, signup, waiver completion, booking blocked recovery, invoice review, PDF download, and payment link collection.

Who should use it

Front desk, sales, customer support

Where to find it

/self-serve/*

Before you start

Self-serve link flow completion gate: explain which customer link each staff action creates, what the customer can do, what stays staff-only, and what failure means.
Self-serve links cover verification code, signup recovery, waiver signing, booking-blocked explanation, payment-link review, and invoice review.
Self-serve Verify route is /self-serve/verify/:token and displays Purpose, Channel, Recipient, Status, and Verification code. It loads GET /workflow-center/public/verify/:token and submits POST /workflow-center/public/verify/:token/submit with code.
Self-serve Signup route is /self-serve/signup/:token and actions are Begin, Complete, Mark failed, and Save for later. The screen shows Member, Session status, Invoice, Amount due, Reason / recovery note, and hosted payment destination when a payment link URL exists.
Self-serve Waiver route is /self-serve/waiver/:token and fields are Signer name, Signer email, IP address, and Notes. It shows Member, Template, Status, Expires, and waiver HTML content before completion.
Self-serve Booking blocked route is /self-serve/booking-blocked/:personId and displays Restriction active, Blocked until, and Reason. It is read-only for customers; staff must clear or override booking restrictions from the profile/workflow panel.
Self-serve Payment link route is /self-serve/payment-link/:paymentLinkId and shows Member, Invoice, Amount due, Payment mode, included items, and Continue to hosted payment when the payment-link URL exists.
Self-serve Invoice route is /self-serve/invoice/:invoiceId and requires signed token query context before PDF download or online payment. The page shows Member, Invoice, Status, Balance, invoice items, Total, Download invoice PDF, and Pay online when a payment link is present.
Self-serve invoice allows Download invoice PDF and Pay online only when the signed invoice response includes a payment link URL.
Self-serve flows fail closed with the API error when the token, tenant context, payment link, or invoice signature is invalid.
A self-serve link must carry tenant context and a valid token.
Staff should generate/resend links from the person profile or POS/payment flow.
Invoice links are signed and expire. They let the customer review invoice items, download the official PDF, and pay online only when an active payment link exists.
Customer-visible self-serve pages must not expose staff internal notes, provider secrets, webhook tokens, gateway references beyond customer-facing payment links, or other members records.
If a customer says the link failed, open the person profile and check link status before sending a new one.

Daily workflow

For verification: staff issues a verification challenge, customer opens /self-serve/verify/:token, checks purpose/channel/recipient, enters Verification code, and staff confirms the verification status changed.
For signup: staff starts or resumes signup, sends /self-serve/signup/:token, customer can Begin, Complete, Mark failed, or Save for later with a recovery note, and staff reviews the same signup session from the person profile.
For waiver: staff chooses an active waiver template, sends /self-serve/waiver/:token, customer reviews waiver content, fills signer name/email/IP/notes, completes the waiver, and the signed waiver attaches to the profile.
For booking blocked: customer opens /self-serve/booking-blocked/:personId to understand active restriction, blocked-until date, and reason; staff handles expiry, exception, or unblock from profile/admin workflow rather than from the customer page.
For invoice: staff sends invoice from the invoice row; customer opens /self-serve/invoice/:invoiceId with signed token, reviews items/status/balance, downloads the PDF, and pays online only if a valid payment link exists.
For payment: staff generates a payment link from invoice/POS and sends /self-serve/payment-link/:paymentLinkId through an enabled channel; customer reviews amount, invoice, payment mode, included items, then continues to hosted payment.
When a customer reports a failed link, staff should identify which route failed, check token/link expiry, invoice/payment-link status, waiver/request status, and tenant context before resending.

Watch out

Do not ask customers to share OTPs or card information with staff.
Do not treat a self-serve signup status button as proof of payment. Payment proof still comes from invoice/payment-link/provider state.
Do not resend invoice/payment links blindly when the original invoice balance, payment link expiry, or provider readiness may have changed.
Do not expose booking-blocked links as a way for customers to bypass policy; it only explains the restriction.

Use the left menu to open related pages in Troubleshooting.
Use Ask Docs for questions that are already covered in this public documentation.