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 move 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 a compatible asset from the automatic catalog, a committed fee schedule, and an account holder to act as the sender.
- An eligible and certified asset. Read the automatic asset catalog and select one whose exact direct-send flow is rails eligible and runtime certified.
- 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 and freezes an intent, the configured account-holder wallet produces its signature, XKOVA verifies the exact signer and payload, the XKOVA Relayer submits the accepted instruction and pays gas, and XKOVA confirms the result on chain. XKOVA never receives or exports the human wallet's MPC private-key material. The full trust boundary is in the Non-custodial Model.
- The payment is created and runs the compliance pipeline; once allowed, it enters a pending sign state.
- The holder authorizes the transfer intent and permit through the configured wallet ceremony.
- 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.