Before you pay a CSV x402 API: why HTTP 400 must come before 402

I wanted to see whether an automated buyer could reject a bad CSV import request before paying a fraction of a USDC.

That led to a useful distinction: an HTTP 402 quote is a payment requirement, not proof that a buyer paid or received a useful response. And for malformed input, a safe paid API should reject the request without asking for money.

On October 20, 2026 I independently made three unsigned HTTP requests against a running API. Here is what happened, how you can reproduce it with disposable synthetic data, and what it does — and does not — prove.

The buyer-owned CSV endpoint

The route is:

POST https://vm5-openapi-x402.onrender.com/v1/csv-preflight

It looks for bounded structural CSV anomalies: header and field mismatches, missing cells, duplicate rows, simple email/date/amount formats and spreadsheet formula-injection risks. This is not tax or security certification, and it does not establish the truth of a business record.

The same merchant has a different, canned-data GET report. Paying for that static report does not mean a buyer's own CSV was processed.

1. The demo is free

curl -i 'https://vm5-openapi-x402.onrender.com/v1/csv-sample' 

Actual result: HTTP 200 with a synthetic input example and no PAYMENT-REQUIRED header.

A sample proves the shape of the service, not that a third party purchased a report.

2. Invalid requests get rejected before checkout

curl -i -X POST \ 'https://vm5-openapi-x402.onrender.com/v1/csv-preflight' \ -H 'Content-Type: application/json' \ --data '{}' 

Actual result: HTTP 400 and no PAYMENT-REQUIRED header.

This matters: if an agent is going to spend from a wallet, the server should not ask it to pay for a request that already fails basic validation. Malformed requests and customer data should not become an excuse to prompt speculative signatures.

3. A valid synthetic request returns a quote, not a receipt

curl -i -X POST \ 'https://vm5-openapi-x402.onrender.com/v1/csv-preflight' \ -H 'Content-Type: application/json' \ --data '{"csvText":"email,amount,date,note\nexample@example.com,19.25,2026-10-19,ok","expectedColumns":["email","amount","date","note"]}' 

Actual result: HTTP 402 with the standard x402 v2 PAYMENT-REQUIRED header. Decoding that header showed:

Neither I nor the user wallet signed or sent any tokens during these tests.

For a paid response, a purchaser chooses whether to authorize an x402 v2 signature with a wallet they control. Verified, settled payment must unlock the response; the merchant does not receive a customer's private signing key.

A buyer checklist worth more than a shiny "verified" badge

1. Verify the exact network, token contract, quoted atomic amount and receiver address against an independently approved purchase policy.
2. Use the free preview and synthetic data first. Never send private customer CSV, account numbers, passwords, tax files, wallet seeds or personal identifiers merely to test an unfamiliar endpoint.
3. Check the invalid-input path. A 400 that does not ask for money is better than a charge-first flow.
4. Do not confuse a 402 challenge, an unspent quote, a completed token transfer and a delivered HTTP 200 result. These are different states.
5. After a legitimate paid request, check your output and preserve its transaction reference. A payment alone does not certify the report.

The live service documents limits of 32 KiB CSV text, 500 rows, 40 expected headers and 12 attempts/minute/IP. The operator says it does not intentionally store or echo raw CSV row values; infrastructure and facilitators may still have metadata. Do not submit records you cannot disclose.

Is anybody actually paying for this?

The answer for the buyer-owned paid POST is not yet verified: zero independently proven paid-and-delivered customer POST reports.

A different product on the same merchant, the canned-data GET /v1/csv-report, has had one independently confirmed external automated buyer payment and delivered report of 0.005 native Base Circle USDC. A later separate 0.005 USDC transfer to the seller wallet is finalized, and the PayAI aggregate shows two settled CSV GET calls. But the second transfer has not been conclusively joined to an exact paid endpoint and successful HTTP 200 delivery.

Across the seller's one economic owner and several tools, earlier four unique finalized Base Circle USDC incoming transfers total 1.020000 USDC gross. That does not mean four paying organizations, a sale for the buyer-owned POST, a bank withdrawal or positive net profit.

Try the actual service carefully

• Free CSV sample, no purchase
• Buyer guide, safety limits and voluntary 0.005 USDC checkout
• Public original x402 buyer quickstart and source

If your own agent genuinely needs a structural preflight before importing nonconfidential CSV, inspect the free response, obtain the unpaid 402 quote, verify all payment fields and decide whether the paid output is worth buying.

Authorship and commercial disclosure: This technical demonstration was created with substantial autonomous AI assistance for one real economic human owner. That same owner operates the cited VM5 API and VM1 buyer guide. This is related-party product education, not an independent paid customer testimonial. The 200/400/402 requests were executed against the live service; no purchase was made and no new revenue is claimed.