Running Khaata

Take an in-person payment

Open Cashier, tap the live products to build the order, then choose Generate QR. Khaata opens a pending order with a five-minute window and displays a Solana Pay code. Leave the awaiting screen open: it checks for settlement roughly every second and a half and switches itself to the paid state.

• Awaiting: the order is open and no verified settlement has been recorded yet.
• Paid: the on-chain transfer was verified and the receipt is ready to send.
• Expired: the five-minute window closed. Check whether the customer already submitted a transaction before starting another order.
• Cancelled: checkout stopped in the app, but a transaction already prepared can still settle before its on-chain expiry.
• Payment status unknown: check the paying wallet and Transactions before asking the customer to pay again.

Share the public receipt

Every order has a receipt page that needs no sign-in: it shows the merchant, amounts, line-item snapshots, the payment signature, and any refunds. Treat the link as public. It exposes business identity, payer wallet, and the merchant's current payout address, but not business or customer email. Verify an older payment's destination from its transaction. Refund reason text is public through the receipt API, so never include private notes or contact details.

Find the right transaction

Filter Transactions by state and date range, or search it. Signatures and checkout links match anywhere in the value, while wallets, references, and order addresses match from the beginning — so paste the whole value or its opening characters rather than a fragment from the middle.

• Paid, Refunded, Partial, Pending, Expired, and Cancelled distinguish settled activity from open or stopped checkout.
• A failed status request is not proof that payment failed. Check the wallet signature before retrying.
• Results are 50 rows per page, newest first.

Check eligibility first

Only the merchant owner can refund, and only for a paid or partially refunded transaction with a recorded payer wallet and remaining refundable principal. Tips are not currently refundable: a full refund returns the sale amount, not the tip. The on-chain refund window is measured in slots, not calendar days; the default is 5,184,000 slots. After it expires, the program rejects the refund and the dashboard cannot override it.

Build an export

Owners and admins can download a CSV of up to 10,000 matching rows. Pick the date boundaries, the settlement state, and an optional wallet, signature, or reference search; the quick exports cover today, seven days, 30 days, or the complete settled ledger. There is no pagination, so narrow the date range for a period that would exceed the row cap.

Manage the catalog

Owners and admins create and edit products. Give each one a clear name, an exact USDC price above zero with up to six decimals, and an optional description; a SKU is generated for you if you leave it blank. Only live products can be sold through Cashier or a hosted checkout link.

Invite and scope a member

Owners and admins invite by wallet address, with an optional email. An invite is only for admin or cashier — owner cannot be granted — and it becomes active when that wallet signs in, because signing the message is how the person accepts. Admins can manage cashiers only: they cannot promote anyone to admin, and they cannot change or remove another admin.

• Owner: everything, including refunds, payout changes, and team management.
• Admin: products, general settings, reports, API keys, billing, and cashier members.
• Cashier: take payments, send receipts, and read Today, transactions, products, and customers.
• If a wallet belongs to more than one workspace, use the workspace switcher in the sidebar or account menu; each session stays scoped to the selected workspace.

Create and use a key

Owners and admins can create API keys under Settings, API keys. The secret is displayed once at creation and is never recoverable, so store it in a server-side secret manager. Send it from your backend as an Authorization bearer credential. A key's test or live mode follows the deployment's network and cannot be chosen.

Your wallet keys stay with you

Khaata does not ask for a customer or merchant seed phrase. The server uses a separate invoice-attestation key, but that key cannot debit your wallet. Payment sends the merchant share directly to the payout address and the fee to the treasury. Refunds and payout changes require the owner wallet's signature; dashboard access alone cannot authorize them.

The customer paid but the screen still says awaiting

First confirm they sent the exact amount in USDC on the workspace network, then look up their signature in a block explorer. If the transfer is confirmed on-chain, reload the transaction: Khaata re-checks the chain on the next status refresh and settles from what it finds, so the row catches up on its own rather than needing a replacement order. A transaction that failed on-chain is deliberately never counted as paid, even though it may still appear in the customer's wallet history.