Skip to main content
You’re already on Stripe. You use some mix of Payments, Connect, Issuing, Terminal, Billing. Sly doesn’t replace Stripe — it sits in front as an agent-layer abstraction and adds protocols Stripe doesn’t cover. The fastest path is additive, not migratory: connect your Stripe account via OAuth, keep the payment flow, add Sly primitives where they give you leverage.

​
What Sly adds on top of Stripe

​
Concept mapping

​
Step-by-step: add Sly to an existing Stripe integration

​
1. Connect your Stripe account

Via the e-commerce onboarding wizard or direct API:
On return, your Sly tenant has a 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 Stripe Customer you want to transact agentically:
Use metadata to preserve the link — both sides now reference each other.

​
3. Register your first agent under a customer account

Now you have an agent — distinct from anything Stripe models — with identity and spending controls.

​
4. Replace manual subscription logic with AP2 mandates

Stripe Subscription + 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:
Sly events cover the Sly-layer primitives (agent actions, mandate executions, protocol flows). Stripe events still cover card-layer primitives (PaymentIntent succeeded, Invoice paid).

​
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)

Most integrations never fully migrate — they compose permanently. That’s the point.

​
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.succeeded at the same moment Sly fires ucp.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