How payments work

Every confirmed booking has one payment record that tracks what the guest owes, what has been received, and how the money is split between you and (in marketplace mode) the property owner. This page explains the vocabulary you’ll see across the console; the day-to-day tasks live in Payment providers and Partial payments and refunds. When a guest can pay, what happens when they don’t, and whether unpaid dates are eventually let go are all one rule — see When you collect.

Payment legs

A booking’s total is collected in one or more legs. Which legs exist depends on how you’ve set up payments:

Down payment — a share of the total collected upfront when the booking is created. Not to be confused with the listing’s security deposit: a down payment is real money on the booking and counts toward the total, whereas the security deposit sits outside the payment legs entirely — see Discounts and fees.
Balance — the remaining amount, due closer to check-in.
Full payment — the whole total in a single leg (when no down payment split is used).
Supplement — an extra charge added when a booking is modified upward.
Tourist tax — a city/tourist tax leg, when the listing’s place charges one. See Taxes and VAT.

Each leg is a line on the booking’s Payment card and in the Payments list, with its own amount, due date, and status.

Payment statuses

A booking’s payment moves through these statuses:

Awaiting payment — due, but nothing received yet.
Partially paid — some money in (e.g. the down payment is paid but the balance isn’t).
Paid — the full amount is settled.
Cancelled — the booking was cancelled and outstanding charges voided.

Individual legs (transfers) show as Pending or Paid, with a Partially paid badge once part of a leg has been received.

Direct vs marketplace mode

Your operator mode is set when your account is created. You can see it under Settings → Payments, where the Operator Mode section is read-only — there is no switch for it in the console. If you picked the wrong one, contact Reynt: a workspace can still be moved while it is empty. Once it has bookings, payments, invoices or guest registrations the mode is fixed for good, because refunds and reporting are derived from it. It decides whether you’re renting your own properties or operating on behalf of owners:

Direct mode — all money goes to you (the operator). There is no owner split and no commission.
Marketplace mode — the booking is split between you and the property owner. You keep a platform commission (the Commission Rate, e.g. 15%, under Settings → Payments) and the owner receives the rest.

Who collects the money

Settings → Payments asks this above the payment methods, because it isn’t a property of a method — it’s a term of your agreement with an owner. It decides who the guest’s contracting party is, who invoices them, whose VAT applies, and whether your commission is netted at source or billed afterwards. There are three answers:

Everything to you — the guest pays you the whole booking. You keep your commission and pay the owner their share yourself, outside Reynt.
Everything to the owner — the guest pays the owner the whole booking. You invoice the owner for your commission afterwards.
Split — the guest pays twice: your commission to you when they book, the rest to the owner. Nothing you owe the owner ever passes through your account.

Under a split, one further checkbox asks whether the owner takes their share in cash — handed over at check-in instead of travelling on a payment method. Your commission is still paid online when the guest books; Reynt records what the owner is owed and you confirm it arrived. It’s a property of the owner’s leg only: your own leg is never cash, and a down payment handed over at arrival would secure nothing.

Confirming is genuinely optional, and nothing pushes you to do it. A cash leg is never chased — the guest hands it over at arrival, so there is nothing to remind them about — and it is left out of Overdue Payments too, because a stay that has already happened would otherwise sit there as a debt forever. That is deliberate: the money went from the guest straight to the owner and never touched your account. What you are owed, the commission, arrived when the guest booked. The owner’s settlement invoice states the cash amount whether or not you confirmed it, so an owner who did not receive it has a document to query — which is where you would hear about it.

In direct mode there is exactly one settlement and no owner to route to, so the question isn’t shown.

Separately, each payment method you enable — Bank Transfer, Mollie — has its own panel, and one of them is marked Default: that’s the method new bookings start on. In the split arrangements the down payment equals your commission and goes to you, while the balance goes to the owner. The commission also drives the owner settlement invoice.

When one owner is different

What you set here is your default, not a rule. In marketplace mode an individual owner can collect differently — see Payment terms for one owner. Their bookings are quoted, invoiced and settled on their own terms, from the price a guest sees on your storefront through to the payment record; everyone else keeps following your default.

What a guest chooses

If you have more than one payment method switched on, a guest picks between them at checkout. With one method there is nothing to choose and Reynt shows no such question, which is what most workspaces see today.

Two things a guest never chooses:

Who collects the money. That is a term of your agreement with the owner, not a checkout preference, so every option they see settles the same way.
An option you cannot honour. Reynt checks each method is actually payable before showing it — Mollie on an account that cannot yet accept payments simply does not appear. It re-checks when the guest submits, so an account cleared in the meantime cannot slip through.

When a guest accepts an offer you sent, they can only pick a method that keeps the payment schedule the offer email already quoted. Otherwise the amounts they were told would change after the fact.

Where you see payments

Dashboard → Money — the Outstanding Payments and Overdue Payments cards roll up what’s still owed across every booking. The figures net out any not-yet-collected price reduction from a downward modification, so they agree with what each booking’s own Payment card shows as owed rather than the original (gross) charge. Cash-on-arrival legs are not counted — that money never comes to you, so a stay that has already happened would sit there as a debt you cannot collect. The booking’s own Payment card still shows it.
Booking detail → Payment card — the money flow for one booking. Each line reads payer → recipient via method (e.g. the guest → Operator via bank transfer), with the total due, total paid, and remaining, and lets you mark a leg paid. A Partially paid badge and a “received X of Y” line appear once part of a leg is in.
Finance → Payments — a list of every booking payment with its Reference, Provider, Amount, Status, and Created date. Filter by status to find what’s outstanding.
Payment detail — open a payment to see the parties (payer, listing, owner), each transfer’s money flow, and the actions for recording payments, refunds, and discharging refunds.

The booking’s Activity → Payments timeline records every individual charge, receipt, refund, and void with its cause and target, so you always have a full audit trail of the money movements on a booking.

“A booking’s payment record doesn’t add up”

Every night we check each booking’s payment history against what it says is owed. If the two disagree, a critical alert appears on your dashboard naming the bookings and the amount involved.

It is the only critical alert there, and the distinction is worth keeping: every other alert is a task you have not done yet, while this one says two records of the same money contradict each other.

It is a night-old answer. The alert prints when it was last checked — something you fixed this morning is still listed until tomorrow’s run.
There is nothing to dismiss. Repair the booking and the alert is gone on the next run. That is deliberate: an acknowledge button would let a real discrepancy be waved away instead of fixed.
Open the booking’s Activity → Payments timeline to see which entries disagree. If it is not obvious, this is worth asking support about rather than adjusting by hand.