How this server is built

x402 on AWS with Terraform

The payment gate is a Terraform module.

Nothing behind these routes knows about payments. The gate is a pair of Lambda@Edge functions on the CloudFront distribution: on origin-request it returns the 402 or verifies the payment and forwards; on origin-response it settles only if the origin answered below 400, so a failed request is never charged. This site deploys it with the same open module anyone can use — ql4b/x402-edge/aws — and attaches its outputs to its own cache behaviors.

main.tf

# Lambda@Edge must live in us-east-1
module "x402" {
  source    = "ql4b/x402-edge/aws"
  version   = "~> 1.3"
  providers = { aws = aws.us_east_1 }

  facilitator_url = "https://facilitator.payai.network"
  network         = "eip155:8453"  # Base mainnet
  pay_to          = "0xYourReceivingWallet"
  public_host     = "api.example.com"

  routes = {
    "/api/premium/*" = { price = "$0.01", mime_type = "application/json" }
  }
}

# then, on your own distribution, one behavior per paid path
ordered_cache_behavior {
  path_pattern             = "/api/premium/*"
  cache_policy_id          = module.x402.cache_policy_id
  origin_request_policy_id = module.x402.origin_request_policy_id
  # + lambda_function_association from module.x402.lambda_function_associations
}

What it does not do: it implements x402 v2 with the EVM exact scheme only; and it does not create or own a distribution — the distribution has to be yours, ideally managed in Terraform. It works with unauthenticated facilitators out of the box, and with the authenticated Coinbase CDP facilitator via a key held in Secrets Manager. The origin can be anything CloudFront fronts: S3, an ALB, a Lambda Function URL.

It retrofits x402 onto existing CloudFront resources — it is not a general payment server. Customizing the flow (idempotency, spend caps, auth-capture) belongs in a stateful runtime, not at the edge.

Registry inputs, outputs, versions ↗ Source handler, tests, examples ↗

Opt-in · signed offers & receipts

The module can sign an x402 offer into every 402 body and a receipt into the PAYMENT-RESPONSE header on a settled 200 — portable, verifiable artifacts a client can check against a public key. It is off by default; a single offer_receipt input turns it on.

It belongs at the edge for the same reason spend caps and auth-capture do not: signing is stateless — a local EIP-712 signature over the payment terms, no state and no extra network call on the hot path. The dedicated signing key (separate from the receiving wallet) lives in Secrets Manager; the module signs but never emits the identity document — the operator hosts a /.well-known/did.json that authorizes the signer.

Running here: the 402 from this site's agent-facing routes carries a signed offer, and each settled payment returns a signed receipt — verifiable against did:web:x402.cloudless.sh.

For the two-persona tour of what this gate protects, see the front page.