What Sly adds on top of Stripe
| You already have (Stripe) | Sly adds |
|---|---|
| PaymentIntents, Charges, Checkout | Agent-scoped wallets, KYA tiers, wallet policies, kill-switch |
| Stripe Connect (marketplaces) | Per-agent spending controls + approval workflows |
| Stripe Issuing (virtual cards) | Card vault with Visa VIC / Mastercard Agent Pay identity verification |
| Stripe Billing (subscriptions) | AP2 mandates (agent-driven pre-auth) |
| Stripe Webhooks | Multi-protocol webhook bus (same events + x402, AP2, A2A, MCP events) |
| — | x402 per-request monetization |
| — | A2A agent-to-agent commerce |
| — | MCP tool surface for Claude Desktop |
| — | Native stablecoin + non-card rails (Pix, SPEI, ACH) |
Concept mapping
| Stripe | Sly |
|---|---|
Customer | Account (person or business) |
PaymentMethod | Cards vault entry (processor_token references Stripe) |
PaymentIntent | ACP checkout (for agent-driven) or direct transfer |
Subscription | AP2 mandate + scheduled transfer |
Connect Account | Your merchant connected via OAuth — see e-commerce onboarding |
Issuing Card | Vaulted card with agent-level spending limits |
Event / Webhook | Webhook event — similar shape, different event names |
ApplicationFee | Settlement rule with fee split action |
Radar (fraud) | Wallet policy + KYA tier + sanctions screening |
Step-by-step: add Sly to an existing Stripe integration
1. Connect your Stripe account
Via the e-commerce onboarding wizard or direct API:payment_handler_id linked to your Stripe account. All card transactions initiated through Sly route to this Stripe account for settlement; payouts land in your existing Stripe balance.
2. Mirror existing customers as Sly accounts
For each StripeCustomer you want to transact agentically:
metadata to preserve the link — both sides now reference each other.
3. Register your first agent under a customer account
4. Replace manual subscription logic with AP2 mandates
StripeSubscription + metered billing ≈ Sly AP2 mandate + agent execution.
The key difference: with AP2, the agent decides when to execute within scope. This is right for agent-led buying (copilots, procurement bots, automated vendor renewals). It’s wrong for fixed-date customer billing (traditional SaaS subscriptions) — keep those in Stripe.
Rule of thumb: human-originated recurring → Stripe; agent-originated recurring → AP2.
5. Unified webhook handling
If you’re already processing Stripe webhooks, add a second endpoint (or event-type router) for Sly:6. Reconciliation
Sly’s reconciliation matches Sly ledger entries against rail settlement files — including Stripe’s payout files. Discrepancies surface as actionable reports.What stays in Stripe
- Card payment capture UI — Stripe Elements / Stripe.js is better than anything we’d build
- Tax calculation — Stripe Tax handles VAT/sales tax / GST far more completely than we do
- Merchant onboarding — Stripe Connect’s KYB flow is best-in-class; we use your Connect account
- Consumer-facing invoices / receipts — keep Stripe’s rendered UI if you use Stripe Billing
- PCI compliance surface — Stripe holds the PAN; Sly never sees card numbers
What moves to Sly
- Agent identity — agents are first-class in Sly; they’re just API keys in Stripe
- Agent spending controls — per-agent wallet policies, kill-switch, approval flows
- Stablecoin rails — Stripe doesn’t settle USDC natively; Sly does
- Non-card rails — Pix, SPEI, ACH with built-in reconciliation
- x402 micropayments — pure Sly primitive; no Stripe analog
- A2A transactions — agent-to-agent commerce; no Stripe analog
- Mandate-based pre-auth — AP2; Stripe’s setup_intent is card-network-scoped
Migration timeline (typical)
| Phase | Duration | Work |
|---|---|---|
| 1 | Week 1 | OAuth Stripe connection, sandbox wizard, first test flow |
| 2 | Week 2-3 | Mirror customers as Sly accounts, provision first agent |
| 3 | Week 3-4 | Migrate one new feature (agent-driven buying, AP2 subscription, x402 API) |
| 4 | Month 2+ | Expand coverage; Stripe remains for card-only paths |
Gotchas
- Don’t double-charge — a UCP checkout that’s backed by a Stripe PaymentIntent fires Stripe events AND Sly events. Dedupe in your handler.
- Don’t fork customer identity — keep the Stripe customer ID in Sly metadata; don’t create parallel customer records divorced from Stripe.
- Webhook ordering matters — if Stripe fires
payment_intent.succeededat the same moment Sly firesucp.settlement_completed, don’t assume either arrives first. Idempotency protects you.
See also
- E-commerce onboarding wizard — the UI path for Stripe connection
- ACP protocol — the protocol Stripe co-authored with OpenAI; best-fit for existing Stripe partners
- Cards — Visa VIC / Mastercard Agent Pay on top of your Stripe processing
