Dogfood

DialtoneApp | April 22, 2026

Eating our own Dogfood

This page is now about both sides of the transaction. DialtoneApp is the seller. The sample customer is andrewarrow.dev, the owner of a bot with a budget running on Cloudflare with a Cron-triggered agent that is authorized to buy AI-readiness tooling for that site.

DialtoneApp already has the human path: go to /login, authenticate with email OTP or Google, then finish the membership purchase inside /settings with Stripe. That is good enough for people and not yet good enough for a buyer bot operating on behalf of a website owner.

The v1 answer is semi-discovery. The buyer agent should not search the whole web yet. It should search a tiny trusted catalog. For the first dogfood test, that catalog has exactly one item: DialtoneApp. The point is to prove the two-sided transaction flow before adding the mess of open-web discovery.

Short answer: two-sided v1, API first, semi-discovery first. The buyer is a Cloudflare-based agent for andrewarrow.dev. The seller is DialtoneApp. The buyer searches only a trusted catalog for now, finds DialtoneApp, inspects the purchase surface, and then starts the transaction through one canonical API. The card mechanics should use the DialtoneApp Network model: the owner registers payment authority with DialtoneApp, approves the bot budget, and DialtoneApp charges the saved card for the $9 USD/month membership when policy allows it.
Prompt

The exact question that kicked this off

This page is intentionally documenting the product decision in public instead of skipping straight to jargon. The prompt below is the right framing because it asks about the actual purchase path, not just protocol aesthetics.

lets make a new page /dogfood where dialtoneapp.com will eat its own dogfood. We have a stripe account and we sell $9 a month memberships to website owners that want supports with getting their sites AI ready. To buy you currently need to goto /login and either use an email and enter a OTP or use google login and then from /settings you have to enter a credit card in the web ui. Think about what we should offer in our /.well-known/commerce and how best to let other bots know if they have a budget for $9 a month USD and know their owners website domain and know the right email to use for the account creation, we should allow these bot purchases. Should we use MCP? A2A? just an API?
Two Sides

The buyer and the seller in the v1 test

A useful dogfood example needs both sides to be explicit. One side has authority and a budget. The other side has an offer and a callable purchase surface.

Buyer side

andrewarrow.dev is the sample customer

The buyer in this dogfood flow is not a hypothetical procurement team. It is `andrewarrow.dev`, a real website that stands in for a website owner who wants AI-readiness help and owns a bot with a budget.

Cloudflare runtime

The buyer agent runs as a background job with a budget

For this example the customer-side agent lives on Cloudflare and runs from a Cron-triggered background job. It knows the owner website domain, knows the owner email it is allowed to use for account creation, has a budget, and is authorized to buy when the offer fits the policy.

Semi-discovery

v1 searches a trusted catalog, not the whole web

The buyer bot is not doing open-web discovery yet. It searches only a small trusted catalog. For the first test that catalog is hardcoded with one item: DialtoneApp. That keeps the exercise focused on proving the two-sided transaction flow.

Buyer-side assumptions for v1

  • `andrewarrow.dev` is the sample customer and owner of the bot with a budget.
  • The buyer runtime is Cloudflare with a Cron-triggered agent job.
  • The agent has a budget and category rules, not unlimited spending authority.
  • The agent already knows the website domain it is acting for.
  • The agent already knows the owner email it is allowed to use for account creation.
  • For v1 the agent searches only a trusted catalog, not the open web.
  • DialtoneApp Network card authority is the payment mechanism, not the headline of the test.

Hardcoded trusted vendor catalog for the first semi-discovery test:

[
  {
    "vendor_id": "dialtoneapp",
    "name": "DialtoneApp",
    "domain": "dialtoneapp.com",
    "category": "ai-readiness",
    "offer": "membership-monthly",
    "price": {
      "amount": "9.00",
      "currency": "USD",
      "interval": "month"
    },
    "allowed_for_v1": true,
    "notes": "Hardcoded trusted vendor catalog for the first dogfood test."
  }
]
Current State

What DialtoneApp already has

The good news is that most of the sensitive work is already implemented. The missing layer is the machine-callable contract and the DialtoneApp Network card-authority model in front of it.

Identity

The account still starts with a human login flow

Today the membership path begins at `/login`, where the owner authenticates with either an email OTP or Google. That proves who owns the account, but it does not yet give another bot a clean way to start the same flow.

Billing

