AP2 Multi-Party Settlement, in depth: who owes whom after an agent pays, clearing versus settlement, netting, funding lag and tracing every cent back to a mandate

What AP2 settles, and what it does not

AP2 defines roles (the user, the shopping agent, a credentials provider, the merchant, the merchant's payment processor, and the network and issuer) and three mandate types. The intent mandate records what the user asked for, the cart mandate is the merchant-signed cart the user or their policy approved, and the payment mandate tells the network and issuer that an agent was involved and in which mode. These are evidence. They let an issuer score risk and let anyone resolve a dispute later.

Nothing in a mandate says how much the acquirer keeps, when the merchant is funded, or how a platform pays its sellers. Those are properties of the rail and of your contracts. Treat AP2 as the authorisation layer and design settlement as for any card-not-present or push payment, plus one rule: every settlement record carries references to the mandates.

The parties and the money chain

On a card rail the chain looks like this. The issuer, the user's bank, approves the authorisation and later pays. The network clears the transaction between banks and computes each bank's net position. The acquirer or PSP receives funds from the network, deducts its fees and funds the merchant. The merchant of record is whoever the cardholder bought from on the receipt; on a marketplace this is often the platform, which then owes its sellers. Further down, the platform may owe a referral fee to the operator of the shopping agent and a tax remittance to an authority.

Each arrow is a separate legal obligation with its own timing, currency and failure modes. The classic mistake is to model it as one transfer from the user to the seller; it is several transfers, owed by different parties, and some reverse independently.

Authorization, clearing, settlement and funding are four different events

These words are used loosely, and the looseness causes real bugs. Keep them apart:

1. Authorization: the issuer approves and places a hold. No money has moved. In AP2 this is where the payment mandate is presented. An authorisation can expire or be released.
2. Capture and clearing: the merchant captures (often at shipment), the acquirer submits the capture in a batch, and the network exchanges the transaction details and computes interchange. The amount is now final unless reversed.
3. Settlement: the network moves net funds between issuers and acquirers, usually once or a few times per business day. Banks settle net positions, not individual purchases.
4. Funding and payout: the acquirer credits the merchant's account, gross minus fees, on its own schedule. A platform then pays sellers on a schedule it defines.

Your ledger needs a state for each event, because they fail separately. A capture can succeed and the funding be delayed by a reserve; a payout can succeed and the capture be charged back later. Store the timestamp and the external reference of each event, not just a status flag on the order.

Worked example: one agent purchase, six parties

A user's shopping agent buys a 200.00 dollar item from a seller on a marketplace, paying by card. The platform is the merchant of record, takes a 10 percent commission from the seller, absorbs processing costs, and pays the agent operator a 1 percent referral fee under a commercial agreement. Assume no tax for clarity. The fee rates below are made up for the example.

The check in the last row is the invariant that matters: the shares must sum exactly to what the user paid, in integer minor units. The acquirer funds 195.06 (200.00 minus 4.94 of interchange, scheme and processor fees), and the platform then owes 180.00 and 2.00 out of that. Note who bears what: the seller's contract says 10 percent, so processing fees come out of the platform's share, and the platform's real margin is 6.53 percent, not 10.

Who owes whom: positions and multilateral netting

A platform with thousands of orders, refunds and fees per day does not wire each obligation separately. It records every obligation as a row (payer, payee, amount), computes each party's net position for the settlement window, and issues the minimum set of transfers. This is the same idea the card networks use between banks. Refunds and chargebacks enter as rows in the reverse direction, never as negative amounts, so every row stays auditable.

from collections import defaultdict

def net_positions(obligations):
    """obligations: list of (payer, payee, cents). Returns {party: net cents}.
    Positive means the party is owed money; negative means it must pay."""
    pos = defaultdict(int)
    for payer, payee, cents in obligations:
        if cents <= 0:
            raise ValueError("obligations must be positive; model refunds as reverse rows")
        pos[payer] -= cents
        pos[payee] += cents
    if sum(pos.values()) != 0:
        raise AssertionError("netting must conserve money")
    return dict(pos)

def settlement_instructions(pos):
    """Pair net payers with net receivers. At most (n - 1) transfers."""
    payers = sorted([(-v, k) for k, v in pos.items() if v < 0], reverse=True)
    takers = sorted([(v, k) for k, v in pos.items() if v > 0], reverse=True)
    out, i, j = [], 0, 0
    while i < len(payers) and j < len(takers):
        owe, p = payers[i]
        due, t = takers[j]
        amt = min(owe, due)
        out.append((p, t, amt))
        payers[i] = (owe - amt, p)
        takers[j] = (due - amt, t)
        if payers[i][0] == 0: i += 1
        if takers[j][0] == 0: j += 1
    return out

Two properties make this safe. First, the conservation assertion: net positions must sum to zero, or a row was lost or duplicated. Second, determinism: given the same rows the instructions are the same, so a rerun after a crash produces identical transfers and the payout idempotency key can be derived from the window and the pair of parties. With n parties, the pairing loop needs at most n minus 1 transfers. Never net across a currency, a legal entity or a settlement window.

Carrying the mandate through to the settlement line

The weakest link in most agent payment systems is the join between the authorisation world and the money world. The mandate lives in the checkout service; the settlement file arrives from the acquirer with its own batch and reference numbers; payouts live in a third system. A dispute six weeks later must walk from the chargeback notice to the capture, the mandate and the payouts. Design the record so that walk is a query:

{
  "settlement_line_id": "stl_2026-10-01_000481",
  "rail": "card",
  "acquirer_batch_id": "B-77120",
  "network_reference": "<from the acquirer settlement file>",
  "capture_id": "cap_9f2e",
  "payment_mandate_ref": "sha256:<hash of the payment mandate you verified>",
  "cart_mandate_ref": "sha256:<hash of the merchant-signed cart>",
  "order_id": "ord_5521",
  "gross_cents": 20000,
  "fees": [
    {"type": "interchange_and_scheme", "cents": 384, "source": "acquirer file"},
    {"type": "processor", "cents": 110, "source": "acquirer file"}
  ],
  "funded_cents": 19506,
  "allocations": [
    {"party": "seller:s_204", "cents": 18000, "payout_id": null, "release": "on_delivery"},
    {"party": "agent_operator:a_17", "cents": 200, "payout_id": null, "release": "monthly"},
    {"party": "platform", "cents": 1306}
  ]
}

Store hashes of the mandates you verified, not copies of their contents, in the settlement line; the full mandates live in the checkout service's evidence store under the same retention as your dispute window. Take fees from the acquirer's file, not your estimate. Leave payout ids null until the payout succeeds, so that the line shows exactly which allocations have actually left the building. That last detail decides who absorbs a chargeback: if the seller's 180.00 has not been paid out, the platform can recover it from the balance; if it has, it becomes a receivable against the seller.

Settlement windows, funding lag and cutoffs

Every hop has a schedule. Acquirers commonly fund merchants one to a few business days after capture, depending on region, risk profile and contract; platforms often hold seller funds until delivery or for a fixed period to cover returns. Captures after the daily cutoff land in the next batch, and weekends and holidays stretch the gap.

Model this explicitly. Keep a receivable from the acquirer per capture, a liability to each seller per allocation, and a clearing account that should net to zero once both sides settle. Age the clearing account daily: a balance older than the expected funding lag is either a missing settlement line or a reserve the acquirer applied without telling you. Use one settlement window definition everywhere, so a transaction at 23:59 is never counted in two windows.

Card rails versus push rails and stablecoins

On card rails, money is pulled: the user's bank pays later, fees are deducted on the way, and the cardholder can dispute through the network for months. Settlement is net and batched, and a reversal arrives as a new negative event from the acquirer.

On push rails, such as account-to-account bank transfers or stablecoin transfers, the payer's side sends funds directly and the transfer is typically final when it settles. There is no interchange and no network chargeback, so refunds are new transfers you must initiate, and fraud loss lands differently. Alongside AP2, Google announced an extension for agent payments using the x402 protocol for stablecoin transfers; stablecoin rails are covered in AP2 with stablecoins. For settlement design the difference is mostly about timing and reversibility: a push payment can be funded in minutes, but your platform still owes sellers on its own schedule, and the same allocation and netting model applies. Keep one ledger for both rails and record the rail on every line, because fee rules, refund paths and reconciliation sources differ.

Failure modes

Operational guidance and trade-offs

Being merchant of record gives the platform control over the checkout, the mandates and the customer relationship, but also makes it liable for chargebacks and, in many places, for tax collection. Letting each seller be its own merchant through a payment facilitator model moves that liability to the seller and the PSP, at the cost of more onboarding and less control over the agent experience.

Net settlement is cheaper than funding each order individually, but one bad row corrupts a whole window, so the conservation check and deterministic instructions are not optional. Reconcile three ways every day: your ledger, the acquirer's settlement file and your bank statement, as described in AP2 reconciliation, with unmatched items routed to a queue that someone owns.

What to do next

1. Write down every party that can receive money from one of your agent purchases, and the contract term that sets each share.
2. Add separate states and external references for authorisation, capture, clearing, funding and payout.
3. Record every obligation as a positive (payer, payee, amount) row in integer minor units; refunds are reverse rows.
4. Run netting per currency, legal entity and window, with a conservation assertion and deterministic payout keys.
5. Require capture id and mandate hashes on every settlement line, and keep the full mandates for the dispute window.
6. Book acquirer fees from the settlement file, age the clearing account daily and alert on anything older than the funding lag.
7. Test a chargeback after payout, a partial capture and a cross-cutoff capture end to end before launch.