Skip to content
On Site & Ready

Getting paid

Taking Payments & Payouts

Card, direct debit or bank transfer — through an account we open for you, or one you already have. We take no cut of any of it.

The one rule

We never take a cut of what you collect. Whichever provider you use, the money goes from your customer to an account in your name, and the only fee is that provider's own. We are not a party to the payment and we never hold it.

Everything on this page is free and included. There is no payments add-on, no per-transaction charge from us, and no plan that unlocks a better rate.

Choosing how you take money

Everything lives under Settings → Payments. The providers are shown as a grid of tiles: each one says whether it is set up, and whether it is the one currently collecting.

Only one card provider collects at a time. You can have Stripe and Mollie both connected and switch between them, but a customer is only ever offered one "Pay now" button, so one of them has to be the answer. Switching to another provider turns the previous one off — the tile reads "Use instead" rather than "Use" when there is something to replace, because that is what the button does.

Direct debit is the exception and runs alongside whichever card provider is collecting. A mandate is standing authority to take money from a bank account rather than a checkout, so it is not competing for the same button.

Worth knowing

Taking no online payments at all is a supported answer, not a half-finished setup. Choose it and your invoices carry your payment terms and bank details instead of a Pay now button.

Cards through On Site & Ready

The option for a business with no card processor of its own. We open a Stripe account in your name, Stripe verifies your business through its own hosted form, and payments settle into that account — which belongs to you, not to us.

Setting it up

Choose "Take payments through On Site & Ready" and press the button to start. Stripe asks for your business details, a bank account and proof of identity. You can leave half way through and come back: the settings page says what Stripe is still waiting for and links straight back into the form.

Two things have to become true, and they happen at different moments: Stripe enables charges before a customer can pay you, and payouts before money can reach your bank. Both are shown on the page.

Your balance, and getting paid out

The same page shows what has cleared and what is still clearing. Card money is not available the moment it is paid — a few days is normal, and it is Stripe's schedule rather than ours.

Payouts run automatically on that schedule, or only when you press Pay out now, whichever you choose. Past payouts are listed with their amount, status and arrival date, and one that failed shows the bank's own reason — a failed payout is reversed back into the balance silently, so the reason is the only thing that explains it.

What this does not do

We do not offer instant payouts and do not shorten Stripe's schedule. New accounts start on a delay deliberately, and that delay is part of why this can be offered without us charging for it.

Your own Stripe account

If you already have Stripe, paste your own secret and publishable keys under Settings → Payments. Nothing changes about your account, your fees or your dashboard; the checkout is simply created on your keys.

Businesses already using their own keys stay exactly as they are. Nothing migrates anybody anywhere.

Mollie

For businesses in the Netherlands and Belgium especially, where Mollie is the usual answer and iDEAL is how people pay. Connect it by pasting one API key from your Mollie dashboard.

The key itself decides the environment: one beginning test_ is Mollie's test mode, one beginning live_ is real money. There is no second switch to get wrong.

Which methods your customers are offered — iDEAL, Bancontact, cards and the rest — comes from your own Mollie profile rather than from us, so it is set where you already set it. The settings page lists what your profile currently offers, so you can see that it matches what you expect.

Worth knowing

There is nothing to register in Mollie's dashboard. The address Mollie should call back is sent with each payment, so it is always the right one.

Viva.com

Cards and local methods across the EU, and among the cheapest card rates in several markets. Viva needs more from you than Mollie does, and that is Viva's arrangement rather than a long form for its own sake.

What to paste in

FieldWhere it comes from
EnvironmentDemo while you are testing, Production for real money
Client ID and Client secretViva → Settings → API access → Smart Checkout credentials. These create the payment.
Payment source codeThe four-digit code of a payment source, from Viva → Sales → Payment sources.
Merchant ID and API keyViva → Settings → API access → Account transactions credentials. Used only to fetch the webhook verification key.

The second pair is optional. Without it you can still take payments — you simply will not be told whether your webhook is set up correctly.

What to paste into Viva

Viva keeps the return addresses on the payment source in their own dashboard rather than accepting them with each payment, so three addresses have to be copied across. The settings page shows all three and names the Viva screen each one belongs on: the two return addresses go on the payment source under Sales, and the webhook lives in a different menu entirely.

The webhook needs three event types ticked — Transaction Payment Created, Transaction Reversal Created and Transaction Failed. Viva checks the address before it will accept it, which happens by itself.

