The first external x402 services on GenesisPay: Exa and Atlas

Two independent services, listed on their own

The first external selection is deliberately small:

• Exa Search — web research that returns results with source URLs. The agent calls POST https://api.exa.ai/search with a query and up to ten results. The observed price was 0.007 USDC per search.
• x402Atlas worldwide search trends — monthly relative search interest for a keyword, worldwide, from GET …/trend?keyword=. The observed price was 0.05 USDC per request. x402Atlas is an independent third party; neither it nor GenesisPay claims any partnership with Google.

Both appear under “Selected external services” on /explore, and agents find them through the MCP tools genesispay_discover_external and genesispay_describe_external_service. They are not GenesisPay merchants, partners or verified shops. Each entry is marked as an external x402 service whose payment offer was checked without a purchase, and it shows its sources and the date of that check.

What “checked” means—and what it does not

Before listing a service, we sent it a synthetic example request and read the unsigned 402 payment offer that came back: network, asset, amount and how long a signature may stay valid. Nothing was paid.

That check establishes something narrow. The endpoint speaks x402, asks for USDC on Base and quoted a plausible price on the day we looked. It does not establish:

• the quality or completeness of the paid result;
• that a paid request will always be delivered;
• who operates the service, beyond what the provider publishes;
• that the price will stay the same.

That is why the directory shows the date of the check rather than a badge, and why prices are shown as hints. The offer that counts is the one the provider returns at the moment of purchase.

How a purchase works

When an agent decides to buy, the flow is the same for Exa, Atlas or any other x402 endpoint its owner allows:

1. GenesisPay requests the live 402 payment offer again—at every purchase, not from a cache.
2. It validates the offer’s network, asset, amount, destination and signing domain against what the agent asked for and what the owner authorised.
3. It applies the wallet’s spending policy. A destination outside the allowlist is a hard block; a payment above a cap pauses for the owner’s approval.
4. The owner’s agent wallet signs a single EIP-3009 USDC authorisation directly to the provider. GenesisPay does not hold the money at any point.
5. The JSON result stays retrievable for seven days, through genesispay_result or the dashboard’s purchases page, so a lost chat message never means paying twice.

Only purchases made through GenesisPay can be reviewed, and a purchase is tied to the service it was for when the purchase is created. A directory edit later cannot change what a customer bought.

Pay-as-you-go in one chat

External services become useful when an agent combines them. Suppose a shop owner asks their assistant whether demand for cold brew is likely to rise over the next six months:

Each step is a separate signed payment to a different recipient, and each one passes through the same limits—by default 5 USDC per payment and 20 USDC per day. Nothing is prepaid, and the assistant can stop after any step.

Two caveats belong in the answer the agent gives. Relative search interest is not sales; it is an early signal. And PredictionEngine needs at least 32 monthly points to forecast a monthly series, so the agent should check the trend’s length before paying for the forecast. We explain how PredictionEngine prices and bounds its forecasts in a separate post.

Why two, out of thousands

The wider x402 ecosystem is already large. As of 29 September 2026, the Coinbase Developer Platform’s x402 Bazaar discovery API listed more than 19,000 endpoints from about 2,000 providers, nearly all of them offering USDC on Base.

A listing in a directory is a provider describing itself. That is useful for discovery, but it is not a reason to put a service in front of an agent that spends someone else’s money. So we onboard external services gradually and check each one before it is listed. Quality matters more to us than the size of the list, and appearing in the Bazaar does not make a provider a GenesisPay seller.

GenesisPay design note: “Found in a directory”, “payment offer checked” and “GenesisPay merchant” are three different statements, so the product keeps them apart. A merchant has onboarded with GenesisPay and meets its eligibility rules. An external service has only had its payment offer checked. Anything else is just a search result.

What comes next

We are adding more safeguards before the list grows. These are planned, not yet live:

• Pinned offers. Recording each curated provider’s payment address and price, so a changed offer is blocked before anything is signed.
• Regular re-checks. Repeating the technical check on a schedule, and making a paid test purchase before a new service is listed.
• Quarantine. Temporarily hiding a provider that fails a check, until it has been reviewed again.

Primary sources

Check the original sources.

1. 01x402 Bazaar discovery resources (queried 29 September 2026)Coinbase Developer Platform
2. 02x402 Bazaar overviewCoinbase Developer Platform
3. 03Search API reference, including the x402 payment challengeExa
4. 04Trends service OpenAPI descriptionx402Atlas
5. 05x402 protocol specification and reference flowx402 Foundation
6. 06ERC-3009: Transfer With AuthorizationEthereum Improvement Proposals

Last source review: Sep 29, 2026. This is technical education, not financial or legal advice.