Skip to main content
Register atum-escrow as a payment method on your mppx client, and your agent can pay for any MPP-gated resource that accepts it — no example repo required.

What’s happening

  1. registerClient builds an atum-escrow client method for mppx — the same Method.toClient() idiom every MPP payment method (Stripe, Tempo) implements. The source account is derived from your key.
  2. When the resource server returns a 402 with a challenge naming atum-escrow, mppx hands it to this method’s createCredential.
  3. createCredential reads the challenge’s corridor terms (destination, deadlines, settlement vault/proxy/role addresses), checks them (see below), builds the Atum PaymentRequest, and signs the source-side Permit2 authorization with your key.
  4. mppx attaches the resulting credential to the retried request as Authorization: Payment, and returns the 200 with a Payment-Receipt header.
The wallet signs a Permit2 authorization — it does not broadcast a transaction. The deposit only executes on-chain once the merchant’s server settles through the Payment Gateway. Before it signs, createCredential checks the merchant’s terms and refuses the challenge with an AtumEscrowTrustError if they fail. See What payers check before signing. Paying through a deployment other than Atum’s production gateways? Pass your own trust to registerClient, or every payment is refused.
The source token must have an approve(Permit2) allowance covering the spend, or the deposit reverts at settlement. The ensureSourceApproval helper in @atumlabs/mppx-atum-escrow/client can arrange it for you before paying.
Expect pending, not a hung request. The acceptance side submits and returns; when settlement is still in flight it answers pending and your client re-attempts the same purchase. Size the client’s HTTP read timeout for the gateway’s wait plus a small buffer, not for the full delivery deadline.

Next steps