I want to sell DApp/MCP services#
This page walks you through the fastest path for an HTTP seller — drop a middleware into your existing HTTP service and start charging per call in a few lines of code, using one-time payments.
Looking for the full picture (one-time, batch, pay-as-you-go)? Jump to Payment Methods.
Choose an integration path#
Pick the path that matches your willingness to modify business code and your deployment preferences — all three paths deliver the same business outcome; they differ only in integration point and refactor cost.
How to choose#
| Path | Business code changes | Deployment | Typical use case |
|---|---|---|---|
| Integrate via Prompt | Generated by AI | Same process as your service | Demos, quick validation |
| Integrate via SDK | A few lines of middleware | Same process as your service | New services, greenfield projects |
| Integrate via Reverse Proxy | None | Separate process (in front of your service) | Existing services hard to modify; consolidating multiple upstreams |
FAQ#
If a buyer doesn't pay, will my service waste resources serving them?
No. The SDK intercepts unpaid requests and returns HTTP 402 directly — they never reach your business logic. Only requests with verified signatures trigger resource delivery.
Do I need to run my own node?
No. The Broker handles all on-chain interactions for you — RPC connections, gas management, transaction submission. All you need is a receiving address.
Why is there no KYC or merchant onboarding?
The x402 protocol doesn't require registration by design — payer identity is established by on-chain signatures (EIP-3009) and cannot be forged. Onchain OS performs transaction-level KYT compliance checks at the Broker layer (see the KYT section in Core Concepts), preserving anonymity while filtering out illicit funds.