Settings › Payments decides how the checkout takes money. The top of the page holds the payment-service cards and the Stripe setup (keys, webhooks) — see Project details & payments. Below them sits Payment methods, the list the checkout actually offers: Stripe, cash, cash on delivery, or an installed payment-gateway module (connected through Modules). The page is for owners and admins.
Payment methods#
Each row is one method the buyer can pick:
- Id — a short unique name (lowercase letters, digits,
-and_). The storefront sends it when the buyer picks the method, so keep it stable. - Service — what takes the money: Stripe payment (on-page), Stripe Checkout (hosted page), Cash, Cash on delivery, Bank transfer, or a payment-gateway module.
- Gateway method — only for a module: one of the methods the module lists. Picking one fills in the name and the countries the module suggests.
- Name (cs) / Name (en) — what the buyer sees; at least one is required.
- Countries and Currencies — comma-separated codes (
CZ, SK·CZK, EUR). Empty means everywhere / every currency. - Min. / Max. order total — the smallest and largest order the method accepts; empty means no limit. For a module method the values must stay inside the limits and currencies the module declares.
- Enabled — untick it to park a row without deleting it.
Add method adds a row, the bin removes one, and the list has its own Save, separate from the cards above. A list holds up to 50 rows. It is public — the storefront reads it — so it never holds credentials.
Without a list#
An empty list shows No payment methods yet — the checkout uses the services selected above: the project behaves as it did before the list existed and the checkout takes the Stripe services ticked on the Stripe card, nothing else. Create from current settings turns those services into rows to start from; nothing changes until you save.
With a list#
Once a row is saved, a checkout must pick one of the enabled rows that serve its country, currency and order total. Cash, cash on delivery, bank transfer and payment-gateway modules exist only as a row here — adding the Cash card at the top of the page is not enough to offer it. Saving an empty list goes back to the behaviour above.
Gateway modules#
A payment-gateway module you installed shows its own configuration card above the list — the same one as on its module page — and appears in every row's Service select. A module that is disabled or not yet verified is listed but cannot be picked (module disabled / not verified); a row that already uses one keeps it and shows the reason beside the service. The list cannot be saved while such a row is in it — enable the module and run Verify on the Modules page first, or give the row another service. The checkout leaves out every method whose module is disabled or unverified. When a module can tell what your account at the gateway really offers, the list asks it once on opening: a method the account does not have is marked Not active in the gateway account in the picker and on its row — switch it on at the gateway, or take the row out. If the project's plan stops including the module, its methods are hidden too, while payments already under way still finish.
Bank transfer#
Bank transfer can be picked only while the project issues proformas (Settings › Setup › Invoice › Proformas, see Invoicing); until then the service is listed as needs proformas (or why the invoicing module cannot) with a link to those settings, and the checkout leaves an existing row out. A transfer order waits Confirmed with its proforma until the money arrives — paired by the invoicing module, or Mark paid — then moves on and is invoiced at once.
Cash and cash on delivery#
An order paid in cash or on delivery is confirmed and prepared unpaid — its payment shows Pay at handover. The money is recorded later:
- Mark paid on the order page, when you have it (owners and admins);
- for cash on delivery, by itself when the carrier — or the project's order system — reports the parcel delivered, whether or not that report is set to move the order status;
- when an invoicing module pairs a payment with the order's invoice.
On the order page#
The Payment card of an order shows the service, the gateway method, the state, the amount and every payment attempt. The payment actions take effect at once:
- Refresh payment (on the status card) re-reads the live payment from Stripe or from the gateway module, for when a notification was missed. Offered for Stripe and module payments.
- Mark paid — for an order paid in cash, on delivery or by bank transfer that is not paid yet: records the payment as received, in any order status. Owners and admins only.
- Mark unpaid — takes back a payment that was marked paid by hand. A payment recorded by a delivery or by an invoicing module is not undone here. Owners and admins only.
- Payment alert — a yellow banner when a gateway module reported money the platform could not act on by itself: Paid after the order was closed, Paid, but the payment was never recorded, Refunded at the gateway, or The gateway reported a different amount. It names the gateway, its reference and the amount. Settle it in the gateway's own portal, then press Resolved — owners and admins only; the order's history records who did.
Refunds are not made from the console — use your payment provider's dashboard.
Access#
Settings › Payments is manager-only. On the order page, Refresh payment needs write on the commerce capability; Mark paid, Mark unpaid and Resolved are for owners and admins.