About Intents

Every payment network speaks a different language. ACH has batch files. Card networks have authorization and capture flows. Real-time payment schemes like Pix or SPEI have their own message formats, their own error codes, their own settlement rules. Mobile money platforms work differently from all of them.

For teams building payment products, this means a separate integration for every rail. Different APIs, different error handling, different reconciliation processes, different ways to know whether a payment actually landed. And every time a new network comes along, the cycle starts over.

An intent makes all of that someone else's problem.

One instruction, any payment

An intent is a single instruction that describes what should happen: move a specific amount of a specific currency from one wallet to another. That's it. The ledger figures out the rest — which network to use, what protocol to speak, how to coordinate the settlement, and how to handle failures.

At its simplest, an intent looks like this:

{
  "handle": "pay-maria-2026-03-22",
  "claims": [
    {
      "action": "transfer",
      "amount": 50000,
      "symbol": { "handle": "cop" },
      "source": { "handle": "sav:98765432@mybank.co" },
      "target": { "handle": "sav:42424242@otherbank.co" }
    }
  ]
}

One instruction. The ledger handles the routing, the protocol translation, and the settlement coordination with every system involved.

The same intent structure works whether the payment is a peer-to-peer transfer between two people, a business paying thousands of suppliers, a cross-border remittance that touches two currencies, or an interbank settlement between financial institutions. There is no special SDK for card payments and a different one for bank transfers. There are no diverging code paths per rail. One integration handles everything.

For engineering teams, this collapses what would traditionally be months of integration work per payment network into a single pattern that works everywhere. For operations teams, every payment — regardless of how it was routed or which systems it touched — looks the same, has the same lifecycle, and can be tracked the same way.

Claims: composing movements

Each intent contains one or more claims — the individual balance movements to execute. A single claim is a basic transfer: debit one wallet, credit another. But claims can be composed to handle more complex operations in a single instruction.

Need to pay a recipient and collect a processing fee at the same time? Two claims in one intent. Currency exchange that debits pesos and credits dollars across two parties? Multiple claims. Marketplace payout that splits a payment between a seller, a platform fee account, and a tax withholding wallet? All one intent.

The key property is atomicity. Either every claim in the intent succeeds, or none of them do. There is no state where the fee was collected but the payment wasn't delivered, or where one leg of an exchange completed but the other didn't. This eliminates an entire class of consistency problems that traditionally require reconciliation jobs, manual intervention, or custom rollback logic.

What happens when you submit an intent

Behind the scenes, an intent moves through a defined lifecycle from submission to settlement:

If an intent reaches Prepared but a participant cannot commit — due to a timeout, a system failure, or a validation error — the ledger automatically rolls back all participants. There is no manual intervention required for stuck payments. The ledger enforces a configurable timeout on the prepare phase, after which it triggers an automatic rollback across all systems.

Each intent carries a unique handle that you choose when you create it. This handle doubles as an idempotency key — if a network glitch causes a retry, submitting the same handle again won't process the payment twice. This is a small detail that eliminates a large category of production incidents.

Clearing across systems

The real power of intents shows up when a payment crosses institutional boundaries — when it touches a bank's core system, a national payment switch, a card network, or a mobile money platform.

In traditional architectures, this is where things get fragile. One system confirms the debit, but the credit fails on the other side. Now you have money in limbo, a reconciliation ticket, and someone manually sorting it out the next morning. Multiply that by thousands of daily transactions across multiple networks, and reconciliation becomes a full-time job for entire teams.

The ledger eliminates this with a two-phase commit protocol — a coordination mechanism where every participant first prepares and reserves funds, and only after all parties have confirmed does the ledger commit the final result. If anything fails at any point — a timeout, a validation error, an external system going down — everyone rolls back together. There is no "cleared on one side, pending on the other."

This is where the conversion rates come from: the ledger retries and coordinates automatically instead of failing silently. And this is where the reconciliation savings come from: every system either commits or rolls back as one, so the books always balance.

What's next

See Send a Payment to submit your first intent, or About Anchors to understand how simple identifiers like phone numbers and emails resolve to the right accounts automatically.