# Invoicing Module and Pay by Link (GladstonePay) HTML version: [Invoicing Module and Pay by Link (GladstonePay)](https://support.gladstonesoftware.cloud/gooperator/invoicing-module-and-pay-by-link-gladstonepay) ## Problem You need to bill a contact for several sales, such as block-booking occurrences, with one invoice they can pay online by **Pay by Link** or at the 360 till, and manage the payment links you send. ## Resolution ### How invoices are built 1. **Understand what the Invoicing Module does** - The **Invoicing Module** groups one or more of a contact's sale invoices into a single invoice (display id such as `INV-0001`) that can be issued with a **GladstonePay Pay by Link** and paid online or at POS. - It aims to: automate invoice generation for a contact's **INV account** (block bookings are the main driver at launch); deliver each invoice with a Pay by Link; support manual methods (cash, BACS, cheque) with operator-updated sale status; keep HMRC-compliant sequential numbering, credit-note handling and VAT treatment; and reconcile invoice, payment and sale automatically. - It replaces raising invoices outside Gladstone, sending them by email, tracking them in spreadsheets and reconciling by hand, which caused outstanding debt (no automated chasing or payment links), manual reconciliation, slow cash flow, HMRC compliance risk from manual numbering and credit notes, and finance overhead. 2. **Understand how block-booking sales feed invoices** - In Go Operator Block Bookings, **each occurrence has its own sales invoice**. The Invoicing Module groups them per the booking's **billing grouping period** (Whole Reservation, Monthly, Quarterly or Yearly) and **itemisation** (Itemised or Grouped), both fixed at creation. - A sales invoice attached to a draft invoice is "in flight", which is why editing or cancelling that occurrence may void or credit it rather than delete it. Credit notes already raised are handled in the Invoicing Module. - Legacy Plus2 hosted reservations use the Plus2 **Invoicing statement run** instead (numeric invoice numbers); see [Block Bookings (Plus2 Hosted Reservations) and Invoicing](block-bookings-plus2-hosted-reservations-and-invoicing.md). 3. **Move the invoice through its lifecycle** - An invoice has a member, a site, a document type, a total, an alphanumeric display id, a due date, a rendered HTML body and a payment link. It can be created, approved, issued, exported to PDF and listed in a back-office grid. - Flow: **Draft → Approved → Unpaid (issued via Mark as issued) → Paid**. | Status | Meaning | |---|---| | Draft | Being assembled. No display id; not payable. | | Approved | Display id allocated, due date and payment link set, HTML rendered. Not yet issued. | | Unpaid | Issued to the contact and awaiting payment. | | Paid | Every linked sale invoice is settled. | | Overdue | An Unpaid invoice past its due date. Shown, never set directly. | - Only an Unpaid invoice can become Paid, and only once **all** linked sale invoices are settled. ### Paying an invoice at POS (360 Find Invoice) 4. **Find the invoice** - In POS **Find Invoice**, enter the invoice number. The field accepts letters and auto-uppercases. - A **numeric** number uses the existing legacy Plus2 lookup; an **alphanumeric** one (for example, `INV-0001`) is treated as a new-module invoice. - POS shows member, amounts, per-line outstanding (`Total − AmountPaid − AmountRefunded − AmountCredited`) and the site's friendly name. 5. **Issue the invoice first (if applicable)** - If the invoice is not issued yet (Draft/Approved), it still displays but **Pay** is disabled with the banner *"This invoice cannot be paid until it has been issued"*. Issue it first (**Mark as issued**). 6. **Take payment** - Take payment with any normal POS method (cash, cheque, card/PED on any provider). - The invoice is paid **in full**: all lines are pre-selected, the per-line select column is hidden and **Pay** is enabled on load. Part payment of a new-module invoice at POS is not supported. - POS then updates the invoice to Paid. This is best-effort: if it fails, the payment stands, POS shows a warning, and a later recalculation (or reopening the invoice) fixes the invoice status. - Legacy numeric invoice lookup and payment (where individual lines can be paid) are unchanged. ### Sending and managing Pay by Link 7. **Send a payment link** - **Pay by Link v1** is a GladstonePay feature for sending a single-use card payment link by email. It has two channels: the **telephone channel** in 360 POS, and the **invoicing channel** (back-office systems such as the Invoicing Module generate links through the API). - A link can be sent at any time from the basket or Sales History (for example, to chase a debt), but the telephone channel is designed for live calls. For debt chasing or invoice settlement, the Invoicing Module's API channel is the better route; discuss specific workflows with your account manager. API links are delivered through the calling system's own channel (email, in-app, letter) and use the same checkout. - If the record has no email, you are prompted to enter or confirm an address; a typed address applies to that transaction only and does not update the record. 8. **Manage links in Sales History** - **Resend**: same link, same email. - **Send New Link**: fresh link and expiry (use when expired). The sale stays open after expiry; it is not cancelled. The old link shows an "expired" message. - **Revoke**: kills an active link immediately (for example, the customer paid at the desk). The sale remains open and unpaid; generate a new link or take payment another way. - After recording a **manual payment** (BACS, cash), the link becomes unusable (customer sees "contact the Centre") but is not marked revoked. **Revoke it explicitly** so its status is clear. - **Declined card**: the customer sees an error and can try another card; the link stays active until expiry. If problems continue, take payment another way (PED or virtual terminal). 9. **Confirm the payment** - There is no live paid notification. **Refresh Sales History**; the sale goes to **Completed** in the background once authorised, and the **Resend**, **Revoke** and **Send New Link** buttons disappear. 10. **Troubleshoot "customer says they paid but the sale shows unpaid"** - Refresh Sales History (there can be a short delay). - Ask whether the customer saw a confirmation on the checkout page. - If yes, it is probably a display issue: raise it with **Technical Support** (every link logs operator username, creation timestamp, site, amount and member). - If no, the payment likely did not complete: retry with the same link if active, or send a new one. ## Notes - **Availability**: the Invoicing Module is for **GladstonePay** customers on **single-database (SaaS) Gladstone Go**; legacy and on-premise deployments are not supported. It launched jointly with **Block Bookings** in Go Operator (see [Block Bookings in Go Operator (Centre Management)](block-bookings-in-go-operator-centre-management.md)). Stages: UAT w/c 5 Aug 2026, Private Preview w/c 17 Aug 2026, GA targeted end of September 2026. - **Pay by Link v1**: beta 29 Jun 2026, broad release 20 Jul 2026. Available in 360 POS (telephone channel) and through the API (invoicing channel), **Gladstone Go single-database only**; not legacy or on-premise. - Some early new-module invoices, created before a fix to how their lines are saved, will not load or pay at POS until they are patched by Gladstone or recreated. Invoices created since are fine. - **Pay by Link quick facts**: | Topic | v1 behaviour | |---|---| | Memberships / recurring / DD set-up | **Not supported**. **Send Payment Link** is hidden if the basket has a membership item. No committed timeline. Use the standard till process. | | Part or split payments | Not supported; single full payment only. Use the standard till process. | | Usable for | Bookings and classes, outstanding unpaid invoices, add-on products, arrears, multi-item baskets without memberships | | Delivery | **Email only** (SMS on the roadmap, not committed). | | Expiry | **72 hours from link creation** (not from opening the email) by default; configurable per site, and separately for **telephone** vs **invoice** links (request via Customer Success, any time). A customer calling back two days later probably needs a new link. | | Reuse | Single-use once paid; stays active after a decline or abandoned page until expiry | | Active links per sale | One. Generating a new link invalidates the old one ("no longer valid, contact the Centre"). No limit on regenerations. | | Reminders | None automated. Resend from Sales History. | | Email template | `SaaS_PayByLink` in GMC (subject, body, button). Edits apply immediately to future emails from that site; any GMC user can update it after go-live. Review it before go-live rather than leaving the default without sign-off. | | Checkout | GladstonePay-hosted with the site's existing GladstonePay branding; any device, no app or login. Card data goes straight to **CardStream** (reduces PCI scope; moves telephone payments from Card Not Present to a customer-initiated flow). 3D Secure is automatic. Card types and currency follow the site's GladstonePay configuration. Cannot be customised per transaction. | | Security | Unique, random, non-guessable token tied to one sale, single-use, expiring. A forwarded link could only pay that exact sale; no card data or account access is exposed. | | Enablement | Per site, via Customer Success. Needs GladstonePay already live; no new hardware, merchant account or CardStream contract. | - Audit records for missing email addresses before go-live. - **Disabling** Pay by Link for a site (via Customer Success or Technical Support) **immediately kills all sent, unpaid links**; sales, records and history are unaffected, so take payment another way. - **Reporting**: Pay by Link payments carry a **channel indicator** and can be filtered by payment channel in standard GladstonePay reports; unmet requirements go to the product team. Till reports, register totals and end-of-day reconciliation are unaffected. - **Pay by Link with Go block bookings**: Go Operator Block Bookings lists Pay by Link with configurable expiry in scope. If payment is taken up front, the user needs permission to issue Pay by Link sales, the Pay by Link flag must be on, and the expiry window should be agreed with the Centre Manager so unpaid occurrences do not fall outside the sale lifecycle. How to configure the expiry for block bookings is not documented. See [Setting Up Block Bookings in Go Operator](setting-up-block-bookings-in-go-operator.md). - **Paying invoices from the Go account**: Operator also has a **pay-invoice URL / invoice payments** setting that lets block bookers log into their Go account and pay an outstanding invoice online. It is a payment method, not a ledger category: money is recorded when taken, and a payment covering several periods is not apportioned back across them. See [Other Go Operator Settings: Single Site, SSO, Payments and Notifications](other-go-operator-settings-single-site-sso-and-notifications.md). - How to configure or raise an invoice in the back office is not covered here. For the day-to-day approve, issue and record-payment steps, see [Using the Invoicing Module](using-the-invoicing-module.md); for sending a link during a call, see [Taking Telephone Payments with Pay by Link](taking-telephone-payments-with-pay-by-link.md). - Related: [Block Bookings in Go Operator (Centre Management)](block-bookings-in-go-operator-centre-management.md); [Block Bookings (Plus2 Hosted Reservations) and Invoicing](block-bookings-plus2-hosted-reservations-and-invoicing.md); [Paying Invoices and Sending Pay by Link from Gladstone360 POS](../gladstone360/paying-invoices-and-sending-pay-by-link-from-gladstone360-pos.md); [Gladstone Go and 360 Email Templates](gladstone-go-email-templates-and-communication-jobs.md).