# Stripe Revenue And Future Spend

How Stripe powers Revenue Mode today and guarded spend/provisioning paths later.

Status: implemented
Version: latest
Review: source-backed

## Revenue Mode

Stripe is first-class revenue infrastructure, not decorative billing. A public request can become a reviewed lead, a $1 acquisition snapshot offer, a Checkout Session or payment link, a signed webhook event, an Order, a RevenueEvent, a paid/won Deal, an OrderIntake, and a Trinity project run that Hermes can help fulfill under human review.

| Stripe event or action | Trinity record | Why it matters |
| --- | --- | --- |
| Checkout Session created | CheckoutSession metadata and offer refs | Reconciles buyer intent to internal state |
| `checkout.session.completed` | Order, RevenueEvent, paid Deal | Converts payment into production work |
| Webhook replay | StripeWebhookEvent processing state | Idempotency and operator visibility |
| Future agent spend | ApprovalRequest plus ToolCall proof | No autonomous spend without caps and approval |

## Snapshot sale loop

| Stage | Owner/operator action | Trinity/Hermes action | Stripe proof |
| --- | --- | --- | --- |
| Lead review | Owner reviews incoming snapshot request | Trinity records lead in Trinity Growth CRM | No payment yet |
| Sales assignment | Owner assigns promising lead to Trinity | Hermes drafts outreach or next steps through approved skills | Optional checkout/payment link prepared |
| Payment | Buyer pays the $1 snapshot offer | Stripe webhook returns signed completion event | Checkout session and event ID |
| Fulfillment | Owner approves plan/drafts/delivery | Order intake creates run and deliverable work | Order and RevenueEvent |
| Proof | Owner reviews ledger and artifact | Trinity links revenue, CRM, run, tools, and model decisions | Paid deal and audit chain |

## Guardrails

- Webhooks require signature verification outside explicit test bypass.
- Stripe operations use idempotency keys.
- Spend and provisioning actions route through ToolRouter.
- Refunds, disputes, account deletion, legal incidents, and credential changes are not autonomous actions.
- Test-mode and fallback proof are labeled honestly and are not presented as live payment proof.

## Future spend and provisioning

Trinity is designed for agents that can earn and eventually spend, but spending is deliberately stricter than drafting. A Hermes intent to buy software, provision a SaaS tool, reserve a domain, or pay for a service should become a structured purchase request. ToolRouter then enforces account caps, provider readiness, policy, idempotency, and explicit approval before Stripe or another provider performs the side effect.

| Spend control | Purpose |
| --- | --- |
| `LIVE_SPEND` gate | Keeps real purchases disabled unless intentionally enabled |
| Account/run caps | Limits blast radius per owner, project, and run |
| ApprovalRequest | Requires a human to approve exact operation, amount, and provider |
| Idempotency key | Prevents duplicate charges or duplicated provisioning |
| ToolCall and audit records | Makes each external side effect reviewable |

## Primary source links

- [Stripe Checkout Sessions API](https://docs.stripe.com/api/checkout/sessions)
- [Create a Checkout Session](https://docs.stripe.com/api/checkout/sessions/create)
- [Stripe event types](https://docs.stripe.com/api/events/types)
- [Stripe webhooks](https://docs.stripe.com/webhooks)
- [Revenue mode concept](/docs/concepts/revenue-mode)
- [Audit ledger concept](/docs/concepts/audit-ledger)


Source paths:
- `lib/autonomous_agency/revenue.ex`
- `lib/autonomous_agency/revenue/stripe_webhook_event.ex`
- `lib/autonomous_agency/tools/stripe.ex`
- `lib/autonomous_agency_web/controllers/stripe_webhook_controller.ex`
- `test/autonomous_agency_web/live/revenue_sprint_live_test.exs`