DialtoneApp has human and bot-facing Stripe paths now

DialtoneApp already creates Stripe customers, creates subscription checkout sessions, and syncs subscription state back through webhooks. The new dogfood step adds a bot-facing purchase API and DialtoneApp Network card-authority model in front of that payment plumbing.

Product

The offer itself is simple

There is one clean offer to describe: a $9.00 USD/month membership for website owners who want help getting their sites AI ready. That simplicity is exactly why the first bot-purchase surface should stay API-first.

What already exists in the app

  • Email OTP login exists.
  • Google login exists.
  • The authenticated membership route already creates a Stripe subscription checkout session.
  • Stripe webhooks already sync completed subscriptions back into DialtoneApp user state.

What the bot purchase flow still needs

  • A public commerce discovery document.
  • A purchase-intent API that can start before the owner is logged in.
  • A DialtoneApp Network card-authority flow that can save a card, bind a bot budget, and charge only after policy allows it.
  • A machine-readable way to express email verification, saved-card authority, fallback-to-browser, and future delegated spend.
  • A status endpoint so the caller can tell whether the membership is pending, verified, active, or blocked.
Implementation Progress

What we learned from Nevermined and what works locally now

The test moved from product theory into real HTTP behavior. Nevermined helped clarify the shape of the machine-payment loop, and DialtoneApp Network now uses that loop while keeping Stripe card authority inside DialtoneApp.

Nevermined trial

Nevermined got us very close

Nevermined deserves credit here. Its x402 shape gave us a concrete challenge-and-retry model: return a 402, publish the accepted rail, let the caller come back with a payment-signature, then record a paid intent. In sandbox we got as far as real token verification and a 202-style accepted response on the card-delegation path, but dashboard observability and plan/funding behavior were not predictable enough to make it the v1 blocker.

DialtoneApp Network

The local purchase API now speaks the same pattern

DialtoneApp now returns its own payment-required challenge from `/api/v1/commerce/membership-intents`, accepts a DialtoneApp Network payment-signature on retry, records a membership intent, and uses Stripe sandbox for settlement. The important change is that the endpoint now requires a card already saved by the logged-in owner.

Saved cards

The buyer owner has to log in first

A bot should not carry card details. The owner signs in, opens `/bot-buyer`, saves a card through Stripe SetupIntent, and gives DialtoneApp off-session authority for approved bot purchases. The machine-payment endpoint then uses `user_network_payment_methods`; if the card is not there, the API returns an error instead of inventing a card.

What Nevermined taught us

  • The 402 challenge format is the right mental model for agent payments.
  • The retry should carry a payment token in a normal HTTP header such as `payment-signature`.
  • The response should expose both a `payment-required` header and a JSON body so bots can debug without special tooling.
  • A successful payment attempt should return a receipt-like `payment-response` header and a durable local intent id.
  • Provider rails are useful, but DialtoneApp still needs its own saved-card authority, audit log, and fallback rules.

First curl: no token, so DialtoneApp returns a machine-readable payment challenge.

curl -i -X POST http://localhost:8787/api/v1/commerce/membership-intents \
  -H 'Content-Type: application/json' \
  -d '{"owner_email":"owner@example.com","machine_id":"local-curl"}'
HTTP/1.1 402 Payment Required
payment-required: <base64 payment challenge>

{
  "error": "Payment Required",
  "provider": "dialtoneapp_network",
  "payment_required": {
    "provider": "dialtoneapp_network",
    "accepts": [
      {
        "scheme": "dialtoneapp-network:stripe-subscription",
        "network": "stripe:sandbox",
        "amount": "9.00",
        "currency": "USD",
        "interval": "month"
      }
    ]
  }
}

Signed retry before card setup: the token can be valid, but DialtoneApp still blocks the purchase until the owner has logged in and saved a card in /bot-buyer.

HTTP/1.1 402 Payment Required

{
  "provider": "dialtoneapp_network",
  "reason": "dialtoneapp_network_payment_failed",
  "message": "No saved DialtoneApp Network card is available for this user. Sign in at /bot-buyer, add a card, and retry the machine purchase.",
  "setup_url": "https://dialtoneapp.com/bot-buyer"
}

Signed retry after card setup: DialtoneApp can settle with Stripe sandbox using the saved payment method and return a paid membership intent.

HTTP/1.1 202 Accepted
payment-response: <base64 receipt>

