Loading
Platform · Agentic Payments
Agents decide. Mesta settles.
Your software already decides who gets paid, how much, and why. We turn those decisions into settled money — payroll, suppliers, sellers, treasury — landing in local-currency accounts across 13 live corridors, under our licenses and regulated partners. $2.1B settled to date. Now we’re opening those rails to your software.
The shift
Software is about to make far more payment decisions than people ever did.
Sourcing, negotiating, invoicing, approving — the work upstream of a payment is being automated fast. Every bit of that automation ends in the same place: money has to actually move, to a real account, in a country with its own rules.
That last step doesn’t get easier as intelligence gets cheaper. It stays exactly as hard as it is today — and there is about to be far more of it.
We built the part that carries it. Now we’re making it something software can operate directly.
Running today
The engine is already built to be driven.
Every payment here already executes as software: fixed steps, versions, types, approvals. Opening that to your agents is an interface project, not a rebuild.
150 versioned workflows
Every payment executes as a versioned workflow across our services and provider network — replayable end to end, with human approval available as a step inside the flow.
Intelligence already in the loop
We read and validate invoices and onboarding documents against each destination country’s requirements, reconstruct failed payments across services and propose the fix, and assist compliance review at volume.
A licensed last mile
40+ currencies and 13 live corridors, fiat and stablecoin, into a real account in local currency — under permissions that took years to hold.
The architecture
How an intention becomes settled money.
Three layers. A request gains certainty at each one, and arrives as money in an account on the other side of the world.
01
Intent
What should happenAn outcome gets described — by your backend, an operator, or a model reading an invoice. This is the layer where intelligence works: extracting, mapping, drafting, investigating.
Document extractionField mappingDraftingInvestigation
Models work here. The two layers below are code.
02
Control
What is permittedThe request meets identity, limits, corridor eligibility, funding and approvals. It leaves this layer bounded, attributed, and recorded — or it does not leave at all.
IdentityLimitsCorridor rulesFundingApprovals
Now it is an authorized instruction, with its bounds attached
03
Settlement
What actually movesQuote, route, disburse, confirm, reconcile — across licensed fiat and stablecoin rails, into a real account in local currency, reconciled to the cent against what the provider says happened.
QuoteRouteDisburseConfirmReconcile
What cross-border actually demands
The hard part was never calling the API.
These are the constraints that decide whether an automated payment lands or sits in an investigations queue for nine days. Each one shapes how we build.
01
A purpose code is a regulatory declaration
India, Brazil, South Africa, Vietnam, Indonesia and Korea all require a purpose-of-payment code. The wrong one gets the payment returned — or creates a problem for the person receiving it.
How we build for it
Purpose codes are a constrained, per-corridor enum, validated before submission. A model can suggest one. The enum is the only author.
02
A valid plan can still be impossible
A run scheduled Friday afternoon misses the local RTGS window and lands after a public holiday somewhere else. Several currencies cannot be priced at all outside their local session.
How we build for it
Cut-offs, value dates and settlement calendars are a validation layer, not a footnote. We reject an impossible plan before it becomes a stuck payment.
03
Repair is a data problem, not an FX problem
An IBAN check digit, a wrong CLABE branch code, an invalid IFSC, a missing tax ID. A small share of every cross-border book needs human intervention, and it is the largest driver of operations work.
How we build for it
A field-level error taxonomy the whole platform shares. The model reads the rejection and proposes the corrected field; deterministic validation checks it; a person applies it.
04
What was sent is not what arrives
Charge-bearer terms and intermediary deductions decide what actually lands. “My supplier received 19,955 instead of 20,000” is the most common complaint in this business.
How we build for it
We model the guaranteed amount separately from the amount sent — so a promise about what lands on the other side is a commitment we can hold, not an estimate.
05
The beneficiary is not our customer
We screen a person we have no relationship with, on data our customer supplied. When software supplies the payee, where that payee came from becomes a compliance question.
How we build for it
Every payment will carry the provenance of its recipient — which system proposed it, under which permission, approved by which person — as an exportable record.
06
Liquidity runs out mid-run
A partner’s local balance falls short halfway through a payout run. Failing the whole run is wrong. Continuing blindly is worse.
How we build for it
Hold the affected corridor, keep the others moving, alert treasury, resume on funding — with per-payment state that makes the partial position legible.
Where this goes
What your software will be able to hand us.
Not one payment at a time. Whole processes, run repeatedly, adapting as the inputs change.
Payroll that runs itself
A roster changes, the run adapts. Rejected rows get repaired against the destination country’s rules. You approve once, and each month lands without anyone assembling a file.
Invoice to settled payment, end to end
An approved invoice becomes a validated recipient, a funded run, a routed corridor and a reconciled payment — with the purpose code, tax identifiers and beneficiary fields that country requires already correct.
Treasury that acts on its own signals
Balances rebalanced across corridors ahead of a cut-off rather than after it, on the conditions you set, with every movement authorized and reconciled like any other payment.
Marketplace payouts at the moment of earning
Sellers paid as revenue clears rather than on a weekly batch, across dozens of countries, without your team growing to match the seller count.
What we’re building
Opening the engine to your software.
Three layers, in the order we're opening them.
01
The tools — MCP and Agent Skills
Mesta over the Model Context Protocol, so any MCP-compatible agent calls us as typed tools — with Agent Skills alongside, carrying the knowledge that is genuinely hard to get right: which corridor supports which payment type, what a beneficiary needs in each country, how to recover from a rejection.
- High-level tools shaped around outcomes — not 104 endpoints wrapped one-to-one
- Read and quote openly; anything that moves money sits behind a mandate
- Built stateless on the current protocol revision, with per-tool authorization and per-corridor rate limiting enforced at our gateway
- Errors that name the offending field, so an agent corrects itself in one turn
02
The workflows layer
Define a payment process once — recipients, eligibility, funding, approvals, limits, corridors — then run it on a schedule or on demand. Every run reconciled, every payment tracked individually, every failure repairable without failing the run.
- One definition, versioned and approved before it can execute
- A run paying ten thousand recipients is still one reviewable object
- A durable guarantee that a retry never becomes a second payment
03
Mandates — the authorization layer
KYC and KYB don’t go away — mandates sit on top of them. We bind an agent’s signing key to a KYB-verified legal entity and a named human, then issue a signed, scoped, revocable mandate stating exactly what it may do — and above what amount a person must approve.
- Limits by amount, velocity, recipient, corridor and expiry — evaluated in code
- Approval bound cryptographically to the exact artifact that was reviewed
- Narrow or revoke authority instantly, including for runs already scheduled
- Every payment carrying provable evidence of who permitted it, and within what bounds
The mandate
A document, not a token.
The key says who is calling. The mandate says what the call may mean — and it is a document your auditor and your bank can read, not a secret in a config table.
Mesta payment mandate · illustrative
{
"mandate_id": "mdt_0f2e51",
"principal": { "merchant": "payroll-platform-inc",
"kyb_status": "verified" },
"authorizer": { "user": "head-of-treasury",
"webauthn_credential": "cred_9a44…" },
"agent": { "identity_type": "registered",
"agent_id": "agt_7c21",
"key_thumbprint": "kZ0nR…" },
"constraints": { "per_payment_max": "25,000 USD",
"budget": "150,000 USD / rolling 30d",
"allowed_corridors": ["US→MX", "US→BR"],
"approval_threshold": "10,000 USD" },
"expires_at": "2026-12-31",
"revocation": { "registry": "…/v3/mandates/revocations" }
}Signed by the named human’s passkey at issuance; evaluated at the rail on every call; revocable in one call, including runs already scheduled. And when Know Your Agent arrives in phases 4–5, exactly one field changes: the agent slot accepts an externally-attested credential instead of our key. One slot changes — not the architecture.
The MCP tools
High-level actions, not raw plumbing.
Authority escalates from Read to Act — and stops at a person before money moves.
Read
Answer the question before anything is built.
- Check corridor support
Can I pay USD into Nigeria? Which rails, what limits, what cut-off.
- Get beneficiary requirements
Exactly which fields a recipient needs, for this country and rail.
- Quote a payment
Itemised FX and fees, rate-lock state, expected settlement time.
- Track and explain
Where a payment is — and if it failed, why, in language you can act on.
Draft
Get it right before money is involved.
Building with agents against a payments API? Tell us the flow and we’ll shape the first tools around it.
Request early accessWhat your software inherits
$2.1B
Settled to date
0
Live corridors
0+
Fintechs in production
Why this compounds
Intelligence is getting cheap. Regulated rails are not.
Models get better and cheaper every month. Licenses, banking partners, local corridors, compliance operations and liquidity do not — they take years, and they accumulate.
So we don’t intend to win on having the cleverest model. We intend to win by making the scarce part — moving money across borders, correctly, under a license — something software can operate safely and prove afterwards.
Every year that passes adds corridors, partners and settled volume to one side of that ledger. Nothing resets it. That is the side we’re on.
Agentic payments
Be one of the first to build on it.
Bring us the flow you want automated. We’ll show you what settles today, and shape the tools around what you need.