Skip to main content
Once you’re past the demo, gate your own route, tool, or API directly with the @atumlabs/x402-atum-escrow server package — no example repo required.
Register the scheme onto an x402ResourceServer with your corridor config, then build the route’s accepts[] from the same config so there is a single source of truth for which source chains you offer:
For a production integration, the contract addresses (fulfillmentProxy, reserver, releaser, escrow per source) and the fulfillmentVerifierEndpoint are Atum-network facts — read them from the payment gateway’s /v1/defaults at startup rather than hardcoding them, so your business config (what/where you receive, markup, deadlines, which chains) stays the only thing you own locally.
The Atum-specific pieces above (registerAtumEscrowScheme, AtumEscrowServerConfig) match the @atumlabs/x402-atum-escrow package. x402ResourceServer and HTTPFacilitatorClient come from @x402/core/server. The route-mounting glue (paymentMiddleware from @x402/express) is the x402 Foundation’s own Express integration — see the x402 documentation for its exact API; mount the resource server however your framework prefers.
Chain IDs, tokens, and addresses above are illustrative placeholders. Use Supported networks and Supported assets for the live catalog.
registerAtumEscrowScheme registers under the eip155:* wildcard by default; pass an explicit network list as the third argument to pin it. A malformed config throws at registration (fail-loud at startup).
Declare the payment-identifier extension as required so the payer names each purchase. When settlement is still running, return pending with PAYMENT-RESPONSE set, and key delivery on the receipt’s payment_id. See Idempotency.

Next steps