Online Payments

Online payments let a client pay an issued invoice by card or bank debit. The money goes to your organisation’s own Stripe account, not to Runnit, and Runnit never sees or stores a card number.

Before a client can pay

Two things have to be true, in this order:

1. Merchant payments have to be available on your Runnit deployment. This is platform configuration, not something an organisation sets up. Where it is not available, every read still works and the reason given for not offering payment is that the platform is not configured.
2. Your organisation has to connect its own Stripe account, and Stripe has to have enabled charges on it.

Until both are true, invoices issue and send exactly as they do now, and payments are recorded by hand or imported from Xero. See Invoices and Getting Paid.

Whose money it is

The connection is to your organisation’s own Stripe account, joined to Runnit through Stripe Connect. Your client pays you directly: you are the merchant of record, the money lands in your Stripe balance, and Runnit never holds client funds at any point.

Card details are entered on Stripe’s own payment form. They never reach Runnit and are never stored by Runnit. For a saved payment method, Runnit keeps only what it needs to show you which one it is: the brand, the last four digits and the expiry.

This is a completely separate arrangement from what your organisation pays Runnit. Your Runnit subscription lives under Billing and shares nothing with it: different account, different credentials, different records. Disconnecting one has no effect on the other.

Connecting Stripe

Connecting, refreshing and disconnecting need finance:manage_integrations.

Starting a connection sends you to Stripe to authorise it, then brings you back. The return is bound to the organisation, the person and the browser that started it, so finishing the connection somewhere else is refused. The stored credential is encrypted and is never returned by any Runnit route or shown on any screen.

Once the account is connected you can:

• Refresh it to pull the account’s current capabilities from Stripe.
• Enable it. Enabling re-checks with Stripe first. If Stripe has not enabled charges on the account, for example while it is still collecting verification details, enabling is refused and says so.
• Set the statement descriptor, which is what your client sees on their card or bank statement.
• Record your own webhook signing secret, if you register the endpoint in your own Stripe dashboard rather than using the platform endpoint.
• Disconnect it. This deauthorises Runnit at Stripe and then clears the stored credential.

Each client’s billing profile has an allow pay now switch, on by default, so you can take a single client back offline without disconnecting the account.

When pay now is offered

Payment is offered on an issued invoice only when the platform is configured, an enabled connection exists, the client’s profile allows it, and there is a balance left to collect. Where any of those is not true, the invoice behaves exactly as it does today and the payment status says which one it is.

Paying happens in the client portal, where the client signs in. The link you share on an invoice shows the document, the PDF and a way to ask a question, and it does not take payment. See Client Portal Billing.

What a payment attempt is

Runnit does not attach a payment to the invoice document. It attaches it to a payment attempt, which carries the amount actually collectable at that moment: the amount due, less anything already authorised and still in flight.

That has a few consequences worth knowing:

• Two tabs do not start two payments. An invoice can have only one live attempt, so a second tab adopts the first one instead of racing it. The same is true of a person and a background retry arriving at the same time.
• If the balance moves, the attempt moves with it. Credit the invoice part way and the amount to pay drops. Credit it in full and the attempt is cancelled.
• A payment that arrives after the invoice closed is kept. If a credit note closed the invoice while a payment was in flight, the payment still gets its receipt and the money becomes client credit you can apply elsewhere. Money that arrived is never rejected after the fact.
• Issuing never waits for Stripe. If Stripe is unreachable, the invoice still issues, sends and renders. Pay now appears a moment later, once the connection catches up.

Cards, bank debit and saved methods

Which methods are offered depends on the billing entity’s country: cards everywhere, plus BECS Direct Debit in Australia, ACH in the United States, Bacs in the United Kingdom, and SEPA Direct Debit in Ireland, Germany, France and the Netherlands.

A client can leave a card or bank account on file. Runnit records the consent and shows the method as brand, last four digits and expiry, nothing more, and you or the client can revoke it at any time.

Runnit does not charge a stored method by itself. Charging one is a deliberate action, and it still waits for the notice below.

Every bank debit needs its own notice

Bank debit rules require the payer to be told before money is taken, so Runnit sends an advance notice for each debit, not once for the stored method. The notice names the exact amount, the currency and the date the debit will be taken.

Change the amount or the date and it is a different debit: the old notice is superseded and a new one has to be delivered before anything moves.

Immediately before charging, Runnit checks the notice again. A charge waits, rather than failing, and says which of these it is waiting on:

