Getting paid
Taking Payments & Payouts
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
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
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
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
| Field | Where it comes from |
|---|---|
| Environment | Demo while you are testing, Production for real money |
| Client ID and Client secret | Viva → Settings → API access → Smart Checkout credentials. These create the payment. |
| Payment source code | The four-digit code of a payment source, from Viva → Sales → Payment sources. |
| Merchant ID and API key | Viva → 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
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
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:
| Currency | Scheme |
|---|---|
| EUR | SEPA Core |
| GBP | Bacs |
| SEK | Autogiro |
| DKK | Betalingsservice |
| AUD / NZD | BECS |
| USD | ACH |
| CAD | PAD |
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
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
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.