What this does not do

A Viva account can only charge in the currencies it was set up for. A Greek account cannot take a pound invoice — and rather than quietly billing €480 for a £480 invoice, we refuse it and say why.

Card readers with SumUp

The one on this page that happens at a door rather than on a screen. A tech finishing a job at six in the evening opens the invoice on their phone, taps Card reader, and the customer presents a card on the SumUp reader already in the van.

What it needs

The SumUp app on the phone, signed in to your SumUp account, with the reader paired to it. That is the whole list. There are no credentials to paste and no account to connect: the money goes to whichever SumUp account is signed in on the phone taking the payment, and their own rate is all you pay.

Switch it on under Settings → Payments, where it sits as its own tile. It is off until you do, deliberately — the button hands off to an app most businesses do not have, and one that leads to "SumUp is not installed" in front of a customer holding a card is worse than no button at all.

What happens to the payment

The app hands off to SumUp, SumUp takes the card, and the result comes back on its own. The payment appears on the invoice as a card payment with SumUp's transaction code against it — which is what you search for in your SumUp account if a customer ever disputes it.

A declined card is recorded too. "The machine refused it twice" is a support call, and the attempts are the answer to it.

What this does not do

A card reader needs a connection, so this is the one part of the app that does not work offline — and it says so rather than queueing something that cannot be queued. It also runs alongside whichever provider collects online rather than replacing it: a reader at a door and a Pay now button on a portal are not competing for the same customer.

Direct debit through GoCardless

For money that is owed again and again — maintenance plans especially. Rather than chasing a card that expires, the customer authorises their bank once and the collection happens on its own.

Connecting the account

Paste a GoCardless access token, and separately a webhook signing secret so their events can be trusted. Connecting and collecting are two switches on purpose: pasting a token proves the account exists, which is not the same decision as starting to take money out of people's bank accounts.

The scheme follows the currency you bill in, because a mandate is an instrument of a national scheme rather than a preference:

CurrencyScheme
EURSEPA Core
GBPBacs
SEKAutogiro
DKKBetalingsservice
AUD / NZDBECS
USDACH
CADPAD

How a customer authorises one

From their own portal page, with no login. They are sent to GoCardless, enter their bank details there, and come back. The mandate then sits as pending for a few days while their bank confirms it — that is the scheme working correctly rather than something stuck, and the portal says so rather than showing a spinner.

Once it is active, a maintenance plan attached to that mandate is collected automatically when its invoice is raised. Nothing is ever collected against a mandate that is still pending.

The customer can cancel at any time from the same page, as the scheme requires.

What this does not do

A direct debit is not instant. A collection is created, submitted, and confirmed days later — and under the SEPA Core scheme the payer can claim it back for eight weeks with no reason given. Every attempt is recorded, so a claim that arrives long afterwards can still be matched to the invoice it undid.

Bank transfer, with nothing to connect

Every euro invoice carries a scannable QR code — the EPC standard that European banking apps already read. The customer points their phone at the invoice, their own bank app opens with your name, your IBAN, the amount and the invoice number already filled in, and they confirm.

There is no provider, no account, no fee and nothing to switch on: add your IBAN under Settings and the code appears on the invoice and in the portal. It is the bank details that were already printed at the foot of the invoice, made scannable.

What this does not do

Euro only, because the standard is a SEPA one. Nothing is confirmed back to us either — the money moves through your customer's own bank, so you reconcile it and record it against the invoice as you would any other transfer.

Recording what happened outside all of this

Cash, a cheque, a transfer that landed in your bank — record a manual payment against any invoice from its detail page. Every payment, however it arrived, goes into the same ledger with its date, method and reference, so the invoice balance, the reports and the accounting export all agree with each other.

Refunds go back the way they came where the provider supports it, and are recorded as their own entry rather than by editing the original. Expenses, VAT & Profit covers where the money then shows up.

When an invoice goes unpaid

Invoices take a due date from the payment-terms preference under Settings, and an hourly sweep raises an invoice overdue event once per invoice when that date passes.

Nothing is sent unless you have written an automation rule for it. That is what makes it opt-in, and what stops a business that never asked for it from having its name on a message the customer gets daily — set the rule up under Automations. An invoice that is paid, voided or given a new due date is only chased again if it goes late again.