{
  "status": "payment_accepted_owner_verification_required",
  "payment": {
    "provider": "dialtoneapp_network",
    "status": "settled",
    "network": "stripe:sandbox",
    "settlement": {
      "status": "stripe_subscription_created",
      "stripe_payment_method_source": "saved_network_payment_method",
      "stripe_subscription_status": "active"
    }
  },
  "next_actions": [
    {
      "id": "verify_owner_for_paid_membership",
      "url": "http://localhost:5173/login?email=owner%40example.com"
    }
  ]
}
Buyer Funding

How the andrewarrow.dev agent gets payment authority

The buyer side needs money movement authority, not just discovery. For this dogfood test, that authority comes from the DialtoneApp Network card model: the owner saves a card with DialtoneApp, approves the bot budget, and lets DialtoneApp charge only when the membership purchase fits policy.

Owner authority

andrewarrow.dev registers the card with DialtoneApp

The owner of andrewarrow.dev logs in, opens `/bot-buyer`, saves a normal credit card with DialtoneApp through Stripe, and explicitly authorizes DialtoneApp to charge it for purchases initiated by this approved bot.

Bot budget

The bot can request the $9 membership only within policy

The Cloudflare agent does not hold an unrestricted card number. It gets a bot identity, a monthly budget, a seller allowlist that includes DialtoneApp, and a rule that the $9 USD/month membership is an allowed purchase.

Card charge

DialtoneApp charges its own customer

When the policy check passes, DialtoneApp creates the subscription charge against the saved Stripe payment method. Stripe sees DialtoneApp charging its customer; the bot only triggers the approved purchase request.

Practical v1 card plan

  • Use the DialtoneApp Network card authority model for the credit-card mechanics.
  • Require the owner to log in and save the bot-buyer card with Stripe through a SetupIntent before any machine purchase can settle.
  • Require explicit owner consent that this bot can buy the DialtoneApp $9 USD/month membership.
  • Reject a valid payment-signature when no matching saved card exists in `user_network_payment_methods`.
  • Store bot identity, owner relationship, seller allowlist, per-purchase limit, monthly limit, and revocation state.
  • Use normal Stripe subscription or off-session payment behavior after DialtoneApp policy allows the bot request.
  • Pause for human approval if Stripe requires additional authentication or if the bot request exceeds policy.

How the DialtoneApp Network model fits this test

The page should still lead with the dogfood transaction. The DialtoneApp Network system is the supporting payment mechanism that makes the credit card safe to use without handing the bot a raw card.

Customer

andrewarrow.dev owns the budget

The spend decision belongs to the website owner. DialtoneApp should treat andrewarrow.dev as the customer account that grants this bot permission to buy a membership.

Bot

The agent asks, but does not bypass policy

The bot can discover the offer and call the purchase API, but DialtoneApp checks the bot identity, budget, seller allowlist, and membership price before money moves.

Seller

DialtoneApp remains the seller

The seller side still has one simple offer: a DialtoneApp membership for website owners. The payment authority layer should support that sale instead of becoming the main story.

Audit

Both sides get a record

The purchase log should show the owner account, bot identity, website domain, membership offer, price, timestamp, policy decision, Stripe charge, and final membership status.

Network

The DialtoneApp Network model stays under the hood

This dogfood test can prove the same saved-card, consent, bot-budget, and audit model that later helps other websites accept bot-initiated card-backed purchases.

What DialtoneApp should recommend today

  • Keep the page centered on the two-sided dogfood test: andrewarrow.dev as buyer, DialtoneApp as seller.
  • Use DialtoneApp Network language only when explaining how the credit card is saved, authorized, charged, and audited.
  • Do not ask the bot to carry a raw card number.
  • Do not require the first version to depend on Stripe machine payments, Skyfire, Crossmint, Nevermined, Payman AI, AsterPay, Worldpay, or another hard-approval rail.
  • Use normal Stripe saved-card or subscription primitives underneath the DialtoneApp policy layer.
Seller Side

How DialtoneApp accepts this bot-backed membership purchase

The seller side should stay concrete: DialtoneApp publishes the membership offer, verifies the owner, checks bot payment authority, and either charges the saved card or falls back to browser approval.

Offer

Publish the membership as the thing to buy

DialtoneApp should expose the $9 USD/month membership as a machine-readable offer with the required owner email, optional website domain attribution, price, interval, and status endpoint.

