Skip to main content
Your merchant server needs to implement ACP’s commerce endpoints (discovery, checkout sessions, orders) and integrate Prism for the payment handler. Prism handles token math, chain selection, and x402 formatting.

Prerequisites

  • A District Pass account
  • A Prism Project Identify Token from the Prism Console
  • An ACP-compatible commerce server exposing /.well-known/acp.json, /checkout_sessions, /product_feed, and order endpoints

Step 1: Host Discovery

ACP agents discover your store by fetching GET /.well-known/acp.json. This is a static file declaring your capabilities:
No payment handler information is included at discovery time. Handlers are returned in the checkout session response.

Step 2: Build the Handler for Checkout Sessions

When an agent creates a checkout session (POST /checkout_sessions), you build the Prism handler from two Prism calls: the handler declaration and the payment requirements.

Fetch the Handler Declaration

Unlike the UCP handlers route, this one needs the API key. Cache the declaration; it rarely changes. It is the handler with an empty config:

Get Payment Requirements

Prism returns the raw x402 PaymentRequired object, with no wrapper. The call is the same for UCP and ACP:

Include in Session Response

Build the handler yourself: copy the cached declaration and set config to the x402 object above ({ ...declaration, config }). Do not change any other field. Add the result to capabilities.payment.handlers[] in your checkout session response:
Request and response amounts use different units. You send amount as a fiat major-unit decimal string ("19.99" — max decimals must match the currency’s exponent). Prism returns the accepts[].amount values in token base units. The tokens that appear in accepts depend on what you have enabled in your Prism Console:
The config must be refreshed on every session update that changes the total (e.g., after adding a shipping address or applying a discount). Re-call Prism’s payment-requirements endpoint with the updated amount, set the new object as config on the cached declaration, and return the handler in your response.

Step 3: Handle Session Updates

Sessions change as the agent provides information. When the agent updates the session (PUT /checkout_sessions/{id}) with buyer info or a shipping address, recalculate your totals and call Prism payment requirements again with the updated amount. Return the updated session with:
  • New totals (including tax, shipping)
  • Updated config in the payment handler (with amounts reflecting the new total)
  • status: "ready_for_payment" when all required fields are present

Step 4: Settle via Prism

When the agent completes checkout (POST /checkout_sessions/{id}/complete), extract paymentPayload and paymentRequirements from payment_data.instrument.credential (ignore the type fields) and forward them to Prism:
Prism settles on-chain and returns:
Create the order and return it with status: "completed". Use the transaction hash as payment proof:
Do not call the settle endpoint more than once per checkout session. If a complete request arrives for an already-settled session, return the previous order without re-submitting to Prism.

Why Prism is Simpler

Prism Console

Configure your chains, tokens, and settlement address

End-to-End Flow

See a complete request/response trace for the full purchase cycle
Last modified on July 10, 2026