Skip to main content
Register atum-escrow as a payment method on your mppx server to accept it alongside any other MPP methods you support — no example repo required.
registerServer takes a single thing: a submitter — an adapter that hands the signed PaymentRequest to Atum’s Payment Gateway. The corridor (what you receive and the terms you offer payers) is built separately and passed to buildChargeChallenge per charge:

What’s happening

  1. registerServer builds an atum-escrow server method for mppx — the same Method.toServer() idiom every MPP payment method implements. It takes only a submitter; the corridor rides in the HMAC-bound challenge, so one registration serves every corridor you advertise.
  2. buildChargeChallenge turns your corridor and one source option into the atum-escrow challenge, including an intentId for the purchase — built fresh per request from the URL, so two different purchases never share an id; mppx.compose serves that challenge with 402 when the request carries no credential.
  3. When a credential for atum-escrow arrives (Authorization: Payment), mppx calls this method’s verify(): a cheap local check (signature recovery, terms match), then submitter.submit(paymentRequest).
  4. Your submitter forwards the request to the Payment Gateway, the authoritative validator — it re-checks everything and drives settlement (selecting a settler’s price quote, and orchestrating the source-chain deposit and destination-chain fulfillment).
  5. Your submitter returns what the gateway said. Within ~30s you may get a confirmation; past that window you get pending, verify() raises SettlementPendingError, and the payer re-attempts the same purchase. On success, mppx serves your resource with Payment-Receipt attached — key fulfillment on that receipt’s payment_id.
Do not poll inside verify(). A missing confirmation means still settling, not failed. Pass status through so verify() can raise SettlementPendingError (re-attempt) versus SettlementFailedError (new purchase id). Size proxy timeouts for the ~30s synchronous window only — past that, answer pending. Full model: Idempotency.
Chain IDs, tokens, and addresses above are illustrative placeholders. Use Supported networks and Supported assets for the live catalog.

Next steps