Stripe · Execution · Senior · 60 to 90 minutes
Deprecating a legacy Stripe payments API
Stripe builds payments and financial infrastructure APIs that businesses use to accept payments, manage money, and run online commerce. Answer this product management case and get it graded line by line against a weighted rubric.
- Strategic judgment
- Migration planning
- Risk management
- Stakeholder alignment
- Metric design
The situation
You are a Group PM in Stripe's Payments organization. The Head of Core Payments and the CTO have asked you for a plan to retire a legacy card payments API built around older Charges and token based flows, and move merchants to newer payment flows such as PaymentIntents and PaymentMethods. Assume the following numbers: about 8,000 active businesses still process meaningful volume on the legacy API, they represent 12 percent of card payment volume, 35 percent of payment support tickets, and a disproportionate share of failed SCA, wallet, and multi step authentication use cases. Engineering wants to reduce duplicate infrastructure and unlock faster work on authentication, regional compliance, and new payment method support. Sales and support are worried about churn, broken checkouts, and anger from platforms whose own users still run on old integrations. Finance is concerned about near term payment volume loss. Your job is to propose how Stripe should sequence the deprecation, protect revenue and trust, decide who gets exceptions, and align leadership on when to push hard versus when to slow down.
What to produce
A 1 to 2 page deprecation and migration strategy memo.
Your answer must
- Segment the affected customers, including direct merchants and platforms, by payment volume, integration complexity, and business risk, and state which cohorts should migrate first.
- Recommend a phased deprecation timeline with clear milestones, notice periods, readiness gates, and a policy for time boxed exceptions.
- Describe the migration plan across product and operations, including API or SDK changes, documentation, dashboard messaging, support, and account management.
- Define success metrics and guardrails, including payment volume retention, migration adoption, support burden, payment performance, and criteria to pause or roll back parts of the plan.
- Explain the main risks and second order effects, and how you would align Engineering, Support, Sales, Legal, Finance, and leadership on tradeoffs and decision rights.
Constraints
- Engineering capacity is limited to two payments platform teams and one developer experience team for the next two quarters.
- Stripe cannot introduce merchant facing breaking cutovers during major retail peaks, including Black Friday Cyber Monday and year end.
- The plan must maintain Stripe's existing uptime commitments and comply with card network rules, SCA requirements, and PCI obligations.
- Existing enterprise contracts and pricing terms generally cannot be reopened before renewal.
Format
Use clear sections such as goals, customer segments, phased plan, migration support, metrics, and risks. State assumptions and explicit tradeoffs rather than trying to cover every detail.
Related case studies
- Where should Stripe place its next growth bet?Stripe · Strategy · Mid
- How should Stripe launch its payments API?Stripe · Go-to-market · Senior
- Should Stripe show BNPL at checkout?Stripe · Metrics · Mid
- How should Stripe measure payment method impact?Stripe · Metrics · Senior
- Should Stripe localize subscription prices?Stripe · Metrics · Mid
- How should Stripe support AI pricing models?Stripe · Strategy · Mid