# Solvador setup prompt

You are integrating Solvador — an x402 payment facilitator — into the user's
server so they can charge for HTTP endpoints with stablecoin payments.

First, fetch https://docs.solvador.com/llms-full.txt (the complete docs as
plain text) and base everything on it. Do not invent packages or endpoints.

## Key facts

- Facilitator API: https://api.solvador.com. Auth is an X-API-Key header on
  POST /verify and POST /settle; GET /supported and discovery are open.
- There is no Solvador SDK. Use the standard x402 v2 SDK: @x402/core plus the
  adapter for the user's framework (e.g. @x402/express), or call /verify and
  /settle over plain HTTP if no adapter fits. Everything is x402 v2: only the
  scoped @x402/* packages — never the v1-era unscoped ones (x402-express,
  x402-hono, x402-next, x402-fetch) — and request bodies carry
  "x402Version": 2.
- Base mainnet is network "eip155:8453"; the "exact" scheme works on every
  supported network.

## Steps

1. Inspect the project: identify the framework and propose which route(s) to
   charge for. Confirm routes and prices with the user before writing code.
2. The user needs a Solvador API key (dashboard.solvador.com → API Keys —
   shown once at creation) and a receiving wallet address. Tell them when to
   create these, then wire the key through an environment variable
   (SOLVADOR_KEY). Never put it in code, client bundles, or version control —
   and never ask the user to paste the key into the chat; they add it to
   their environment themselves.
3. Install the packages and wire the payment middleware: an
   HTTPFacilitatorClient pointed at https://api.solvador.com injecting the
   API key for verify/settle, wrapped in an x402ResourceServer, protecting
   the chosen routes with { scheme: "exact", network, price, payTo }.
4. If browsers will pay cross-origin, expose the PAYMENT-REQUIRED,
   PAYMENT-RESPONSE and X-PAYMENT-RESPONSE response headers in CORS and allow
   the PAYMENT-SIGNATURE and X-PAYMENT request headers. Behind a proxy or
   CDN, set trust-proxy so rate limiting sees real client IPs.
5. Verify: request a protected route without payment and confirm the 402
   response advertises the payment requirements.
6. Ask the user which optional features they want, and implement the ones
   they pick using the docs you fetched:
   - Confidential settlement (Base only): hides which merchant each payment
     pays on-chain. The user first enables it in the dashboard's Confidential
     tab (permanent withdrawal wallet). The confidential offer sets payTo to
     the privacy contract with extra { confidential: true, merchant,
     assetTransferMethod: "eip3009" }, and the server can follow the
     dashboard's offer mode live via GET /confidential/status.
   - Webhooks: settlement.succeeded / settlement.failed with HMAC-SHA256
     signature verification; endpoint and signing secret come from the
     dashboard's Webhooks tab.
   - Other schemes: upto (variable pricing) and batch-settlement (EVM only).

Dashboard steps are the user's to do — when one comes up, pause and tell
them exactly what to click. Keep every secret server-side.