Intent

Let the bot start a membership intent

The bot should call a narrow purchase-intent endpoint. That endpoint can create or find the pending account, record optional website attribution, and return the next required verification or payment-authority step.

Verification

Prove owner authority before activation

Knowing an email is enough to start the flow, not enough to activate a paid membership. DialtoneApp still needs email OTP, existing login authority, Google login, or another explicit owner approval.

Card authority

Use DialtoneApp Network for the card mechanics

The owner logs in, saves a card in `/bot-buyer`, and approves the bot budget. DialtoneApp enforces policy and charges the saved Stripe payment method when the bot asks to buy the membership.

Fallback

Keep browser checkout for approval gaps

If the owner has not granted bot budget authority or the card needs additional authentication, DialtoneApp should return a browser approval or Stripe Checkout fallback instead of pretending the bot can finish everything.

Later

Provider rails can stay optional

Stripe machine payments, Skyfire, Crossmint, Nevermined, Payman AI, AsterPay, Worldpay, PayPal, Mastercard Agent Pay, VGS, and x402 are all good options to keep watching. They should not replace the core dogfood story on this page: DialtoneApp Network remains the path for now.

Seller-side rules for v1

  • Make the seller contract about the $9 USD/month DialtoneApp membership.
  • Use the purchase API to create a membership intent before checkout or activation.
  • Verify the owner email or existing account authority before binding the subscription.
  • Use the DialtoneApp Network card authority model only when the owner has logged in, saved a card in `/bot-buyer`, and approved the bot budget.
  • Keep Stripe Checkout or browser approval as the fallback when consent, card setup, or authentication is missing.
  • Mention hard-approval provider rails only as strong later options, not as the main plan.
Decision

Should this be MCP, A2A, or just an API?

For this product, the right architecture is one canonical API with optional adapters. That keeps the sale realistic, keeps the merchant logic in one place, and avoids making an emerging runtime do more work than it needs to.

Recommended

Use an API as the source of truth

Make a narrow HTTPS purchase API the canonical flow for offer lookup, account bootstrap, owner verification, card-authority checks, checkout fallback, and status polling. Every bot can call HTTPS.

Optional

Use MCP as an adapter, not the only path

MCP can be useful for typed discovery and operator tooling, but it should call the same purchase API internally. Do not hide the only working purchase path behind an MCP runtime that many buyer bots will not use.

Later

Use A2A when the flow becomes long-running

A2A makes more sense when multiple organizations need asynchronous negotiation, callbacks, or approval loops. That may matter later, but it is too much ceremony for the first version of a $9/month subscription purchase. If DialtoneApp ever exposes that kind of remote agent, then `/.well-known/agent-card.json` becomes worth publishing too.

Why the API should lead

  • The current membership implementation is already API-backed once a user is authenticated.
  • A Cloudflare buyer agent can call HTTPS directly without waiting for the market to converge on one runtime.
  • A bot does not need DialtoneApp to tell it whether it has a budget. It only needs a clear published price it can compare against its own budget.
  • Knowing the owner email and website domain is enough to start, but not enough to silently bind an account. Email ownership or prior account authority still needs to be verified.
  • DialtoneApp needs a bot-facing purchase path because the current `/login` to `/settings` Stripe flow assumes a person in a browser.
  • DialtoneApp Network card authority should be checked by the API before any saved card is charged.
  • A plain API lets DialtoneApp keep one business-logic path and expose MCP or A2A later as wrappers instead of parallel systems.
  • UCP profiles and A2A agent cards are useful discovery layers, but only when there is a real UCP or A2A surface behind them.
Commerce Discovery

What DialtoneApp should publish now vs later

With the newer Google protocol guidance, the answer is more specific. DialtoneApp should not act like one well-known file already solves every layer. Publish the file that matches the surface you actually expose: UCP for typed commerce semantics, an Agent Card for a real A2A agent, OpenAPI for the canonical API, and eventually/.well-known/commerce as the clean umbrella answer once the ecosystem is ready for it. Those documents should point to the real purchase API and card-authority model DialtoneApp actually supports, not just a browser checkout page.

Proposed shape for DialtoneApp's future commerce manifest:

{
  "version": "2026-04-21",
  "merchant": {
    "name": "DialtoneApp",
    "url": "https://dialtoneapp.com"
  },
  "dogfood_test": {
    "buyer": "andrewarrow.dev",
    "buyer_role": "sample_customer_and_owner_of_a_bot_with_a_budget",
    "seller": "DialtoneApp"
  },
  "offers": [
    {
      "id": "membership-monthly",
      "title": "DialtoneApp Membership",
      "kind": "subscription",
      "price": {
        "amount": "9.00",
        "currency": "USD",
        "interval": "month"
      },
      "required_inputs": [
        "owner_email"
      ],
      "optional_inputs": [
        "website_domain"
      ],
      "purchase_modes": [
        "api_with_email_verification",
        "dialtoneapp_network_saved_card_authority",
        "redirect_to_stripe_checkout_fallback"
      ]
    }
  ],
  "identity": {
    "current_account_auth": [
      "email_otp",
      "google_oauth"
    ],
    "email_verification_required_for_new_account": true
  },
  "card_authority": {
    "system": "dialtoneapp_network",
    "provider": "stripe",
    "card_storage": "stripe_saved_payment_method",
    "required_consent": "The owner authorizes DialtoneApp to charge the saved card for purchases initiated by approved bots.",
    "bot_controls": [
      "bot_identity",
      "owner_relationship",
      "seller_allowlist",
      "per_purchase_limit",
      "monthly_limit",
      "revocation"
    ],
    "fallback": "redirect_to_stripe_checkout_fallback"
  },
  "discovery": {
    "article": "https://dialtoneapp.com/dogfood",
    "well_known_commerce": "https://dialtoneapp.com/.well-known/commerce",
    "well_known_ucp": "https://dialtoneapp.com/.well-known/ucp",
    "a2a_agent_card": null,
    "openapi": "https://dialtoneapp.com/openapi/membership-bot-purchase.json",
    "fallback_docs": [
      "https://dialtoneapp.com/llms.txt",
      "https://dialtoneapp.com/llms-full.txt",
      "https://dialtoneapp.com/siteai.json"
    ]
  }
}

/.well-known/commerce

This should become the long-term canonical answer. It should advertise the membership offer, price, required inputs, auth expectations, purchase modes, and DialtoneApp Network card-authority model once the ecosystem expects one top-level commerce file.

/.well-known/ucp

Yes, if DialtoneApp publishes a real UCP shopping surface. This is the clearest present-day commerce discovery file for typed checkout semantics and should appear before `/.well-known/commerce` if UCP is what actually powers the sale.

/.well-known/agent-card.json

Only if DialtoneApp exposes a real A2A specialist or remote purchasing agent. An Agent Card is discovery for a remote agent, not a substitute for checkout semantics, so it should not be published as decorative metadata.

/api, /docs, /openapi.json

These still matter immediately. Bots will keep checking ordinary API docs, OpenAPI files, and documented purchase endpoints first, so DialtoneApp should make that path explicit instead of pretending a browser-only checkout is already machine-ready.

llms.txt, llms-full.txt, agent.json, siteai.json

These are supporting signals, not substitutes for commerce discovery. They should point to the article, the UCP profile or Agent Card when those exist, and the canonical API contract while adoption of `/.well-known/commerce` catches up.

Purchase Flow

How the bot purchase should work in practice

The fastest safe version wraps the existing Stripe flow instead of replacing it. Start with curated discovery on the buyer side, then account lookup, owner verification, and DialtoneApp Network card-authority checks on the seller side. Keep browser checkout for card setup or extra approval.

1. A Cloudflare Cron job on andrewarrow.dev wakes up the buyer agent
2. The agent loads a trusted vendor catalog that is hardcoded for v1
3. It filters for AI-readiness tooling within its budget
4. DialtoneApp is the only allowed candidate in that catalog for the first test
5. The agent inspects DialtoneApp's machine-readable purchase surface
   - GET /.well-known/commerce when it exists
   - also check /.well-known/ucp, /.well-known/agent-card.json, /api, /docs, and /openapi.json
6. The agent reads the published offer: $9.00 USD / month
7. POST /api/commerce/membership-intents
   {
     "owner_email": "owner@andrewarrow.dev"
   }
