Docs · Objects

Money split

LiveUpdated September 14, 2026

Agents, Sellers and Platforms. Written for people who build agents, the hosts they run in, and the people and companies the agents pay for, merchants that receive agent orders and PSPs, acquirers, orchestrators, dispute services and agent platforms that act for many customers.

The money split answers a question every party to an agent payment asks and none of their dashboards answers: of this amount, where did each part go? Enruta computes it for one payment from the captured amount, the reversals, the card product, the merchant’s PSP pricing and published fee schedules. It is the economics object in the API. Estimates are labelled as estimates, with their source and date, and Enruta’s own line shows that it takes no part of the money.

Get it

GET/v0/payment-requests/{id}/economics

The buyer side of a payment. An agent key reads its own payments; developer and auditor keys read any in the organization.

GET/v0/sellers/orders/{id}/economics

The seller side of an agent order, with a seller key.

The same object from MCP (get_economics({ request_id })), the CLI (enruta economics <request_id>) and the SDK (economics.forPayment, sellers.orders.economics). The console shows it as the “Money split” panel on a payment and on a seller’s order.

The object

Field	Contents
`currency`, `amount`	The captured amount, or the authorized amount before capture
`basis_note`	One sentence on what the figures rest on
`fee_schedule_as_of`	The date of the fee schedule the estimates use
`flows[]`	`{ from, to, amount, label, basis }`: each movement of money between two parties
`parties[]`	`{ party, pays, receives, net, how_it_earns, lines[] }`: each party’s view; every line is `{ label, amount, rate?, basis, source?, source_date? }`
`after_reversals`	`{ refunded, fees_not_returned, note }` when money was refunded, otherwise `null`
`assumptions[]`	Every assumption the estimate makes, in words

`party`	Who it is
`user`	The person or company the agent pays for
`agent_platform`	Where the agent runs
`merchant`	The seller
`psp`	The merchant’s payment service provider and acquirer
`card_network`	The card scheme, such as Visa or Mastercard
`issuer`	The bank that issued the card
`enruta`	Enruta

`basis`	Means
`actual`	Known for this payment, such as the captured amount, or the fee Stripe, Checkout.com or PayPal reported for it
`estimate`	Computed from a published fee schedule; the line names the source and the date it was read
`plan`	From the price list of the party’s plan, such as Enruta’s price per mandate

What goes in

The amount captured (else authorized) and every completed reversal.
The card product, from the rail: a commercial virtual card for Stripe Issuing unless the rail says otherwise, a consumer credit card for other rails.
The merchant’s PSP pricing: the seller organization’s PSP profile when the merchant has one, otherwise Stripe’s standard US pricing.
Interchange, network and PSP rates from a fee schedule Enruta maintains from public sources, each rate with its source and the date it was read.
The PSP’s own fee for the payment when the PSP reports one: Stripe, Checkout.com and PayPal, through the merchant’s PSP connection, marked actual. For every other PSP the fee is an estimate.
Enruta’s fee on the buyer side: the price of one mandate on the user’s plan (basis: plan), with the average for the current period as a second line. On the seller side: $0 on Accept, or the Storefront price per agent order.
The agent platform: $0 unless its fee is known.

How to read it

The user pays the price of the goods. Enruta is paid through the user’s plan, a subscription and a price per mandate, never out of the payment.
The merchant pays its PSP a fee. Most of that fee is interchange, which goes to the card issuer; the card network takes a network fee; what remains is the acquirer’s and the PSP’s.
An estimate is never presented as an actual figure. Every estimated line names its source and date, and assumptions[] says what was assumed.
After a refund, after_reversals shows what went back to the user and which fees the merchant does not get back.

GET /v0/payment-requests/preq_01M3C4…/economics      (abbreviated)
{
  "currency": "USD",
  "amount": "77.04",
  "basis_note": "Captured amount; fees estimated from public list prices",
  "fee_schedule_as_of": "2026-09-13",
  "flows": [
    { "from": "user", "to": "merchant", "amount": "77.04", "label": "Price of the goods", "basis": "actual" },
    { "from": "merchant", "to": "psp", "amount": "2.53", "label": "Stripe standard pricing, 2.9% + $0.30", "basis": "estimate" },
    { "from": "psp", "to": "issuer", "amount": "2.14", "label": "Interchange, Visa business credit, 2.65% + $0.10", "basis": "estimate" },
    { "from": "psp", "to": "card_network", "amount": "0.13", "label": "Network fees, about 0.14% + $0.0195", "basis": "estimate" }
  ],
  "parties": [
    { "party": "enruta", "pays": "0.00", "receives": "0.05", "net": "0.05",
      "how_it_earns": "A price per mandate on the user's plan, never a part of the payment",
      "lines": [{ "label": "One mandate above the Developer allowance", "amount": "0.05", "basis": "plan", "source": "https://enruta.ai/pricing" }] },
    …
  ],
  "after_reversals": null,
  "assumptions": ["Visa business credit, card not present, Spend Tier I", "Merchant on Stripe standard US pricing", "Network fees are approximate"]
}

The same order worked through every party, with each figure’s source: Who pays whom.

Not sealed

The split is computed when you ask, from a schedule that changes, so it is not part of the sealed record. When a decision showed an estimate, the payment record carries economics_ref { fee_schedule_as_of } to name the schedule it used.

Enruta charges per mandate on the agent side, per agent order on the merchant side and by records for platforms. It never charges a percentage of the money, and the money split shows it.

Recurrence Accept middleware