XKOVA Docs
Payments
The Payments area is where an operator reviews direct sends and follows each one from creation to a confirmed on chain state. It is the console view over the same payments API your backend can call directly.
What this area covers
The Payments list shows direct sends for the active workspace. Escrowed payments live in a sibling area, because they hold funds until a recipient claims them. For the concepts behind both, see Payments and Escrow and Claims in the XKOVA SPS section.
Before you can send
A payment will not mint until the workspace has the right setup in place. If you have just signed up, the dashboard checklist walks you through it. In short, you need an enabled token and a committed fee schedule, and you need an account holder to act as the sender.
- An enabled token. Only tokens on the workspace allowlist can move. Enable one in settings.
- A committed fee schedule. The payments path is rejected until a fee schedule prices the send. Commit one in settings.
- An account holder. The member who signs the transfer. Your backend can provision these on member sign in.
How a payment moves
Sending is never a single write that moves money. The application creates an intent, the account holder signs it in their own wallet, the XKOVA Relayer submits the signed instruction and pays gas, and XKOVA confirms the result on chain. This is what keeps the send non-custodial. The full mechanics are in the Non-custodial Model.
- The payment is created and runs the compliance pipeline; once allowed, it enters a pending sign state.
- The holder signs the transfer intent (and a permit) in their wallet.
- The XKOVA Relayer submits the signed call on chain.
- XKOVA observes the result on chain and the payment becomes confirmed. A webhook fires on state change.
Working the list
The list shows each payment with its status and counterparties. Click a row to open the payment detail, where you can see its current state, the amount, the parties, and its progress through signing, relay, and confirmation. Use the detail view to confirm a payment reached a terminal state rather than guessing from the list alone.
Status and what it means
The console groups the payment lifecycle into four display states; the detail view shows the underlying step within each.
| State | Meaning |
|---|---|
| Queued | Created and working through pre-flight: quoting, the compliance screen, and any required approval. |
| Pending | Cleared pre-flight and in motion: waiting for the holder's signature, or signed, relayed, and awaiting on chain settlement. |
| Success | Settled on chain with a verified success flag. The terminal success state. |
| Failed | Did not complete: blocked by compliance, cancelled, or the transaction did not succeed on chain. The amount did not move. |
The value-movement firewall
Every payment (and treasury transfer) is checked against the workspace's committed authorization policy before it can move: a default-deny rule set built from closed rule types such as destination allow and deny lists, amount caps, velocity limits, counterparty risk, and required-approval rules. The Firewall area is where an operator views the active policy, builds a draft, simulates sample transactions against it, and commits it; a committed policy is immutable, so changing the rules means drafting and committing a new one (the commit itself can be governance held). Every allow or deny decision the firewall makes is recorded in a decision log the operator can review.
Related
For the exact request and response shapes, see the operations list or the interactive reference. To send programmatically rather than from the console, see the XKOVA SPS overview and the SDK workflows. To get notified when a payment changes state, see Webhooks.