A checkout session created from the invoice's balance, returning a hosted payment URL. The button only appears when a payment provider is connected and the invoice is in a payable state with a positive balance. Returning from checkout confirms server-side and then re-polls so the status and balance catch up.
Also called: take a card payment · pay online · stripe checkout · customer pays the deposit
- 1POST /api/client-portal/invoice/pay authorises on the invoice's portal token and creates a session
- 2Return redirects are built from the host the customer is actually on, so sub-account domains land back correctly
- 3On return with a session id, a confirm call verifies the session server-side, then the page re-polls four times
- 4Inside the dashboard modal the checkout opens in a new tab, because checkout refuses to load framed
- 5Coming back to the dashboard tab refetches so the modal updates in place
Getting paid meant waiting on a cheque or talking a customer through bank details over the phone, for a bill they were already looking at. Customers pay by card from the invoice itself. Payment is confirmed server-side as the primary path so it works in every environment, with a webhook and a reconcile pass as backups that cannot double-count, and a customer on a builder's own subdomain lands back on that builder's portal rather than the platform's. The checkout is never framed, because the payment provider refuses to be embedded and the customer would otherwise be staring at a blank box where the card form should be.
- Payment friction on a document the customer already has open
- A pay button that fails on press for builders with no provider
- Payments that do not reflect until a webhook lands
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →