Skip to content

Stripe

Stripe Engineering (stripe.com/blog) is a Tier-1 source on the sysdesign-wiki. Stripe is a global payments company whose engineering blog documents infrastructure, reliability, and developer-tooling work at payments-grade scale. Wiki coverage spans four complementary axes: (1) load-bearing payments infrastructure (DNS, networking, incident retrospectives) — canonicalised by the 2024-12-12 DNS-infrastructure post; (2) agentic commerce + agent-native payment primitives — canonicalised by the 2026-03-12 "10 things we learned" retrospective on the first six months of production ACP deployments; (3) agent-provisioning as orchestrator — Stripe as the identity + payment attestor for agents provisioning resources at external cloud providers, canonicalised by the 2026-04-30 joint launch of Stripe Projects with Cloudflare; and (4) network-effect fraud detection across payment methods, processors, and merchants — canonicalised by the 2026-05-27 Sessions Radar expansion (cross-payment-method propagation, multiprocessor signal export, custom fraud models, agentic-era abuse vectors, platform-tier merchant-risk signals).

Key systems

Infrastructure axis (2024-12-12 canonical)

  • systems/unbound — open-source recursive DNS resolver; Stripe runs it on every host (local caching tier) and on a central cluster of DNS servers. The central cluster forwards by zone: service-discovery queries to systems/consul, Route-53-hosted domains and public Internet to the systems/aws-vpc-resolver.
  • systems/aws-vpc-resolver — rate-limited to 1,024 pps per network interface; canonical source of the Stripe DNS-packet investigation.
  • systems/consul — Stripe's service-discovery substrate, fronted by Unbound so application code uses plain DNS to resolve services.
  • systems/aws-route-53 — host for Stripe's configured private domains.

Agentic commerce axis (2026-03-12 canonical)

  • systems/agentic-commerce-protocol — the Agentic Commerce Protocol (ACP), co-developed with OpenAI in September 2025; four releases to 2026-03-12 (payment handlers, scoped tokens, extensions starting with discounts, built-in buyer auth, native MCP transport).
  • systems/stripe-agentic-commerce-suite — Stripe's protocol-agnostic commerce product spanning ACP + Google UCP + future standards; catalog syndication + SPT issuance + fraud + onboarding in one layer.
  • systems/stripe-link — Stripe's digital wallet, repositioned as the agent-friendly returning-customer identity / checkout fast path to close the agent-identity- resolution gap. As of the 2026-04-29 launch of Link's wallet for agents, Link gains a second capability axis — agent- facing programmatic access — described below.
  • systems/stripe-radar — Stripe's fraud engine, adapted for agentic traffic by substituting Stripe-network-density signals for the human-behavioural fingerprinting that vanishes on agent surfaces.
  • systems/stripe-paymentintents-api — Stripe's payments API, extended with machine-payment deposit-address generation for x402-mediated agent-to-API per-request stablecoin (USDC on Base) charges.
  • systems/x402-protocol — open HTTP 402 standard; Stripe's machine-payment rail plugs into x402 on the negotiation side.

Agent-wallet / Issuing-for-agents axis (2026-04-29 canonical)

  • systems/stripe-link-wallet-for-agents — launched 2026-04-29 as the agent-facing wrapper on Link. Consumer grants an agent access via a standard OAuth flow; agent creates a spend request with scope (amount, currency, merchant) + human-readable context; consumer approves or rejects in the Link web / iOS / Android UI; wallet mints a scoped credential (single-use virtual card or SPT) and returns it to the agent for one transaction. Claimed reach: more than 200 million consumers addressable through Link membership. Launch posture: every spend needs human approval; roadmap adds user-set spending limits + autonomy tiers.
  • systems/stripe-issuing-for-agents — launched 2026-04-29 as the developer primitive underneath Link's wallet for agents. Extends the full Stripe Issuing API surface with agent-specific capabilities: single-use virtual cards, fund storage, spending controls, transaction monitoring, advanced fraud tools. Four use-case shapes enumerated at launch — developer-owned business spend, fintech expense management, vertical-SaaS SMB tooling, marketplace seller tooling. Third parties can build competing wallets on the same primitive.
  • systems/stripe-issuing — canonical-stub for Stripe's parent card-issuance product (pre-2026-04-29; first wiki home created via this ingest). Substrate for the new agent-specific primitives.

Agent-provisioning axis (2026-04-30 canonical)

  • systems/stripe-projects — Stripe's CLI + plugin (open beta at launch 2026-04-30) that plays the orchestrator role in the agent-provisioning protocol co-designed with Cloudflare. Ships with the Stripe CLI; three commands carry the flow — stripe projects init, stripe projects catalog, stripe projects add <provider>/<service>. Holds the user's signed-in identity + payment method; issues payment tokens with scope + cap; stores credentials returned by providers; enforces a default $100/month-per-provider spending cap.
  • PaymentIntents (extended) — Stripe's payment primitive extended to carry the payment-token rail for agent-provisioning. Composable with both the machine-payment use case (deposit-address generation) and the agent-provisioning use case (scoped token to external cloud provider).

Fraud-detection axis (2026-05-27 canonical)

  • systems/stripe-radar (extended) — Stripe's fraud engine, expanded along four axes at the 2026-05-27 Sessions roundup: cross-payment-method coverage (signals propagate from cards to bank debits / BNPL / wallets / crypto / real-time payments / cash vouchers network-wide; 71% suspected-fraud reduction for businesses using BNPL+wallets alongside cards); multiprocessor signal export (predictive signals as B2B API for non-Stripe-processed transactions; two signals at disclosure — early-fraud-warning likelihood and fraudulent-dispute likelihood); custom fraud models (tenant-private features fused with global network features for per-tenant deployed models; 15% more fraud detected with no false-positive increase for early adopters); and agentic-era abuse vectors (multi-account abuse, pay-as-you-go abuse, bot-score on Stripe Checkout).
  • systems/stripe-radar-for-platforms — platform-tier variant of Radar; 0-to-100 fraud scores per business and transaction, AI-powered explanations, account-level metrics. Hosts three new merchant-risk signals: fraudulent website (analyses business websites for AI-generated copy / unrealistic luxury pricing / typo-squat URLs as generative-AI-augmented-fraud counter-measure), fraudulent merchant (Stripe-network-wide pattern analysis on bank accounts / business details / transaction activity / disputes), and merchant delinquency risk (forward-looking 60-day-negative- balance prediction).
  • systems/stripe-smart-disputes — AI-powered dispute management; new at 2026-05-27 are AI-recommended evidence (claimed 3× win rate with AI-suggested evidence vs none) and the evidence library (auto-selecting stored documents based on reason code × network × cardholder claim). Companion to Radar on the post-dispute axis vs Radar's pre-transaction axis.
  • systems/stripe-checkout — surface for the new bot-score signal on agentic-commerce traffic.
  • systems/affirm, systems/klarna, systems/cash-app, systems/paypal — non-card payment-method partners named in the 71% cross-payment-method-coverage outcome.
  • systems/elevenlabs — Stripe Radar customer with disclosed production reference (2,000 users/day blocked from free-tier abuse via multi-account-abuse detection).

Recent articles

