How I Designed a $2.4M Revenue Bridge Without Breaking Our Core Payment System
Jetty Credit was essentially a dead product. With a 0.42% take rate, it was generating almost no revenue despite having thousands of qualified prospects flowing through our system monthly. The company had tried email marketing campaigns, manual outreach, and sales initiatives, none of which moved the needle. Meanwhile, Jetty Deposit was successfully processing tens of thousands of transactions and driving 70% of the company's revenue.
Leadership needed Jetty Credit to hit a 5% adoption rate to justify the product's existence. The challenge: How do you cross-sell a failing product without risking the checkout flow that keeps the business alive?
TECHNICAL CHALLENGE
The core problem was architectural incompatibility. Jetty Credit ran on modern Stripe v3 (PaymentMethods), while Jetty Deposit was built on deprecated Stripe v2 (Sources). These systems are fundamentally incompatible—you can't create a unified payment flow between them without significant migration work.
Any integration attempt risked breaking live transactions worth millions. The solution required building a dual-payment architecture that could authorize future billing (SetupIntents) while processing immediate payments (Sources), all while maintaining PCI compliance across separate Stripe accounts.
APPROACH
I led the technical design and architecture for a dual-Stripe integration that would enable cross-selling without requiring a risky system migration. Rather than migrating Jetty Deposit to Stripe v3—a months-long project that could destabilize our revenue stream—I designed a bridge system that could create both payment types from a single user input.
Key strategic decisions:
Minimize risk: Limit changes to checkout and success pages only
Defer complexity: Use SetupIntents for Jetty Credit to avoid immediate charges and refund complications
Enable rollback: Feature-flag the entire integration for safe gradual deployment
Comprehensive monitoring: Build observability before launch to catch edge cases immediately
KEY ACTIONS
Architected a dual-payment system that creates both Stripe Sources (JD) and PaymentMethods (JC) from a single form input
Built a real-time eligibility engine using resident ID and property data to determine cross-sell availability without impacting checkout performance
Implemented deferred billing architecture using SetupIntents to authorize payment methods without immediate charges, avoiding refund complexity
Designed a comprehensive monitoring with Sentry, Datadog, and FullStory integration to track payment flows, API failures, and user interactions
Led a cross-functional team of product, design, and QA to execute a zero-regression launch.
EVIDENCE
Business Impact:
A live painted door test proved a 74% checkout completion rate, validating the cross-sell approach and shattering initial risk assessments.
Revenue modeling based on the successful pilot projected a 12x increase in product adoption (from 0.42% to the 5% target), meeting the primary business goal.
The architecture successfully unlocked $2.4M in potential annual recurring revenue from existing user traffic, a key strategic goal that was met before company-wide changes altered the product's trajectory.
Zero degradation to Jetty Deposit checkout performance during extensive testing
Technical Achievement:
Successfully bridged incompatible payment systems (Stripe v2/v3) without migration
Built PCI-compliant dual-payment flow with comprehensive error handling
Delivered feature-flagged, observable system with zero payment failures in test environments
Created architecture that handled all identified edge cases and rollback scenarios
STAKEHOLDER IMPACT
Leadership: Provided credible growth strategy for struggling product line with clear path to $2.4M ARR potential
Revenue team: Unlocked a new distribution channel requiring zero additional acquisition cost
Engineering: Avoided months-long risky migration while extending system capabilities safely
Customer support: Deferred billing design eliminated potential refund tickets and payment confusion during the move-in process
- Python
- React.JS
- Stripe v2
- AWS
- Stripe v3
- PostgreSQL
- Sentry
- Datadog
- LaunchDarkly
- Segment