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
registerServerbuilds anatum-escrowserver method formppx— the sameMethod.toServer()idiom every MPP payment method implements. It takes only asubmitter; the corridor rides in the HMAC-bound challenge, so one registration serves every corridor you advertise.buildChargeChallengeturns your corridor and one source option into theatum-escrowchallenge, including anintentIdfor the purchase — built fresh per request from the URL, so two different purchases never share an id;mppx.composeserves that challenge with402when the request carries no credential.- When a credential for
atum-escrowarrives (Authorization: Payment),mppxcalls this method’sverify(): a cheap local check (signature recovery, terms match), thensubmitter.submit(paymentRequest). - 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).
- Your submitter returns what the gateway said. Within ~30s you may get a confirmation; past that window you get pending,
verify()raisesSettlementPendingError, and the payer re-attempts the same purchase. On success,mppxserves your resource withPayment-Receiptattached — key fulfillment on that receipt’spayment_id.
Chain IDs, tokens, and addresses above are illustrative placeholders. Use Supported networks and Supported assets for the live catalog.