Step-by-step instructions
Orders can be paid with clear method labels, correct cash or non-cash behavior, accurate commissions, and the right account or integration routing.
Use the interactive screenshot walkthrough first. Switch steps with the step dots, then read what to fill and why it matters.
Payment method examples
Use these examples as starting presets, then adjust visibility, accounts, fees, and integration settings to match the real business process.
Cash
- Non-cash: off
- Pay online: off
- QR: off
- Integration: empty
- Account: cash drawer or safe
Why: Use for physical money collected by staff. It should affect cash drawer and shift reconciliation.
Card
- Non-cash: on
- Commission: provider fee if needed
- Pay online: off for terminal-only
- Integration: optional
- Account: card terminal or acquiring account
Why: Use when staff confirms a card terminal payment or records card collection separately from cash.
QR
- Non-cash: on
- QR: on
- Pay online: on if QR opens payment flow
- Visible in app/web: only where customers scan
- Account: QR or bank settlement account
Why: Use when customers scan a QR code to pay from a phone, bank app, wallet, or payment link.
Integration
- Non-cash: on
- Pay online: on
- Integration: provider selected
- Webhook/status: required
- Account: provider settlement account
Why: Use for Stripe, North, bank acquiring, or another provider where SABSUS must wait for external confirmation.
Fields on this screen
Icon
How to fill: Use a visual icon that matches the payment type: cash, card, QR, or provider logo.
Why: Cashiers recognize the method faster and customers understand checkout options.
Name
How to fill: Write the method name in every enabled language, for example Cash plus the local-language cash label.
Why: Receipts, POS, customer app, and reports use this label.
Account
How to fill: Choose the finance account where this payment should be posted.
Why: Cash should not be reconciled together with card processor settlements.
Non-cash switch
How to fill: Turn it on for card, QR, bank transfer, and integrations; leave it off for physical cash.
Why: Shift close and cash drawer logic depend on this difference.
Commission
How to fill: Set percent and fixed fee only when the processor or business charges one.
Why: Fees affect customer totals, net revenue, and reports.
Client pays commission
How to fill: Enable only if the customer, not the business, should pay the method fee.
Why: This changes what the customer sees at checkout.
Visible in app / web
How to fill: Enable only where customers should be able to choose the method.
Why: Internal methods should not appear in customer screens.
Self-service
How to fill: Enable only for methods that a customer can complete without staff help.
Why: Kiosk checkout must not show methods that require manual cashier confirmation.
QR
How to fill: Enable for scan-to-pay methods or static QR collection.
Why: This tells staff and customer screens to use QR-specific behavior.
Pay online
How to fill: Enable for methods that create or confirm a digital payment.
Why: Online checkout and integrations depend on this setting.
Integration
How to fill: Choose a provider only for processor-backed methods.
Why: Provider methods need API credentials, account status checks, and webhook confirmation.
Save and test
How to fill: After saving, create a small test order and check the receipt and finance report.
Why: This proves the method works end to end, not just that it exists in settings.
Common mistakes
- Creating card or QR as a cash method, which makes cash drawer reports wrong.
- Enabling Pay online without selecting or configuring the required integration.
- Using one finance account for cash, terminal, QR, and integration settlements when reporting needs them separate.
- Showing an internal payment method in the customer app or web checkout by mistake.
- Changing a method name and assuming old orders changed too; order payments keep their own snapshot.
- Treating a provider-created payment row as paid before webhook or provider status confirms it.
AI Agent Field Reference for implementation
This block is intentionally below the human instructions. It explains storage names and downstream dependencies for automation, support, and future AI agents.
| Field | Stored as | Purpose | Why it matters |
|---|---|---|---|
| Payment method ID | payment_methods.id | Unique identifier for the configured method. | Orders store this reference in payment rows; duplicate or unstable IDs break reconciliation. |
| Company | payment_methods.company | Workspace that owns the method. | Prevents payment methods from leaking between companies. |
| Method name | payment_methods.name | Visible name such as Cash, Card, QR, or Stripe. | Staff and customers choose the method by this label, so every enabled language needs a clear name. |
| Icon / photo | payment_methods.photo | Visual icon shown on checkout and method lists. | Icons speed up cashier work and reduce method selection mistakes. |
| Account | payment_methods.account / accounts.id | Finance account where collected money is posted. | Cash, card terminal, QR, and online integration payments should land in separate accounts when reporting requires it. |
| Non-cash payment | payment_methods.non_cash_payment | Marks card, transfer, QR, and online payments instead of cash. | Cash drawer, shift close, and finance reports depend on this flag. |
| Commission percent | payment_methods.commission | Percentage fee for the method. | Explains processor fees, net revenue, and customer-paid commission scenarios. |
| Fixed fee | payment_methods.fixprice | Fixed amount added or tracked for the method. | Some providers charge a fixed fee in addition to percent commission. |
| Client pays commission | payment_methods.clientPay | Defines whether the customer pays the payment fee. | Changes final customer amount and receipt explanations. |
| Visible in app | payment_methods.available_in_app | Shows the method in app-facing checkout. | A method can be available for staff but hidden from customers. |
| Visible in web | payment_methods.web | Shows the method in web checkout. | Web checkout may have different methods than POS or mobile app. |
| Self-service visibility | payment_methods.selfs | Shows the method on kiosks or self-service screens. | Customer-operated checkout should only show methods that can be completed without staff help. |
| Pay online | payment_methods.pay_online | Marks the method as capable of online payment. | Required for payment links, online checkout, app payment sheets, or provider-created payment sessions. |
| QR payment | payment_methods.qr | Marks the method as QR-based. | Controls scan-to-pay presentation and QR payment instructions. |
| Integration | payment_methods.integration | External processor or integration key. | If filled, payment success may depend on provider connection, account status, webhooks, and API responses. |
| Tax flag | payment_methods.tax | Defines whether payment fees or payment rows participate in tax-related logic. | Receipts and totals can be wrong if fee tax behavior is unclear. |
| Active / visible status | payment_methods.active / visibility flags | Controls whether the method can still be selected. | Disable unused methods instead of deleting methods that historical orders reference. |
| Order payment snapshot | orders.payments[].methodPayment | Copy of the selected method stored on the order. | Historical orders keep the method context even if the method is later renamed. |
| Order payment amount | orders.payments[].amount | Actual amount paid with this method. | A configured method is not a transaction; collected money is proven by the order payment row. |
| Paid status | orders.payments[].paid | Shows whether the payment row is completed. | Online and integration payments can be pending until provider confirmation arrives. |
| Provider status | integration payment status / webhook status | External payment state when integration is used. | Agents should verify provider status before saying an online payment is complete. |
| Updated at | payment_methods.updated_at | Last update time for the method. | Recently edited methods can create cache or display differences until refreshed. |
Related guides
Use these guides to connect this section to adjacent SABSUS workflows.