Pay Cofounder with MPP

Cofounder accepts Machine Payments Protocol (MPP) payments for prepaid company credits. An agent buys credits, then spends the company's balance on Cofounder services. Company research is one example: the agent starts a research job and receives a saved report with sources.

The payment endpoint delivers a credit purchase receipt. Research is a separate, authenticated operation; paying for credits does not start a research job.

Price and requirements

• A company member can buy $10 to $5,000 in credits, in whole US cents. A $10 purchase adds $10 to the company's credit balance before any unpaid company bills are settled.
• Additional credit purchases require an active $40/month company credit subscription. Each subscription payment also adds $40 in credits. Start the subscription through Stripe Checkout.
• An MPP purchase is a one-time payment. It does not activate a subscription, renew one, or enable automatic recharges.
• Service charges 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

Use the CLI, general Cofounder MCP, or authenticated public API to create the purchase. Reuse the same idempotency key and amount if the response is lost.

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

The MCP operation is company_billing_top_up. Its 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 paid endpoint is POST https://api.superoptimizers.cofounder.co/billing/mpp/{token}. Use the complete payment_url returned by Cofounder rather than constructing a URL. The token scopes access to that purchase and expires; 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. Have the wallet read the challenge, show the amount and seller, and obtain approval for the purchase.
3. Retry the same URL with the wallet's Payment-Authorization header. The Base x402 option instead accepts Payment-Signature; 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 settlement is still pending; it is not proof of delivery.

The wallet-facing endpoint does not require a Cofounder login or API key. Creating the purchase and spending its credits still require company access. A GET request does not initiate payment.

The integration supports these payment methods. Use the offers returned for your purchase as the source of payment amounts, networks, and destinations.

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 authorizing it. Sandbox profiles start with profile_test_; live profiles do not. Sandbox blockchain offers use test networks. Never substitute live payment credentials or funds when testing a sandbox purchase.

Example: buy credits, then research a company

After the credit purchase is confirmed, check the available balance:

cofounder company billing get

Then request a report with its own spending limit and idempotency key:

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>

These commands perform paid work. The research limit is separate from the credit purchase amount. research start returns a job_id; wait for that job's status to become completed before treating the report as delivered. The results include the report and source grounding. The job's library_files identify the saved outputs, and its cost.settled reports the final charge. See Research for the API routes and other output formats.

Receipts and service results

Keep the credit transaction ID and research job ID when recording the purchase and its use. They identify different records:

• The credit transaction's id also appears as metadata.company_transaction_id on the Stripe PaymentIntent. It identifies the credit purchase.
• The research job_id identifies the service request and its saved results. The research job has a separate usage charge against the company balance.

The current top-up API does not accept a research job ID or bind the Stripe payment to one report. Credits can fund multiple operations, and existing credits can also fund research. A top-up receipt alone does not prove that a particular service result was delivered. To verify research delivery, retain the completed job, its settled cost, and the returned report or Library files.

Pending payments, failures, and refunds

If a payment succeeds but the credit balance has not updated, inspect the saved transaction with cofounder company billing transactions list, then retry that transaction with cofounder company billing transactions retry <transaction-id>. Cofounder reconciles the saved provider payment before crediting the purchase. Keep the original purchase identity; do not create and pay another top-up to recover an uncertain payment. Contact support if settlement remains pending.

For ordinary research jobs, failure or cancellation releases the reserved credits without charging for the job. A job awaiting reconciliation or output publication is not yet a completed result; inspect the same job before starting another. Prospect searches in enumerate mode have different rules and can retain charges for work already done, as described in Research.

Releasing a research reservation returns credit to the company balance; it does not 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 research job ID if relevant. Support can use those records to reconcile the payment and delivered work. Approved payment refunds are processed through the payment provider and reflected 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 supplies no payment credential:

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

It returns the challenge without authorizing a charge. This does not run research. For a complete sandbox test, use a purchase created in the sandbox and a compatible test wallet. Live wallet authorization can move real funds. Redact URL tokens, authorization headers, Shared Payment Tokens, and wallet credentials from logs or evidence shared outside the payment flow.