Customer Portal & Public Surfaces
Payment links
Use hosted invoice payment links with Paystack, Flutterwave, and Anchor providers.
Payment links
Payment links covers hosted invoice and checkout links for customers using configured payment providers and public payment surfaces. Use this page when you are setting up the product surface, reviewing a rollout, or troubleshooting why users see a different result from an administrator.
What this surface is
- Primary purpose: hosted invoice and checkout links for customers using configured payment providers and public payment surfaces.
- Where users start: Billing invoice routes include
/billing/invoices,/billing/invoices/view/:invoiceId, and object billing tab payment paths. - Where administrators configure it: Object billing can open payment entry at
/objects/:objectName/:recordId/view?tab=billing&billing_tab=addPayment&invoice=:invoiceId. - Runtime/detail surface: Customers pay from a narrow hosted surface without receiving staff workspace access.
- Platform connections: Payment links connect invoices, billing records, payment providers, public access, notifications, storefront checkout, and provider webhooks.
Where it lives
| Area | Path or surface | Use it for |
|---|---|---|
| User surface | Billing invoice routes include /billing/invoices, /billing/invoices/view/:invoiceId, and object billing tab payment paths. | Day-to-day work and review. |
| Configuration | Object billing can open payment entry at /objects/:objectName/:recordId/view?tab=billing&billing_tab=addPayment&invoice=:invoiceId. | Setup, permissions, routing, labels, and behaviour. |
| Runtime/detail | Customers pay from a narrow hosted surface without receiving staff workspace access. | Testing the live experience users actually see. |
Configure it
- Confirm the audience for this surface and whether they are staff users, portal users, customers, public visitors, or administrators.
- Open the owning product route: Billing invoice routes include
/billing/invoices,/billing/invoices/view/:invoiceId, and object billing tab payment paths. - Review the configuration route and permissions before changing live behaviour: Object billing can open payment entry at
/objects/:objectName/:recordId/view?tab=billing&billing_tab=addPayment&invoice=:invoiceId. - Define the primary records, fields, statuses, owners, and notifications involved in this workflow.
- Configure Invoice payment, Object billing tab, and Portal payment first because they shape the rest of the rollout.
- Add Public hosted link and Storefront checkout only after the core path works with sample data.
- Test the runtime surface as a restricted user, not only as a superadmin: Customers pay from a narrow hosted surface without receiving staff workspace access.
- Check downstream connections after saving: Payment links connect invoices, billing records, payment providers, public access, notifications, storefront checkout, and provider webhooks.
- Record the owner, rollout date, and support path for the configuration.
- Review the first week of activity and remove any option that users do not understand or need.
Configuration options
| Option | Use when | Notes |
|---|---|---|
| Invoice payment | Customer should pay a specific invoice | Link from the Billing invoice flow. |
| Object billing tab | Staff collect payment from a record | Use the billing tab payment route. |
| Portal payment | Signed-in customers pay from portal | Pair with customer portal menu. |
| Public hosted link | Anonymous payer should not log in | Use a narrow payment surface. |
| Storefront checkout | Shopper pays for cart/order | Pair with Shop by Antly. |
| Webhook confirmation | Provider reports payment status | Verify inbound events and logs. |
Operating notes
- Keep labels aligned with the words users see in the product, especially Invoice payment and Object billing tab.
- Permissions still matter even when a menu, page, or link is visible.
- If users see empty data, check role filters, enabled apps, ownership rules, and saved filters before editing records.
- If a change affects customers or public visitors, test from a logged-out or customer account as appropriate.
- Use reports or logs to confirm the change produced the expected operational result.
- Capture configuration decisions in rollout notes so support teams know what changed.
- Do not reuse one option for unrelated processes just because it is already configured.
- Review linked notifications, workflows, dashboards, and reports after changing this surface.
- Prefer narrow changes that can be tested with sample data before a tenant-wide rollout.
- When troubleshooting, start at the route users open, then inspect configuration, permissions, and logs in that order.
- Keep retired settings hidden or archived so users do not choose outdated paths.
- Assign an owner for ongoing review; unattended configuration becomes stale quickly.
For developers
Use these pages when the surface is read or changed by code, scripts, embeds, widgets, API clients, webhooks, or realtime listeners.