Payments

One settlement pipeline for every channel. Whether a payment came from the storefront, a QR table, the POS or a refund, it goes through the same service and lands in the same ledger.

Providers

Payment methods are providers in a registry. Each has its own configuration schema, so adding PayPal asks for PayPal's fields and adding a bank transfer asks for your account details.

Card and hosted providers

Manual settlement types

Providers marked Coming soon are listed in the picker but cannot be selected or enabled — the card providers cannot yet initiate a charge, and gift card and loyalty have no balance validation behind them. The block is enforced on the server, not just in the interface. Each unlocks in a future update.

Configure providers under Payment Gateways — see Payment Gateways.

Redirect flows and the webhook backstop

Redirect providers take the guest away to their own page and send them back. PayPal is the one that does this today; the others follow the same path as they ship. Two things can go wrong with it, and both are handled:

• The guest returns normally. The return is verified server-side and the payment is captured.
• The guest never returns — they close the tab, lose signal, or their phone dies. The provider's webhook confirms the capture independently, and the order settles from the server side.

The webhook is not an optimisation; it is what makes the flow trustworthy. A payment that reached the provider is never lost because a browser tab closed.

Because webhooks require a publicly reachable HTTPS URL, redirect flows do not fully self-heal on a local or firewalled install. See Troubleshooting.

The transactions ledger

Payments is a dedicated admin view listing every transaction — captures, refunds and adjustments — across every channel and provider.

The ledger is gated on the payments permission, not the reports permission. That separation is deliberate: someone who reconciles the till each night needs the ledger without needing access to sales analytics.

Refunds

Refunds are issued from the POS or from the ledger, full or partial.

• Where the original payment went through a provider, the refund is issued back through that provider and the provider's reference is recorded.
• Manual settlement types are recorded as refunds without a provider call — the money moves in the real world, the record moves here.
• Every refund is written against the order and appears in the refunds tab.

Refunds triggered by an order correction carry the correction's reason with them, so the ledger explains itself. See Order Corrections.

Split payments

A single check can be settled across more than one method — part cash, part card — and each part is recorded separately. Combined with check splitting in the POS, a table can pay however it likes and the ledger still balances against the order. See Point of Sale.

What is and isn't stored

Card providers use their own hosted checkout or their own terminal, so card data never reaches your server. Provider credentials are held in the gateway configuration and are stripped from API responses.

Extending it

Providers are drivers behind a registry with two opt-in interfaces — one for redirect flows, one for webhooks. Adding a provider means writing the driver and its configuration schema; it does not mean editing the generic return handler, the webhook router or the ledger. See Payment Gateways.

See also

• Payment Gateways — configuring providers
• Stripe · PayPal · Adyen, Square & SumUp
• Point of Sale — taking payment at the counter
• Reports — payment breakdown