Turning a Stripe Subscription Into a Bot-Buyable API | DialtoneApp

Claim

This is the whole article in miniature. The same membership endpoint moves through three states as the buyer gets closer to real spending authority.

POST /api/v1/commerce/membership-intents
owner_email=owner@example.com

HTTP 402 Payment Required
payment-required: <base64 challenge>
provider: dialtoneapp_network
accepts:
  scheme: dialtoneapp-network:stripe-subscription
  amount: $9.00
  currency: USD
  interval: month

POST /api/v1/commerce/membership-intents
payment-signature: dtapp_network_v1....

HTTP 402 Payment Required
reason: dialtoneapp_network_payment_failed
message: No saved DialtoneApp Network card is available
setup_url: /bot-buyer

POST /api/v1/commerce/membership-intents
payment-signature: dtapp_network_v1....

HTTP 202 Accepted
status: payment_accepted_owner_verification_required
payment.status: settled
settlement.status: stripe_subscription_created
next_action: verify_owner_for_paid_membership

I started with a boring human checkout

The pre-bot version of DialtoneApp already worked for humans. A website owner could go to /login, use email OTP or Google login, open /settings, and buy the membership through Stripe. That path was fine for a person in a browser and bad for a buyer bot.

human_flow:
  /login
  -> email_otp | google_oauth
  -> /settings
  -> Stripe checkout
  -> active membership

I kept the first bot-buying test narrow on purpose. The buyer was andrewarrow.dev. The agent ran from a Cloudflare Cron job. The catalog had exactly one allowed seller: DialtoneApp itself. I was not trying to solve open-web discovery. I was trying to make one real SaaS purchase honest and inspectable.

• I used one seller and one offer: the DialtoneApp $9.00/month membership.
• The buyer was a concrete site, `andrewarrow.dev`, not a general shopping bot.
• The buyer used a trusted one-item catalog. I intentionally skipped open-web discovery.
• A bot never saw a raw card number. The owner had to save a card in `/bot-buyer` first.
• Owner verification still happens after payment, so this is not “one header and now everything is autonomous.”

I made discovery boring and payment explicit

The first step was not checkout. It was a machine-readable offer. I published the membership in the obvious places a buyer would actually inspect: the commerce manifest, the UCP companion, the public offer endpoint, and the OpenAPI contract.

GET /.well-known/commerce

{
  "offers": [
    {
      "id": "membership-monthly",
      "price": { "amount": "9.00", "currency": "USD", "interval": "month" },
      "required_inputs": ["owner_email"],
      "optional_inputs": ["website_domain"],
      "purchase_modes": [
        "api_offer_lookup",
        "api_purchase_intent_bootstrap",
        "dialtoneapp_network_payment",
        "browser_checkout_fallback"
      ]
    }
  ]
}

The canonical runtime stayed plain HTTPS. That was deliberate. MCP and A2A are useful adapters, but I did not want the first working purchase path to depend on one runtime choice. Every buyer can call HTTPS. The contract lives in the API.

The second step was the 402 loop. Nevermined was useful here because it gave me the right mental model: if the request is payable, return a challenge and let the caller retry with proof. DialtoneApp now does the same thing for its own saved-card path.

curl -i -X POST https://dialtoneapp.com/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>

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

A valid token still is not payment authority

This was the part that made the project click for me. A buyer can hold a valid payment token and still not be allowed to spend. The seller has to know which human account the spend belongs to and whether that account already delegated a usable payment method.

DialtoneApp Network signature claims:
{
  "aud": "/api/v1/commerce/membership-intents",
  "offer_id": "membership-monthly",
  "owner_email": "owner@example.com",
  "website_domain": "andrewarrow.dev",
  "machine_id": "local-curl",
  "max_amount_cents": 900,
  "currency": "USD",
  "exp": "...",
  "jti": "..."
}

The worker verifies those claims and then looks up the real payment authority. That lookup ends in user_network_payment_methods. If the owner has not logged in and saved a card through Stripe SetupIntent in /bot-buyer, the machine purchase still fails.

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"
}

That was the real design goal: the bot never sees a raw card number. The owner signs in, saves a card once, and delegates a bounded right to spend against that card for this offer. The bot only carries a scoped proof that it may ask.

When the saved card exists, the worker either reuses an existing matching Stripe subscription or creates a new one off-session. The response is still honest about what happened next.

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

{
    "status": "payment_accepted_owner_verification_required",
    "payment": {
      "provider": "dialtoneapp_network",
    "status": "settled",
    "settlement": {
      "status": "stripe_subscription_created",
      "stripe_payment_method_source": "saved_network_payment_method"
    }
  },
  "next_actions": [
    {
      "id": "verify_owner_for_paid_membership",
      "url": "https://dialtoneapp.com/login?email=owner%40example.com"
    }
  ]
}

The whole world of bot-to-bot selling, in one stack

This is the compact version I wish I had at the start. People talk past each other in this space because they mix runtime, commerce semantics, payment authority, and fulfillment into one blurry concept called “agentic commerce.”

That is why broad explainer posts often feel vague. A concrete build makes the boundaries visible. In this one project alone, I needed ordinary HTTPS, a machine-readable offer, a challenge-and-retry payment loop, scoped spend, saved-card authority, Stripe settlement, owner verification, receipts, and browser fallback.

runtime        != commerce semantics
commerce      != payment authority
payment       != fulfillment
browser fallback is still part of the system

Appendix: raw traces and limits

These traces came from the same implementation window on April 22, 2026. They are the smallest pieces of evidence I would want to inspect if someone else claimed this system worked.

verify payment-signature:
  aud must equal /api/v1/commerce/membership-intents
  offer_id must equal membership-monthly
  exp must be in the future
  owner_email must match
  website_domain must match when supplied
  machine_id must match when supplied
  max_amount_cents must authorize 900

resolve payment authority:
  find user by owner_email
  find payment method in user_network_payment_methods
  if no payment method:
    return 402 with setup_url /bot-buyer

if reusable subscription exists:
  status = existing_subscription_reused
else:
  create Stripe subscription off-session
  status = stripe_subscription_created

not solved here:
  open-web seller discovery
  generalized merchant network acceptance
  delegated refunds and disputes
  cross-merchant standard payment authority
  zero-human post-payment onboarding