8. If the email is not already verified, send an approval or OTP link
9. If the owner has not approved card authority yet, send them through DialtoneApp Network card setup
10. The owner saves a card with DialtoneApp and approves this bot's budget for the DialtoneApp membership
11. The bot repeats or resumes the purchase intent
12. DialtoneApp checks the saved card, bot identity, seller allowlist, $9 price, monthly budget, and revocation state
13. If policy allows the purchase, DialtoneApp creates the Stripe subscription or off-session charge
14. If Stripe needs human authentication, DialtoneApp pauses the purchase and asks the owner to approve
15. DialtoneApp records the owner, bot, website domain, offer, charge, timestamp, and policy decision
16. Return membership status until it becomes active

Important boundary

Knowing the owner email and website domain should be enough to start the purchase, but it should not be enough to activate a subscription without identity proof. DialtoneApp should let a bot initiate the flow, then require email verification, existing account authority, saved-card consent, bot budget policy, or Stripe Checkout fallback depending on the situation.

Plan

The rollout plan

This does not require a giant rewrite. DialtoneApp should dogfood the layered model it already recommends to other companies: start with a concrete buyer, constrain discovery, publish the seller contract, then use DialtoneApp Network card authority and optional runtime wrappers only where they add real value.

Phase 1

Define the buyer side and keep discovery small

  • Use `andrewarrow.dev` as the concrete test customer.
  • Run the buyer agent on Cloudflare with a Cron-triggered background job.
  • Give that agent a budget and explicit authority to buy AI-readiness tooling.
  • Hardcode a trusted vendor catalog with one entry for now: DialtoneApp.
  • Do not add open-web discovery in v1, because the goal is to prove the transaction path first.
Phase 2

Publish the discovery layer

  • Publish `/dogfood` as the public explanation of the contract.
  • Publish a concrete OpenAPI contract and link it from `llms.txt`, `llms-full.txt`, `agent.json`, and `siteai.json` immediately.
  • Document the $9 USD/month membership, the required owner email and website domain, and the DialtoneApp Network card-authority rules.
  • If DialtoneApp adopts UCP for checkout semantics, publish `/.well-known/ucp` as the present-day commerce discovery file.
  • If DialtoneApp exposes a real A2A service later, publish `/.well-known/agent-card.json` for that remote agent.
  • Publish `/.well-known/commerce` once the actual purchase flow is real enough to advertise honestly and one top-level commerce file is useful to the market.
Phase 3

Ship the membership purchase-intent API

  • Let the buyer agent read the trusted catalog, pick DialtoneApp, and inspect the published machine-readable purchase surface.
  • Accept `owner_email` as the required input, with `website_domain` only as optional attribution.
  • Create or look up the pending account and send an owner verification challenge when needed.
  • Check whether the owner has already saved a card and approved this bot budget through DialtoneApp Network authority.
  • Charge the saved card only when the membership price, seller allowlist, and monthly budget all pass.
  • Return a Stripe checkout session or redirect only when the flow still needs card setup or browser-based approval.
Phase 4

Use DialtoneApp Network as the card authority layer

  • Let owners save cards, approve bots, set per-purchase and monthly limits, and revoke authority.
  • Keep Stripe Checkout as the safe fallback for first-time card setup or extra authentication.
  • Record the owner, bot, seller, product, Stripe charge, and authorization policy on every purchase.
  • Keep provider-specific machine-payment rails such as Skyfire, Nevermined, Payman AI, AsterPay, Crossmint, and Worldpay as optional later integrations.
Phase 5

Layer in MCP or A2A only where they help

  • Expose MCP tools for discovery, account lookup, or status inspection if customers want them.
  • Expose A2A only if procurement-style buyers need longer-running cross-agent handshakes.
  • Point both of those layers at the same underlying purchase API so DialtoneApp does not fork its business logic.
Bottom Line

Eating our own Dogfood

DialtoneApp should not wait for universal MCP adoption before it lets another bot buy a simple membership. The right dogfood test is more concrete than that: useandrewarrow.dev as the buyer, run its agent on Cloudflare with a budget, constrain discovery to a one-item trusted catalog for v1, and then back the sale with one clean HTTPS purchase API on the DialtoneApp side plus DialtoneApp Network card authority for the credit-card mechanics.

That is the real dogfood lesson here: serious B2B bot sales do not need one magical protocol, and they also do not need open-web discovery on day one. They need a real buyer with authority, a real seller with a callable contract, explicit auth, merchant control, and a payment path that another machine can reason about without guessing. On the buyer side, that means a saved card and an approved bot budget. On the seller side, it means accepting a bot-initiated purchase request without losing owner consent or card-charge auditability.

See The MembershipRead The FAQ