Payment methods
Most B2B revenue is still collected on an invoice after delivery. The card and wallet methods matter for new customers, small orders and cash-in-advance business. If you configure nothing else, configure invoice properly.
Two kinds of method
| Kind | Who collects the money | Examples |
|---|---|---|
| Self-managed | You do. The platform records the intent; your bank and your accounting do the rest | Invoice (Kauf auf Rechnung), prepayment (Vorkasse), direct debit you run yourself |
| PSP-backed | A payment service provider does, through a driver | Card, PayPal, and the provider's other methods |
Self-managed methods authorise immediately, because there is nothing to ask. PSP methods can require the buyer to do something (a redirect, a 3-D Secure step), and the payment finishes when the buyer comes back.
For a Mittelstand wholesaler the realistic set is: invoice for established customers with a credit check behind it, prepayment for new customers and export orders, and one card method so a first-time buyer is not turned away.
What a method carries
Each method is a row under Order Management › Payments › Methods:
| Field | What it does |
|---|---|
code, name | The stable identifier and the label a buyer sees. labels holds translations |
kind | Self-managed or PSP |
provider, provider_method | Which PSP serves it, and which of that PSP's methods |
enabled | Whether it is offered at all |
position | The order methods appear in at checkout |
fee_type, fee_amount, fee_currency | A surcharge: none, a fixed amount, or a percentage |
countries | Restrict to specific countries |
min_order_value, max_order_value | Restrict by order value |
The three restriction dimensions are combined with AND, values inside one
dimension with OR, and an empty dimension means unrestricted. So invoice, only
for German buyers, only above €50 is countries: DE plus a minimum value,
which is the classic setup.
Eligibility is evaluated server-side
The checkout asks which methods apply for this country, amount and currency and receives only those, with fees already computed. The same evaluation runs again when the payment is created, so hiding a method in the storefront is not a control and showing one is not a permission.
That is the answer to "the buyer sees a method they should not": look at the country list and the value bounds on the method rather than at the theme.
Providers
A PSP is a row under Order Management › Payments › Providers. Adding one means adding credentials, and no code changes.
New provider rows arrive disabled and in test mode. That is deliberate: a provider nobody has configured must not transact. Run your test transactions, then turn test mode off and enable it, in that order.
Disabling a provider is usually what you meant instead of deleting it. Only the
create path reads enabled, so a disabled provider takes no new payments while
every capture, cancellation and refund on the payments it already holds keeps
working. Deleting one that payments still name is refused, with the count.
Fees
fee_type is none, fixed or percent. Whether the computed fee is shown
gross or net is a tenant setting, because the payments app has no tax semantics
of its own. Set it to match how the rest of your shop displays prices. See
Currencies and tax.
Surcharging card payments is legally restricted in the EU for consumer cards; check before you enable it rather than after.
What happens after the order
A payment runs its own lifecycle, independent of the order:
created ──► requires_action ──► authorized ──► captured ──► refunded
│ │
└─── failed └─── cancelled
The result is reported onto the order as payment_status. When you capture is a
setting: immediately on authorisation, on shipment, or by hand. Invoice and
prepayment are never auto-captured, because there is nothing to capture until
the money arrives.
refunded means refunded in full. A partial credit is handled in your
accounting system; there is no button for it here. Plan for that before you
promise a customer a 30 % credit against a card payment.The dunning clock
Invoice and prepayment are money that is owed and has not arrived. A daily scan classifies every unpaid self-managed payment against two thresholds and stamps the row with a stage (none, reminder, overdue) and the date the next stage falls due. Capture, cancellation, refund and a provider callback all stop the clock.
It classifies; it does not send. The reminder mail is yours to send, driven off the stage. Order Management › Payments carries a Run payment scan action if you want to advance it by hand.
What to check
- Place a test order with each enabled method.
- On the order's Payment tab, confirm the payment snapshot names the method and the amount matches the grand total plus any fee.
- Confirm
payment_statusmoved as you expected:openfor invoice,authorizedorpaidfor a captured card payment. - Change the order value above and below a
min_order_valueand confirm the method appears and disappears.
Next
- Shipping methods and carriers — the other half of the checkout answer.
- Payment terms — the terms behind an invoice method.