KoratKorat never touches this money at all
Money a customer transfers into the bank account/PromptPay set up on this page goes directly to the shop's own account — Korat is not an intermediary collecting payment on the shop's behalf, and doesn't deduct a fee from this amount. The system has no automatic bank connection to confirm money actually arrived; the shop checks the slip and confirms it themselves — full details are on the Payment gateway page.
This page is "accounts the shop receives money into", not employees' personal accounts
The payment channels on this page are the shop's accounts/PromptPay, printed for customers to see when paying — a different matter from an employee's personal bank account used to receive salary (set on each employee's own profile page, not this one), and different again from shop verification, which unlocks accepting deposits/pre-orders.
Channel types you can add
| Type | Details |
|---|---|
| Bank transfer | Account number, bank name, account name |
| PromptPay (instant transfer) | Tied to a tax ID or bank account number — a QR image can be attached |
| Cash | For shops that mainly take cash at the counter |
| Cash on delivery (COD) | For orders where payment is collected on delivery |
| Other | A channel that doesn't fit the above; describe it yourself |
You can set any channel as "default" — the one set as default is offered to customers before other channels. Channels can be paused temporarily without deleting them.
Who can edit
You need the "Manage payments" (payments.manage) permission to add/edit/delete — regular shop members (is_member_of) can only view the list. The full account number only shows when opened for editing; the list view shows only the last 4 digits.
If you press save/delete and the screen shows "Success" but the old account number is still there, that means you don't hold the payments.manage permission — the system always checks whether the write actually hit a real row, rather than just trusting the server said OK.
Shop verification — unlocking deposits/pre-orders
A separate page from payment channels — "Shop verification" verifies the shop's identity and bank account to unlock taking payment in advance, e.g. deposit invoices or pre-orders. If you just want to add a regular payment-receiving account, you can set it up without verifying identity first.
Refund requests — the full process
When a customer requests a refund for a cancelled order or booking, the request lands on the "Refund requests" page for the shop to handle — the system today only supports 2 contexts: shop orders and appointments. Other contexts (delivery, dine-in, lodging, events, packages) aren't turned on yet.
- Awaiting approval — the request comes in; the shop chooses to approve or reject it (rejecting requires a reason, which the customer sees)
- Approved, awaiting transfer — the shop transfers the refund to the customer themselves, outside the system (Korat doesn't transfer the money)
- Marked as transferred — the shop presses to mark it as transferred, attaching a slip as evidence — this is the shop's claim, not yet the customer's confirmation
- Customer confirms receipt — the case only closes completely once the customer themselves presses to confirm the money genuinely arrived
A customer can cancel their own request if it hasn't reached the approval stage yet. Every status keeps a full history — the "shop claims transferred" status is never merged with "customer confirmed received" into one and the same thing.
The amount offered for refund may have no prior proof of real payment
If the system finds no evidence the customer actually paid (e.g. cash paid at the counter with no slip in the system), the approval screen warns clearly: "using the document total as a cap instead — this does not mean a real payment happened." The shop must verify this themselves before approving.