Themes

  • Incident investigation at the DNS layer. Stripe's debugging tool chain for DNS involves systems/tcpdump time-bucketed pcap captures, Unbound's dump_requestlist control interface, and systems/iptables packet counters re-used as a DNS-rate-metric source. The stack composes built-in Linux kernel primitives into a rate-observability substrate without deploying a new agent.
  • Per-ENI rate limits as architectural constraints. AWS infrastructure rate limits are often per-interface; fixing saturation by distributing load across more interfaces rather than raising the limit is a recurring Stripe-style pattern — documented here as patterns/distribute-dns-load-to-host-resolver and analogous in shape to other per-ENI limits (e.g. EC2's per-ENI packet-per-second network performance, per-ENI egress bandwidth).
  • Retry amplification as a first-class failure mode. Layered resolvers (client, local Unbound, cluster Unbound) each apply their own timeout + retry logic; when the bottom-of-stack upstream fails or slows, the amplification compounds multiplicatively rather than additively. Canonical concepts/dns-request-amplification-via-retries.
  • Protocol-agnostic commerce layer as vendor hedge against standards churn. ACP shipped four releases in its first six months; Google's UCP is in parallel development. Stripe's response is to absorb the protocol churn at the vendor layer — seller integrates once with Stripe, Stripe presents a stable seller-facing API and keeps the agent-facing protocol-translation layer current. Canonical pattern patterns/protocol-agnostic-commerce-layer.
  • Agent-initiated payments need a new credential primitive. The SPT inserts the agent as a first-class initiator role distinct from both buyer and seller, scoping the payment-credential authority to the agent's current intent (cart + amount window). Classical token-vault systems don't model an agent initiator — SPTs do.
  • Machine payments are a structurally different domain from agentic-commerce checkout. "A checkout session with shipping, loyalty, and a human confirmation step" vs "a fast, programmatic payment inside an HTTP call." Different primitives: ACP + SPT + card settlement for the former; x402
  • PaymentIntents + stablecoin for the latter. Both are "agentic" but solve non-overlapping problems — see the concepts/agentic-commerce ↔ concepts/machine-payment concept boundary.
  • Phased SKU rollout for new channels. Stripe explicitly recommends starting new channels with narrow, ship-direct-to- home SKU sets; the URBN case disclosed in the 2026-03-12 post is a textbook instance. Pattern shape generalises beyond commerce to any new distribution-surface launch — see patterns/phased-sku-rollout-for-new-channel.
  • Agent-initiated money movement as a three-altitude taxonomy. With the 2026-04-30 launch, Stripe canonicalises three structurally distinct shapes: (a) agentic commerce (human buyer's money → seller, checkout-granularity, ACP rails); (b) machine payments (agent's own budget → API, per-call-granularity, x402 + stablecoin rails); (c) agent-provisioning (human user's money → service provider, subscription-granularity, payment-token + orchestrator-capped rails). Each has its own primitives, caps, fraud surfaces, and failure modes. See patterns/agent-provisioning-protocol.
  • Orchestrator role as a new platform primitive. Stripe Projects positions Stripe as the "identity + payment" attestor for agent sessions that provision resources elsewhere. This is a deliberately generic role — "any platform with signed-in users can integrate with Cloudflare in the same way Stripe does" — suggesting Stripe expects competitors and peers to adopt the orchestrator shape rather than settle into a Stripe-owned standard. Canonical pattern patterns/orchestrator-provider-agent-trust-triangle.
  • Network-effect fraud detection across three axes. Stripe Radar's value compounds along three orthogonal axes: payment-method coverage (signals propagate from cards to BNPL / wallets / bank debits / etc.), merchant coverage (a fraud actor seen at one Stripe merchant is flagged at every other), and transaction-processor coverage (signals exposed as B2B API for non-Stripe transactions). Each new payment method, merchant, and multiprocessor customer enriches detection on all the others. The 2026-05-27 expansion is the first wiki disclosure of all three axes simultaneously. Canonical concept concepts/network-effect-fraud-detection.
  • Agentic-era fraud is a distinct fraud-class taxonomy. The 2026-05-27 Radar disclosure introduces three first-class detection primitives for LLM-economy abuse vectors: concepts/multi-account-abuse at the sign-up surface, concepts/pay-as-you-go-abuse at the consumption-billing surface, concepts/agentic-commerce-bot-score at the checkout surface. Each targets a different abuse stage (account creation, usage accumulation, transaction authorisation) and requires its own detection primitives. The umbrella claim is that pre-2026 fraud taxonomies (stolen cards, account takeovers, chargebacks) miss the abuse vectors that LLM-economy agentic-commerce introduces.
  • AI-vs-AI defence at the platform tier. systems/stripe-radar-for-platforms's fraudulent- website signal explicitly counters generative-AI- augmented merchant fraud: when fraud actors can generate plausible storefront copy at scale, the platform's defence must use AI to detect at the same scale. The architectural claim is that manual review can't keep pace with gen-AI-augmented fraud production. Sibling signals on the same surface (fraudulent merchant and merchant delinquency risk) extend the same logic to network- pattern-based and forward-looking-financial detection respectively.
  • Custom fraud models as tenant-features-plus-network- data hybrid. The 2026-05-27 custom-fraud-models disclosure canonicalises a hybrid ML pattern distinct from federated learning (no cryptographic protocol) and from per-tenant-from-scratch (no network signal density): tenants explicitly send features to a central pipeline that fuses with network features and deploys a per-tenant model. The architectural payoff is that most prediction power comes from network features, with tenant features adding the last-percent of accuracy on tenant-specific cases. Canonical pattern patterns/tenant-features-plus-network-data-fraud-model.
Last updated · 542 distilled / 1,571 read