Payments

Fooodo splits payment handling into a dedicated service. The customer-facing menu app proxies to it; the payment service owns Mollie integration, PCI scope, and webhook reconciliation.

Supported methods

In production today:

• Card (Visa, Mastercard) and EU bank direct-debit
• Apple Pay
• Google Pay
• Trustly — online-banking direct pay, primarily for Nordic and Baltic markets where bank-app authentication is the default consumer flow

Mollie's full method catalogue is technically available through the same integration; only the methods above are wired into the production checkout path. Additional methods (e.g. iDEAL, Bancontact) can be enabled per deployment.

Cash is supported as a separate flow: a waiter takes cash at the table and marks the order paid directly in the Fooodo admin. The order itself flows through the same state machine; only the Mollie payment-creation step is bypassed.

Supported currencies

Fooodo settles each order in the currency configured on the restaurant. Mollie supports more than 30 currencies; the practical list for the markets Fooodo serves today:

Mollie's full catalogue (31 currencies including AUD, CAD, JPY, ZAR) is technically available; not every payment method covers every currency. EUR and the major card networks (Visa, Mastercard) work everywhere; method-by-currency support is finalised during onboarding for non-Eurozone deployments.

For Romanian deployments specifically, RON is supported via card payments end-to-end; Apple Pay and Google Pay also accept RON cards.

The payment lifecycle

Menu app	Payment service	Mollie	Guest
▶ 01Create payment for order
	▶ 02Build payload (tips · donations) and create payment
	◀ 03Return checkout URL
◀ 04Pass checkout URL through
▶ 05Redirect guest to Mollie checkout
		◀ 06Complete payment
	◀ 07Webhook callback (payment ID only)
	▶ 08Fetch authoritative status
◀ 09Notify status (queued, signed)
▶ 10Show success / cancel page

The pipeline is webhook-driven and idempotent. Mollie may retry webhooks on transient failures; replays are safe — the service short-circuits if the payment status hasn't changed since the last run.

Payment states

The payment service tracks its own state machine, parallel to the order state machine in the menu app:

Cancelled and Expired are recoverable — a guest can retry on the same order, which creates a new payment attempt against the same order.

Tips

Tips bundle into a single Mollie charge alongside the order — guests never see a second checkout for the gratuity. After payment settles, the tip lands in your POS as a separate tip line on the order so reporting and tip-out flows work as they always did. The POS revenue code used to represent tip income is set per-restaurant in the admin (R-Keeper is the live reference connector for this; other POS connectors expose the same setting through the connector contract).

Donations

Donations work the same way: a single Mollie charge to the guest, but the donation portion is routed to a separate organisation account inside Mollie (Red Cross is the live reference example). From the guest's perspective it is one transaction; from the operator's perspective the donation does not show up in restaurant revenue or in your POS sales reports — it lands cleanly in the partner organisation's books.

Webhooks

Two webhooks are involved:

• Mollie → payment service. Public endpoint that receives only a Mollie payment ID. The service then calls Mollie's API to fetch the authoritative status — so a forged callback cannot move money or change order state. (This is the standard Mollie integration pattern; their callbacks are intentionally minimal.)
• Payment service → menu app. Bearer-token authenticated, per-deployment secret. This is the channel that actually flips order state on the menu app side.

If you are operating a Fooodo deployment, the menu-app secret is provisioned during onboarding. If you are integrating against Fooodo as a partner, you will not normally see either of these.

What partners see

Partner integrators do not integrate with the payment service directly. The contract is:

• You call the menu app's order-creation API.
• You receive an order and (when payment is required) a checkout URL.
• You do not handle card data, do not call Mollie, do not need PCI scope.

This is one of the load-bearing reasons the payment service exists as a separate boundary.

Refunds and reversals

Refunds are an operator action — guests cannot request them from the app. Depending on your deployment, refunds are issued from the Mollie dashboard or the payment-service admin panel. There is no customer-facing refund flow today.