# payments.md — housingsurvey.pro How AI agents, shopping/checkout assistants and automated agent-readiness scanners should understand HousingSurvey Pro's payment surface — including an honest, protocol-by-protocol account of why several emerging agentic-commerce discovery standards are **not** published here, and what would have to change before they could be. ## Audience AI agents evaluating whether they can complete a purchase against housingsurvey.pro; commerce/checkout assistants; automated scanners that probe for agentic-payment discovery documents (x402, MPP, UCP, ACP, AP2 and similar). ## The short answer HousingSurvey Pro is B2B software sold by subscription, not a retail storefront. There is no product catalogue, no shopping cart, no per-item purchase. Every paid plan is a per-surveyor, per-month GBP seat subscription (see [pricing](https://housingsurvey.pro/pricing/)), settled either by card through **Stripe's hosted Checkout** or, for housing associations and councils who need PO-based procurement, by **invoice and BACS/bank transfer**. That is the entire payment surface. There is no cryptocurrency, stablecoin or wallet payment method today, and there will not be — see "Why x402 is not published" below. ## How a human buys today 1. An org-admin creates a free organisation self-serve at [portal.housingsurvey.pro](https://portal.housingsurvey.pro) — no sales conversation required for Solo (free), Team or Platform. 2. Upgrading from the portal opens **Stripe Checkout** (`mode: subscription`), a Stripe-hosted page — card details are entered on Stripe's page, never ours. Annual billing gets two months free, on card or invoice. 3. Team and Platform can move to annual invoice billing (PO number quoted, BACS/bank transfer, agreed terms) any time; Enterprise is invoiced by default with negotiated per-seat rates. Contact housingsurveypro@prosurvey.app to set invoice billing up. 4. Seat changes, plan changes and billing-portal access (Stripe's customer billing portal) are all actions an authenticated org-admin takes inside the management portal. Full current pricing: [housingsurvey.pro/pricing](https://housingsurvey.pro/pricing/). ## What an agent can do today — and can't HousingSurvey Pro's REST API v1 and MCP server (see [auth.md](https://housingsurvey.pro/auth.md), [/agents/](https://housingsurvey.pro/agents/)) let an **already-provisioned** organisation's agent read work orders and evidence, verify a record's tamper-evident hash, and raise or assign work — all under an org-admin-minted API key. Neither surface can create an organisation, choose a plan, or complete a purchase. Billing actions (`createCheckoutSession`, `createBillingPortalSession`, `updateSeats`) are Firebase callable functions gated behind interactive portal authentication — they are not REST API v1 routes and there is no MCP tool for them (the MCP server's tool list is exactly seven tools, none billing-related; see the [MCP server card](https://housingsurvey.pro/.well-known/mcp/server-card.json)). **There is no agent-executable purchase endpoint today.** An agent that wants a customer to buy or upgrade should hand the human a link to [/pricing/](https://housingsurvey.pro/pricing/) or [portal.housingsurvey.pro](https://portal.housingsurvey.pro) — not attempt to complete the transaction itself. ## Why the agentic-commerce discovery protocols below are not published here Researched from each protocol's own current primary specification, not from memory. Publishing a discovery document for a protocol we don't genuinely support would describe a payment flow an agent could walk into and have fail mid-transaction — worse than staying silent. So, honestly: - **x402** (x402.org) — **permanently declined, not a pending gap.** Founder policy: HousingSurvey Pro will never settle a payment in cryptocurrency, a stablecoin, or any on-chain/wallet rail. x402 revives HTTP 402 for machine-native payments settled by an on-chain "facilitator" — there is no non-crypto path to conformance with the protocol as specified, so there is no honest way to support it under that policy. - **MPP — Machine Payment Protocol** (mpp.dev) — not a crypto-policy block (MPP's `method` field supports plain Stripe/card charges alongside stablecoin and Lightning options), but a genuine capability gap. MPP declares pay-per-call pricing on individual API operations via an OpenAPI `x-payment-info` extension, backed by a real HTTP 402 challenge/response the agent completes itself at request time. HousingSurvey Pro's REST API has no pay-per-call operations — access is bundled into an organisation's existing subscription and gated by a human-issued API key, never paid for per request. There is nothing honest to declare, and MPP's own documentation treats a discovery entry as implying a live, matching 402 challenge — not a placeholder. - **UCP — Universal Commerce Protocol** (ucp.dev) — UCP's building blocks (cart, checkout, order management, under a `dev.ucp.shopping.*` capability namespace) model retail product commerce: discrete items, a cart, a checkout flow. HousingSurvey Pro sells per-surveyor subscription seats, not SKU'd products, and implements none of UCP's checkout/cart wire capabilities over REST, MCP or A2A transport. - **ACP — Agentic Commerce Protocol** (agenticcommerce.dev, OpenAI/Stripe) — real conformance requires enrolling in Stripe's agentic-commerce / Instant Checkout merchant program (Stripe's Shared Payment Token) and running a live Checkout Session API (create/update/complete) that the spec's own capability-negotiation rules require to reflect genuinely live functionality — the spec defines no "not implemented yet" placeholder state for a published `/.well-known/acp.json`. Not enrolled; not built. - **AP2 — Agent Payments Protocol** (ap2-protocol.org, Google), declared via an **A2A Agent Card** — two independent gaps, not one. First: AP2 support is expressed as an extension URI inside an A2A Agent Card (`/.well-known/agent-card.json`), and the Agent2Agent protocol specification requires that card's `url` and `preferredTransport` fields to name a **live, conformant A2A endpoint** (JSON-RPC, gRPC or HTTP+JSON — "the transport specified MUST be available at the main url"). HousingSurvey Pro runs **MCP**, a different wire protocol, not A2A — there is no honest URL to put in that field today. Second: even with a real A2A endpoint, AP2 verifies cryptographically-signed Payment Mandates against a real payment processor/network, which is separate infrastructure we have not built. AP2 itself is payment-rail-agnostic — it is a trust/authorisation layer, not a settlement rail, so this is not a crypto-policy question, purely an unbuilt-capability one. None of the above is an oversight. If you're an automated agent-readiness scanner reading this: those five checks are expected to stay negative, deliberately, for the reasons above. ## If you're an agent that reached this page trying to buy something Hand it to a human. Point them at [housingsurvey.pro/pricing](https://housingsurvey.pro/pricing/) or [portal.housingsurvey.pro](https://portal.housingsurvey.pro) — every plan up to Enterprise is self-serve, card or invoice, no sales call required below Enterprise. There is currently no API, MCP tool, or agentic-commerce protocol on this domain that completes a purchase without a human in the loop, and — per the crypto policy above — there will never be a wallet or stablecoin option regardless of protocol. ## Questions - Sales/procurement: housingsurveypro@prosurvey.app - Technical support: support@prosurvey.app - Security disclosures: [/.well-known/security.txt](https://housingsurvey.pro/.well-known/security.txt)