Pay Cofounder with MPP

Your agent can buy prepaid company credits with a Machine Payments Protocol (MPP) wallet, then spend the company's balance on Cofounder services such as company research, which returns a saved report with sources.

top-up → wallet pays payment_url → credits land → research start draws on the balance

Buying credits only adds credits. Research is a separate call that needs company access.

Price and Requirements

• A company admin can buy $10 to $5,000 in credits, in whole US cents. A $10 purchase adds $10 to the company's balance. Confirmed funds cover any unpaid company bills first.
• Every credit purchase needs an active $40/month company credit subscription. Each subscription payment also adds $40 in credits. Start it through Stripe Checkout.
• An MPP purchase is a one-time payment. It doesn't start or renew a subscription, or turn on automatic recharges.
• Services draw from the shared company balance. A top-up is not a fixed-price research purchase, and unused credits carry over.

Create a Credit Purchase

Create the purchase from the CLI, MCP, or API. If the response is lost, retry with the same idempotency key and amount. You won't be charged twice.

cofounder company billing top-up 1000 \
  --pay-with mpp \
  --idempotency-key company-research-funding-001

The MCP tool is company_billing_top_up. The API route is POST /cofounder-cli/v1/company/billing/top-ups, with this JSON body:

{
  "amount_cents": 1000,
  "pay_with": "mpp",
  "idempotency_key": "company-research-funding-001"
}

Save the returned transaction id and payment_url. The public payment endpoint is POST https://api.superoptimizers.cofounder.co/billing/mpp/{token}. Always use the complete payment_url Cofounder returns. Don't build the URL yourself. Its token unlocks only that purchase and expires, so keep it private.

Pay Through a Compatible Wallet

1. Send a POST to payment_url without a payment credential. A pending purchase returns HTTP 402 with payment offers in WWW-Authenticate.
2. The wallet reads the challenge, shows the amount and seller, and gets approval for the purchase.
3. Retry the same URL with the wallet's Payment-Authorization header. The Base x402 option uses Payment-Signature instead. Send only one of these headers per request.
4. A confirmed purchase returns HTTP 200, a transaction with state: credited, and a Payment-Receipt header when the payment credential is authenticated. HTTP 202 means payment is still settling. It doesn't prove the credits arrived.

The payment URL needs no Cofounder login or API key. Creating the purchase and spending the credits still need company access. A GET request doesn't start a payment.

Always take amounts, networks, and destinations from the offers returned for your purchase. Supported methods:

Check the Seller

Cofounder's seller is The General Intelligence Company: view the Stripe profile. The production Business Profile ID is profile_61VNemPyLY6duDVnvA6VNemOP2SQNzOcfQgZdsGsqBvc.

For a Stripe payment, check methodDetails.networkId in the challenge before approving it. Sandbox profiles start with profile_test_ and live profiles don't. Sandbox blockchain offers use test networks. Never use live payment credentials or funds to test a sandbox purchase.

Buy One Research Report Directly

You can also buy a single company research job without credits. The payment pays for that job only and never becomes a credit balance.

cofounder research purchases create --domain stripe.com

The MCP tool is research_purchases_create (POST /cofounder-cli/v1/research/purchases). It returns the new job_id, the price in amount_usd ($1.00), and a private payment_url. Nothing is charged or started until the URL is paid, and the offer expires after an hour.

1. POST to payment_url without a credential. HTTP 402 returns a Stripe card or Link challenge for the price. Its description and opaque metadata name the job ID.
2. Retry with the wallet's Payment-Authorization header. The Stripe PaymentIntent gets metadata.research_job_id set to the same job ID, and only then does the research start.
3. The paid request waits up to four minutes and returns HTTP 200 with the job_id, the finished report, its grounding sources, the payment_intent_id, and a Payment-Receipt header. If research is still running it returns 202 with the receipt. Request the same URL again for the report.

If research fails after payment, you get 502 with the receipt and job ID. Contact support with them for a refund to the original payment method.

Example: Buy Credits, Then Research a Company

Once the purchase is confirmed, check the balance:

cofounder company billing get

Then request a report with its own spending limit and idempotency key. These commands do paid work, and the research limit is separate from the credit purchase amount:

cofounder research start \
  --query "Summarize Stripe's products, target customers, and competitors. Cite sources." \
  --title "Stripe company research" \
  --max-cost-usd 5 \
  --idempotency-key stripe-company-research-001
cofounder research jobs get --job-id <job-id>
cofounder research jobs results get --job-id <job-id>

research start returns a job_id. Research takes a while, so check research jobs get until status is completed before treating the report as delivered. The results include the report and its sources. The job's library_files point to the saved outputs, and cost.settled shows the final charge.

See Research for the API routes and other output formats.

Keep Receipts

Keep both the credit transaction ID and the research job ID. They identify different records:

• The credit transaction id identifies the credit purchase. It also appears as metadata.company_transaction_id on the Stripe PaymentIntent.
• The research job_id identifies the service request and its saved results. Research is charged to the company balance separately.

A top-up isn't tied to any one report. The top-up API doesn't take a research job ID, credits can fund many operations, and existing credits can also pay for research. So a top-up receipt alone doesn't prove a particular result was delivered. To prove research delivery, keep the completed job, its settled cost, and the returned report or Library files. To tie one payment to one report, use a direct research purchase instead.

Pending Payments, Failures, and Refunds

Payment went through but the balance didn't change

Find the saved transaction with cofounder company billing transactions list, then retry it with cofounder company billing transactions retry <transaction-id>. Cofounder checks the saved payment before adding the credits. Keep the original purchase. Don't create and pay another top-up to recover. Contact support if it stays pending.

Research failed or was cancelled

For ordinary research jobs, the held credits are released and the job isn't charged. A job still being reconciled or publishing its output isn't finished yet. Check the same job before starting another. Prospect searches in enumerate mode can keep charges for work already done. See Research.

Refunds

Released research credits go back to the company balance. They don't refund the original MPP payment. To request a payment refund, contact Cofounder Support or email support@generalintelligencecompany.com. Include the company ID, credit transaction ID, payment receipt or reference, and the research job ID if relevant. Approved refunds go back through the payment provider and show up in the company's credit ledger.

Inspect a Challenge Without Paying

Given an existing, pending payment_url, this request needs no Cofounder API key and sends no payment credential:

curl --include --request POST "$PAYMENT_URL"

It returns the challenge without charging anything, and it doesn't run research. For a full sandbox test, use a purchase created in the sandbox and a compatible test wallet. Approving in a live wallet can move real money. Redact URL tokens, authorization headers, Shared Payment Tokens, and wallet credentials from any logs or evidence you share.