Chegg Commerce: SaaS Vendor Selection (Stripe vs Recurly)

March 1, 2025 · 7 min read · architecturecommerceevaluationpaymentsproductRecurlySaaSStripesubscriptions

Led the evaluation to migrate Chegg’s commerce infrastructure to a SaaS platform, ultimately selecting Recurly for its In-App subscription support and gateway flexibility.

Executive Summary

As a Staff Software Engineer at Chegg, I led the evaluation to migrate our existing commerce infrastructure to a SaaS platform. The organization had already chosen to “buy not build,” so our goal was to identify the most suitable vendor to meet current and future business needs. After a structured assessment—including capability mapping, total cost of ownership (TCO), Proof of Concept (POC) implementation, and risk analysis—Chegg selected Recurly. The deciding factors were Recurly’s native In‑App (iOS and Android) subscription support, strong subscription lifecycle tooling, and gateway flexibility that reduced lock‑in.

Context and Objectives

• Replace/augment in‑house commerce systems with a best‑of‑breed SaaS solution.
• Preserve critical business features (pricing, coupons, subscription lifecycles, dashboards, and analytics).
• Minimize time to market for new packages and promotions.
• Reduce operational burden (scaling, compliance, updates).
• Support In‑App subscriptions with minimal in‑house maintenance.
• Avoid vendor lock‑in where practical (gateway choice, data export).

We began by identifying and eliminating legacy/defunct features to scope the migration effectively. A preliminary cost‑benefit analysis narrowed candidates to Stripe and Recurly.

Evaluation Criteria

The following criteria guided our selection. We applied weights to reflect Chegg’s priorities (e.g., In‑App support and subscription flexibility had higher weight than optional add‑ons).

• Client onboarding time and implementation effort
• Subscription models and pricing flexibility
• In‑App (Apple/Google) subscription support
• Dunning, churn reduction, and lifecycle tooling
• API design, webhooks, SDKs, and documentation quality
• Gateway flexibility vs. vendor lock‑in
• SLA, reliability, rate limits, and scaling posture
• Reporting, dashboards, and observability
• Security, compliance (PCI DSS, SCA/PSD2), and data residency/export
• TCO (platform + transaction fees + add‑ons + internal effort)

Example weighting schema:

Stripe vs Recurly: Capability Overview

Decision Matrix (Illustrative Scoring)

Weights applied to a 1–5 score (5 = best fit). Example results below reflect Chegg’s priorities and POC outcomes.

Result: Recurly scored higher given Chegg’s emphasis on In‑App and subscription lifecycle needs.

Scoring Notes

Key scores explained:

• In-App Support: Stripe scored 2 (requires custom bridging for iOS/Android subscription management); Recurly scored 5 (native in-app out-of-box integration).
• Gateway Flexibility: Stripe scored 3 (locked to Stripe’s own gateway); Recurly scored 5 (supports Braintree, Adyen, Stripe Connect, and regional processors).
• TCO: Recurly scored 3 vs Stripe’s 4 due to higher per-transaction fees at our scale (notable monthly cost difference), offset by significant monthly savings in engineering maintenance.

Scoring scale: 1 = Poor fit, 3 = Adequate, 5 = Excellent fit

Proof of Concept (POC) Approach

POC goals: validate fit for key business flows, identify integration friction, and estimate effort.

1. Dashboard configuration: model products/plans, coupons, taxes, and entitlements.
2. Pricing/packaging: map current and near‑term pricing; document trade‑offs.
3. Webhooks ingestion service: receive events, verify signatures, define idempotency strategy, and map events to domain actions.
4. Minimal web experience: integrate vendor JS library where needed; verify PCI scope and customizability of checkout.
5. In‑App flows: confirm purchase/renewal/cancellation mapping and data reconciliation.
6. Backend impact: evaluate changes to fulfillment, entitlements, invoicing, CRM, and analytics.

POC success criteria:

• End‑to‑end subscription lifecycle works (create, trial, renew, pause/cancel, refund).
• Webhooks processed reliably with idempotency and replay handling.
• Dashboards provide sufficient operator controls and reporting.
• Meets preliminary rate/throughput targets and error budgets.

Risks and Mitigations

Migration Plan (High Level)

1. Discovery and deprecation: catalog features, retire unused paths, finalize accounting rules.
2. POC and decision: execute POC with top flows, gather metrics, finalize weighted scores.
3. Contracting and compliance: SLA, rate limits, data export, DPA, and audit requirements.
4. Build integration: webhook services, pricing/catalog sync, entitlement mapping.
5. Dual‑run and shadow testing: mirror production traffic (where feasible), reconcile events.
6. Controlled rollout: pilot cohorts, monitor KPIs (conversion, churn, auth rates, declines).
7. Full cutover and decommission: switch traffic, stabilize, retire legacy components.

Key KPIs:

• Conversion rate, SCA success, auth/decline rates
• Renewal success, dunning recovery, churn (voluntary/involuntary)
• Refund/chargeback rates and response times
• Time‑to‑launch for new packages/promos

Why Recurly Was Selected

• Native In‑App subscription handling, reducing the need to maintain an internal bridging service.
• Strong subscription lifecycle features (dunning, churn controls, complex pricing).
• Payment gateway flexibility, reducing lock‑in and enabling regional optimization.
• Demonstrated rate‑limit flexibility for peak events without punitive costs.

“In-App subscription support alone accounted for 20% of our decision weight. For companies with mobile-first offerings, underestimate this at your peril.”

“The decision matrix is not just a scoring exercise, it forces alignment on what actually matters to your business.”

“We chose Recurly not because it was ‘better’ than Stripe, but because it was better for us. Context matters more than features.”

Key Takeaway

For Chegg, Recurly’s strengths in subscription flexibility, churn management, and native In-App support outweighed Stripe’s broader ecosystem.

This evaluation highlights the importance of POC-driven vendor selection, balancing cost, feature coverage, and long-term scalability.

Architecture Notes (At a Glance)

• Client → Vendor Checkout → Payment Auth (SCA/3DS as required)
• Vendor Webhooks → Webhook Ingestion Service (verify signatures, idempotency, DLQ)
• In‑App purchase events → Vendor → Webhooks → Entitlement Service
• Data sync/export → Data Warehouse (reporting, forecasting, LTV, churn analysis)

References

Decision-Influencing Resources

• Recurly In-App Purchase Overview - Key resource for evaluating iOS/Android support
• Stripe Billing vs Recurly Comparison - Third-party analysis
• SaaS Metrics That Matter - Framework for KPI selection

Technical Implementation Guides

• Webhooks Best Practices - Idempotency and retry patterns
• PCI DSS Compliance Guide
• Strong Customer Authentication (PSD2)

Vendor Documentation

• Recurly API Documentation
• Recurly Webhooks Reference
• Stripe Documentation
• Stripe vs Recurly Feature Comparison

Business Context

• Subscription Business Model Fundamentals
• India Unified Payment Interface
• Related: Migration story — Chegg’s Recurly Migration: Cohorts, Contracts, and Compensation