Waiting on	What it means
Consent	The stored method was revoked, has expired, or has failed
A recipient	There is no billing contact to send the notice to
Delivery	The notice has not been accepted by the mail provider yet
A failed notice	The notice bounced or the address is suppressed
The notice period	The notice went out, but the required days have not passed

The notice periods Runnit waits by default are three days for BECS, Bacs and ACH, five days for SEPA, and none for cards. Your own scheme rules may require longer; where a stored method records a longer period, the longer one wins.

Surcharges

Surcharging is off by default. When you turn it on for a billing entity, you set a rate per payment method, optionally a fixed amount, the disclosure text the client reads, and the tax rate it carries.

A surcharge is never added to the issued invoice. It is charged on top of it and recorded against the payment attempt, so the amount owed, the surcharge, Stripe’s fee and any platform fee stay four separate figures that reconcile independently. A refund returns the surcharge in proportion.

Caution

Where the law prohibits a surcharge, no setting overrides it. Card surcharging in Australia is prohibited from 1 October 2026, and from that date Runnit will not add one to a card payment for an Australian entity whatever the policy says.

Fees

Three figures are recorded against every payment: the gross amount, Stripe’s own processing fee, and the Runnit platform fee. The platform fee is zero by default, and only a Runnit platform administrator can set an override for an organisation. Whatever applies is fixed onto the attempt when it is created, so a retry always uses the fee that applied when the payment started.

Stripe sometimes confirms its fee after the payment itself. Until it lands, the fee reads as pending rather than as zero, and the nightly reconciliation fills it in. A fee that lands late never causes a second payment to be recorded.

Processing is not paid

Card payments confirm immediately. Bank debits do not: an authorisation is a promise, not cash. Runnit tracks that as a collection state on the invoice rather than as a status, which matters because it keeps every other figure honest.

While money is processing:

• it is not counted as paid, and stays out of cash, revenue and any commission it would otherwise trigger;
• the invoice’s status, ageing and reminders read exactly as they did; and
• the amount is taken out of what is collectable, so nobody can pay it twice.

Runnit records when the rail settles (the same day for cards, three days for BECS and Bacs, four for ACH, five for SEPA) and when reversal stops being possible. That second window is much longer than most people expect: 120 days for cards, 60 days for ACH and about 13 months for SEPA, while Australian and UK direct debit claims can be raised for years. If the debit fails or is cancelled, the amount goes back to zero and the invoice is collectable again.

Refunds and disputes

A refund can never exceed what was actually settled. Partial and repeated refunds are supported, and each one reverses the original allocation line by line, including each tax component, with the surcharge and platform fee returned in proportion.

A dispute is not a refund. When one is opened, Runnit flags the invoice and pauses its reminders, and moves no money. Money moves only if the dispute is lost, and only once. A dispute you win clears the flag and changes nothing financially.

Closed periods

If a settlement’s economic date falls in a period that is already closed, it is neither discarded nor forced into the closed period. It is held, with its full detail and its original date, and somebody with finance:record_payments posts it into an open period with a reason. The record keeps the date the money actually moved. See Month End.

Missed messages from Stripe

Runnit records everything Stripe sends and processes it separately, so a message is never lost because processing failed. A failure is retried with a growing gap rather than dropped, a message that arrives twice records once, and anything Stripe never delivered is picked up by polling. A replay from the Stripe dashboard is safe.

Deposits at acceptance

A quote can ask for a deposit when the client accepts it. Acceptance then issues one deposit invoice and offers it for payment. The deposit is a percentage of the accepted net and is split across the same tax rates as the work, so a quote priced at several rates produces a deposit with several lines. Retrying returns the same deposit invoice and the same payment attempt rather than a second one, and the acceptance itself is kept whatever happens next: if the deposit cannot be issued, for example because the period is closed or it needs approval, the signed acceptance still stands. See Quotes.

Recovering credit after a receipt is removed

If a removed receipt had credit already used or money already refunded, Runnit records a separate recovery balance. Unused credit is cancelled and the remaining invoice payment is undone on the reversal’s posting date. You can inspect and record repayments under Receipt recoveries. See Getting Paid. This does not change the release requirements for online payments above.

Next step

Split an overdue invoice with Payment Plans, or see what the client sees in Client Portal Billing.

Help from Ru

Ru can explain payment states and read the information you are allowed to see. Connecting payment accounts, granting standing payment authority and executing provider charges remain in the payment workflow. A manual payment record made through Ru does not move funds. See Finance with Ru.