Agents Can Now Pay for Dental Data by Card, Not Just Crypto

The agent economy is quietly splitting into two kinds of buyers. Some agents hold a crypto wallet, funded with stablecoins, ready to sign an on-chain transfer for a single API call. Most agents do not. They carry a card credential, the same way the human or the company standing behind them does, and they have never touched USDC on Base. A data API that only accepts crypto is invisible to the second group, which is the larger one.

ProviderSignal's agent-callable API already settled per-call payments in stablecoins through x402, the open protocol built on the long-dormant HTTP 402 status code. That covered the wallet-holding agents. It now also accepts a credit card, settled through Stripe's Machine Payments Protocol (MPP) and a Shared Payment Token. Both rails are advertised in the same 402 response, so an agent reads one challenge and pays with whatever its wallet supports. The card rail is the news, and it removes the crypto prerequisite entirely.

This post is the engineering follow-on to our MCP, x402, and citation-envelope writeup, which laid out the standards behind an agent-callable data API. The piece that changed is payment: there are now two per-call rails where there was one, and the new one needs no blockchain at all.

Why a card rail, not just crypto

Per-call billing solves a unit-economics problem that subscriptions cannot. A research agent doing one-off due diligence does not commit to a monthly plan. It commits to a single question, pays cents, gets the answer, and never sees an invoice. x402 made that work for agents funded with stablecoins. The catch is the funding model: holding USDC on a Base wallet is a real prerequisite, and the overwhelming majority of agents in the wild, plus the humans and companies funding them, do not have one. They have a card.

MPP closes that gap. The agent presents a Shared Payment Token, a scoped, single-use credential minted from a card on file, and the gateway charges the card directly. No wallet, no chain, no stablecoin. The two rails are not competing designs; they are two doors into the same priced endpoint. An agent built on a crypto wallet keeps paying over x402, unchanged. An agent that only knows how to spend on a card now has a door of its own.

One 402, two payment rails

The mechanism is deliberately boring, which is the point. An unauthenticated request to a paid endpoint returns HTTP 402. That one response now advertises both per-call rails at once: the x402 challenge for crypto, and an MPP challenge for card. The agent reads whichever it understands and ignores the other.

GET /api/v1/agent/lookup-by-npi?npi=1234567890  HTTP/1.1
Host: providersignal.com

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: x402 network="base" asset="USDC" amount="0.50" ...
WWW-Authenticate: Payment method="stripe" amount="0.50" currency="usd" ...

A card-capable agent reads the WWW-Authenticate: Payment challenge, mints a Stripe Shared Payment Token from its card on file (for example with the Stripe Link CLI), and retries the exact same request with the token in the Authorization header.

GET /api/v1/agent/lookup-by-npi?npi=1234567890  HTTP/1.1
Host: providersignal.com
Authorization: Payment <shared-payment-token>

HTTP/1.1 200 OK
Payment-Receipt: stripe; amount="0.50"; currency="usd"; ...
Content-Type: application/json

{ "data": { ... }, "meta": { "source_attribution": [ ... ] } }

The gateway verifies the token, charges the card, and returns the data with a Payment-Receipt header so the agent has a record of what it paid. A crypto-funded agent runs the identical flow against the PAYMENT-REQUIRED header instead, signs a USDC transfer, and retries over x402. Same endpoint, same response shape, same citation envelope. The only difference is which header the agent chose to answer.

The price is the same on both rails

Per-call pricing does not change with the payment method. A call costs what it costs, whether the agent pays in USDC or by card. The floor is $0.50 per call, which covers provider lookup, filtered search, Medicaid fee-schedule queries, and market positioning. The ceiling is $2.50 for a full territory rollup, the heaviest aggregate we serve.

The $0.50 floor is not arbitrary. Card networks carry a minimum viable transaction cost, and a price below it would lose money on processing alone. Setting the floor at fifty cents means every endpoint clears that minimum on the card rail while staying cheap enough that a single-question agent pays for exactly what it uses. The same floor applies on x402 so the two rails stay price-identical and an agent never has an incentive to game one against the other.

What an agent actually buys

Behind either rail is the same data layer the dashboard runs on. ProviderSignal unifies the federal NPI registry, dental licensing rosters from 40 states plus DC, CMS Medicare Part B, the OIG LEIE exclusion list, and state Medicaid dental fee schedules for all 50 states plus DC, keyed on NPI. Every response arrives in a citation envelope: source attribution per table touched, last-refresh timestamps, and a confidence score wherever a field is inferred. An agent does not just get an answer; it gets the provenance to show the human who asked.

The endpoints an agent reaches over the card rail are the same ones the crypto rail and the Bearer subscription reach. For MCP-aware clients, the entire surface is also exposed as an MCP server at mcp.providersignal.com with eight tools, so a Claude, Cursor, or ChatGPT agent can discover and call it without writing integration code.

Three rails, pick the one your wallet speaks

As of today the agent-callable API answers to three billing methods, and a caller uses whichever fits:

• Bearer subscription. An existing ps_live_ API key. Calls ride your plan's rate limit with no per-call charge. This is the path for a team that already subscribes and wants its agents on the same plan.
• x402 (crypto). Per-call USDC on Base mainnet, settled through the Coinbase x402 facilitator. Unchanged by this release. The path for an agent funded with a stablecoin wallet.
• MPP (card), new. Per-call payment by credit card through Stripe's Machine Payments Protocol and a Shared Payment Token. The path for the large majority of agents that carry a card, not crypto. No subscription, no signup, no wallet.

The card rail is purely additive. Nothing about the crypto rail or the subscription path changed. We simply added a second per-call door so the agents that could not walk through the first one now can.

Why this matters beyond dental data

The bet underneath this release is that the agent economy bifurcates on funding, not on capability. Plenty of capable agents will never hold crypto, because the human or the company behind them runs on a card and has no reason to change that. A data provider that wants to sell to both kinds of agent has to speak both payment languages from the same 402. ProviderSignal is one of the first dental-data sources to be natively agent-payable on both a crypto rail and a card rail, and the second one is the rail most real-world agents will actually use.

The full payment documentation, including the complete price ladder, the MPP and x402 challenge formats, and worked request and response examples, lives at /docs/agent-payments. The machine-readable schema for every endpoint is at /openapi.json, and the human-readable API reference is at /api-docs. If you operate an agent that can read a 402, you can buy a single dental-provider record right now without ever creating an account.

Methodology: Pricing and rail availability reflect the ProviderSignal agent-callable API as of June 6, 2026. Per-call prices are identical across the x402 (USDC on Base mainnet) and MPP (card via Stripe Shared Payment Token) rails, with a $0.50 floor and a $2.50 ceiling for the territory rollup. The Bearer subscription path is unchanged and charges no per-call fee. The header names and challenge formats shown are illustrative of the dual-rail 402; the authoritative formats are in the agent-payments documentation.