Most of the writing about agent payments right now is written by people who haven't shipped them. It compares rapidly evolving protocols in the abstract and stops before the part that actually matters: what does a single API call cost to settle, and which rail is worth using when the call is worth a tenth of a cent?
We sell creator intelligence as an API. A profile lookup costs $0.001. A YouTube search result costs $0.005. An email resolution costs $0.05. When the buyer is an agent inside a campaign workflow, not a developer at a pricing page, the payment has to happen mid-loop or the workflow stalls. So we wired up three ways to pay for the same endpoints, and one of us ended up writing a piece of the x402 protocol's framework support to do it.
This is the practitioner version. What we built, what it costs, and when each rail is the right call.
The three rails, in one paragraph
Influship's endpoints accept payment three ways on the same URL. An API key is the default for production traffic: cheapest per call, tied to an account, integrated with the dashboard. x402 lets a client pay per request in USDC on Base without an account: it hits the endpoint with no key, gets a 402 Payment Required, signs a payment, and retries. MPP (Stripe's Machine Payments Protocol) uses the same per-request pattern through stripe/charge or tempo/charge, reading the supported methods off a WWW-Authenticate: Payment header. A single 402 can advertise both the x402 and the MPP challenge at once, and the client picks whichever its framework already speaks.
That's the whole shape. The rest of this is why, how, and what it costs.
Why an API needs more than an API key now
Every API was built around a human onboarding flow. A developer signs up, adds a card, picks a plan, generates a key, reads the docs, writes the integration. That works, and for steady production traffic it's still the right model.
Agents break the assumption in the middle. An agent inside a campaign-planning workflow doesn't have a card on file with your service. If it hits your endpoint and the only path forward is “pause, prompt a human to register a new vendor, resume,” most agents never get past step one. The agent needs to find the service, read the price, pay, and use the response without breaking the loop.
The shift underneath: once an API is machine-discoverable and machine-payable, you stop distributing it through a sales motion and start distributing it through the software that calls it. That's a different go-to-market, and it only works if paying for one call is as cheap and fast as making the call.
The 402 handshake, with real code
The mechanic is the oldest unused status code on the web. HTTP 402 Payment Required was reserved in the original spec and sat dormant for thirty years. x402 turns it on.
A client hits a paid endpoint with no payment attached:
curl -i https://api.influship.com/v1/profiles/instagram/some_creatorThe server responds 402. The x402 challenge is in the PAYMENT-REQUIRED header, while MPP methods are advertised through WWW-Authenticate. The response body itself is empty JSON:
HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: <base64-encoded-x402-challenge>
WWW-Authenticate: Payment <mpp-challenge>
Content-Type: application/json
{}The client signs a payment, attaches the proof to the retry, and gets the data:
curl https://api.influship.com/v1/profiles/instagram/some_creator \
-H "PAYMENT-SIGNATURE: <signed-x402-payment-payload>"No account, key, or invoice is required. From the API provider's side, the integration adds middleware that reads the request, returns a 402 when payment is missing, verifies the credential through the configured payment service, and allows a valid request through.
The detail people miss: both challenges live on the same 402. We don't run an x402 endpoint and a separate MPP endpoint. One URL advertises both, and the client reads whichever it understands. A stablecoin-native agent pays x402. A team already on Stripe pays MPP. Neither has to wait for the ecosystem to crown a single standard.
The part we had to build ourselves
Influship's external API runs on Fastify. When we went to add x402, the protocol had official middleware for Express and Hono, but not for Fastify. So rather than hack around it, our CTO wrote the Fastify adapter and contributed it upstream to the x402 Foundation repo. It ships the middleware itself, an example server, and test coverage for settlement, response handling, and the edge cases a real Fastify service hits in traffic: malformed paths, settlement byte preservation, resource URL handling.
We wrote it because we needed it, and once it existed there was no reason to keep it private. Agentic payments only become real infrastructure when the frameworks developers already use have working adapters. An ecosystem where the protocol works in a demo but not in your actual web framework stays a demo. (Background on why, in this thread.)
The takeaway for anyone evaluating x402 for their own API: check whether your framework has an adapter before you budget the work. Express and Hono were covered; Fastify wasn't until we did it. Yours might be a weekend or might be already done.
The economics nobody publishes
Here is the part the comparison posts skip. The right rail depends on what a single call is worth, and the failure mode is using a rail whose overhead is bigger than the thing you're selling.
A profile lookup on our API is $0.001 on prepaid credits via an API key. The same lookup over x402 is listed at $0.01, ten times more. That gap reflects Influship's 20% pay-per-request surcharge and whole-cent rounding with a one-cent minimum. That floor dominates sub-cent endpoints. You can see our live per-endpoint x402 pricing on our x402scan listing: profile and creator lookups at $0.01, a one-creator match request at $0.02, and lookalike search from $0.02 for one result up to $1.80 at the 100-result maximum.
Run the rails against a single profile lookup:
| Rail | Price to the buyer | Why | Needs signup? |
|---|---|---|---|
| API key (prepaid credits) | $0.001 | Settled in bulk, so the price can be a fraction of a cent | Yes |
| x402 (USDC on Base) | ~$0.01 | Influship rounds pay-per-request prices to whole cents | No |
| MPP (USDC on Tempo / Stripe SPT) | ~$0.01 | Each request uses an MPP payment credential | No (per-request auth) |
| Raw Stripe card | unsellable | 2.9% + $0.30 fee dwarfs any micro-priced call | Yes |
Three things fall out of that table.
A raw card charge is a non-starter for micro-priced calls. The $0.30 fixed fee alone is 300 times the credit price of a profile lookup. Anyone telling you to “just use Stripe” for a raw card charge on every API call hasn't done this arithmetic. MPP uses protocol-native payment credentials for each request instead of creating a standalone card transaction for every call.
The API key is cheapest, and it's not close. Because you settle credits in bulk, you can price a call below what any per-request on-chain rail can match. This is the concrete reason to keep an API key for production traffic and reach for x402 only where signup is the dealbreaker.
The rails aren't competitors; they're a spectrum by call value and buyer type. API key for known, high-volume production traffic. x402 for the long tail of one-off agent calls where signing up makes no sense. MPP when the buyer is already in the Stripe world or uses USDC on Tempo. A consumer can use more than one rail as its traffic changes.
A worked example: what one agent task actually costs
Concrete numbers make this land. Say an agent is building a creator shortlist for a campaign and runs this sequence against our API. Here's the same task on two different rails.
The calls:
- One semantic search returning 30 ranked creators.
- 30 profile lookups to pull metrics on the results.
- 8 match-scoring calls to vet the strongest candidates against the brief.
- 5 post lookups to verify recent content.
Paying per call with x402 (using our live listed prices): the 30-result semantic search is $1.02, 30 profile lookups are $0.30, 8 one-creator match calls are $0.16, and 5 live Instagram post lookups are $0.10. The API total is $1.58 before any wallet or network costs. The agent can pay mid-loop from its wallet without creating an account.
The same task on an API key (prepaid credits): the search is 85 credits ($0.85), the profile lookups are 3 credits ($0.03), match scoring is 8 credits ($0.08), and the post lookups are 5 credits ($0.05). The total is $1.01. The key remains cheaper because prepaid credits can support sub-cent endpoint prices.
The same task on a raw card: ~44 calls × ($0.30 + 2.9%) is over $13 in fees before accounting for the API value. That is why a raw card charge per call does not work at these prices. x402 and MPP attach protocol-native payment proof to each API request instead.
When to use which: the decision framework
Strip away the protocol politics and the choice is about the buyer and the call.
Use an API key when the caller is your own product, a known customer, or steady production traffic. It's the cheapest per call, gives you account-level rate limits and analytics, and integrates with the dashboard. If a human signs up once and then makes a million calls, a key is correct. Don't make your paying customers do a 402 dance on every request.
Use x402 when the caller is an autonomous agent making a handful of calls, or a developer who wants to try one endpoint without committing to an account. No signup, per-request settlement, and an explicit price for each request. This is the rail for discovery, experimentation, and the long tail: the agent that needs one creator profile mid-workflow and will never call you again.
Use MPP when the buyer wants a per-request payment credential backed by Stripe or USDC on Tempo. Influship currently exposes stripe/charge and tempo/charge; each API request is priced and authorized independently.
You don't have to choose one forever. Because all three hit the same endpoints, a consumer can start on x402 to evaluate, move to an API key once the integration is in production, and never change the URL.
Paying for API calls is not paying creators
One distinction worth stating plainly, because it trips people up. Everything above is about an agent paying your API for data. It is not about paying creators for campaigns.
Creator payments are a different problem: flat-fee contracts, 50% deposits, milestone releases, W-9 and W-8BEN collection, and 1099-NEC reporting where applicable. Those need a payout system with approval, compliance, and dispute controls. They are separate from the per-request API payment described here.
Agentic payments are for machine-to-machine API consumption: small, frequent, programmatic. We walk through where both fit inside a real workflow in the automated influencer pipeline guide. Don't conflate the two; they use different rails for good reasons.
What's still unsolved
Honest about the gaps, because the field is early:
Spending limits agents can't blow past. Per-task budgets that a user grants and an agent physically cannot exceed are still maturing. Influship's current x402 and MPP integrations authorize individual requests, so callers still need their own task-level budget enforcement.
Receipts and refunds that work like humans expect. Failure and refund handling differs by rail and by the point at which a request fails. Document when payment settles and give buyers a clear support path.
Funding. Stablecoin rails require a funded wallet. Stripe-backed MPP does not use the same funding flow, so production integrations need rail-specific setup and monitoring.
Disputes. On-chain payments do not have a card chargeback path; Stripe-backed MPP follows Stripe's controls. Define the support and dispute process for each rail.
None of this makes the direction wrong. Agents are going to keep buying things from software, and the APIs they call need a way to charge them without routing every buyer through a signup form. It does mean you should ship agentic payments alongside your API key, not instead of it.
Where this leaves you
If you run an API and you're wondering whether to add agent payments: do it as an additional rail, not a replacement. Keep the API key for production. Add x402 for the agent long tail. Add MPP if your buyers live on Stripe. Check whether your web framework has an adapter before you scope the work, and if it doesn't, the protocol's repo takes contributions.
For Influship specifically, the paid endpoints in the live manifests accept API keys, x402, or MPP. The x402 protocol itself is governed by the x402 Foundation, and our live server's paid resources and listed prices are publicly indexed on x402scan, the explorer for x402 traffic. An agent can discover those endpoints, pay per call, and never create an account. A production team can generate a key and get cheaper per-call pricing. Same data, same URLs, different doors.
The deeper write-up of our launch is in Influship adds x402 and MPP support. The end-to-end workflow that uses these calls is in the automated influencer pipeline guide. And the rest of the developer guides (MCP server, creator API, Apify actors) live in influencer marketing for AI agents and developers.
Get started: the API docs, or generate a key and make your first call.
