Question from an x402 endpoint operator: what spend-governance features do MCP payment users actually ask for?

[ozdreamwalk]

Hi — I run paid x402 endpoints out of Germany (api.ozdreamtools.de) and publish monthly demand measurements: https://www.ozdreamwalk.com/x402-dach-radar-01-2026-07/

MCPay sits at the exact point my current research is about: the proxy between client, wallet and upstream, where 402 negotiation and payment happen — which is also where budgets and approvals would technically live. I'm testing whether a governance layer above the payment primitives is worth building. Six questions; brief answers welcome, and I'm glad to share our aggregate demand data in return:

1. What governs an agent's spending through MCPay today — and what's deliberately not there yet?
2. Which spend-control features do users actually use, and which requested features have you consciously NOT built (too enterprise, too accounting-shaped)?
3. When users ask for approvals, audit exports or accounting integration: what do they cite — internal policy, tax rules, fear of runaway agents? Who inside their org asks?
4. Who owns agent-spending budget and signing authority in the orgs you see?
5. Would your users pay for a governance layer above the proxy (team budgets, approval workflows, audit-ready ledger, accounting export) — and what must it do on day one?
6. Separate question, on the upstream side: when several paid endpoints could serve a request, what decides which one MCPay actually calls — the directory entry, a trust/reliability score, prior experience, price, or nothing in particular? Do you use or pay for endpoint-reputation data, and what does it get wrong?

Thanks — Oliver (OzDreamWalk, Germany)