Stripe Revenue And Future Spend
How Stripe powers Revenue Mode today and guarded spend/provisioning paths later.
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
Official references
| System | Use in Trinity | Official docs |
|---|---|---|
| Stripe Checkout | Snapshot payment session | Checkout Sessions API |
| Stripe webhooks | Signed idempotent revenue events | Stripe webhooks |
| Stripe API | Event and object reference | Stripe API reference |
Source paths
lib/autonomous_agency/revenue.exlib/autonomous_agency/revenue/stripe_webhook_event.exlib/autonomous_agency/tools/stripe.exlib/autonomous_agency_web/controllers/stripe_webhook_controller.extest/autonomous_agency_web/live/revenue_sprint_live_test.exs