← Home

Replacing the engine under a live checkout

Teachable's custom commerce stack had become the top reason its highest-volume sellers were routing sales elsewhere. I led the design of the 12-month migration that moved it to Stripe without interrupting a single live seller.

The Stripe-powered student checkout that shipped with teachable:pay
Role
Product Design Manager
Lead Designer
Timeline
12 months, concept to launch
Team
Myself, 1 Product Designer
2 PMs, 1 Engineering Manager, 8 Engineers
Scale
150K+ creators and businesses selling in 180+ countries
01 · Context and problem
The company

Sellers are the business, and the business was losing them

Teachable is a platform where more than 150,000 creators and companies sell courses, coaching, memberships, and digital downloads. Internally, checkout was named the number one reason our highest-volume sellers had started taking their sales somewhere else.

The problem

A commerce stack that cost a full pod to maintain

Several competitors had moved to Stripe and could ship new payment methods as fast as Stripe released them. We could not, because an entire pod (a PM, an EM, and a team of engineers) was consumed keeping our own stack running, with very little left over for new capability.

What we heard

“The teachable checkout page for my school has become excruciatingly slow. This is really hurting my sales.”

Creator, support

“Probably several hours per week [spent answer emails about failed transactions].”

CREATOR, SUPPORT

“Teachable's current subscription billing capabilities don't meet my needs.”

High-revenue seller, research interview
  • 18%checkout conversion, against competitors running the same Stripe-backed capabilities at the same price.
  • 7payment methods, where adding an eighth was a project rather than a setting.
  • 1 podon maintenance indefinitely, with zero capacity for new commerce features.
02 · Impact
18% → 23%
CHECKOUT CONVERSION (+27%)

Against the exact surface that sellers named as their reason for leaving.

97% → 99.9%
Payment approval rate

Failed transactions were one of two complaints support heard on repeat.

−32%
Payment support tickets

Another main complaint, and one that wasted hours of creator time.

−1.28s
Time to complete checkout

Measured on new sellers, the first cohort migrated.

03 · What shipped
What shipped

teachable:pay, a Stripe commerce stack that reads as Teachable

Sellers connect a payments account, switch on the local payment methods their buyers use, style their own checkout, and reconcile every transaction without leaving the Teachable admin. Buyers get Stripe's checkout, priced and translated for wherever they are. The plumbing is Stripe; the product is ours.

48%

of the schools onboarded to the new stack switched on international selling, a capability the old one could not offer at all.

Shipped now
  • Embedded Stripe checkout
  • 27 payment methods
  • Adaptive pricing across 60+ tax jurisdictions
  • Stripe Billing for student subscriptions
  • In-app dispute and refund handling
  • Abandoned cart email
Deliberately not rebuilt
  • Buyer gifting
  • Checkout page testimonials and custom copy
  • Urgency timers
  • Post-sale one-click upsells
  • Buyer referral links

For what we cut, we scoped a Stripe rebuild of all five with engineering before making a decision on any of them. Usage was the deciding factor: urgency timers ran under 1% adoption, and the other four sat in the same range. We traded five features almost nobody used for a payment stack we could add to every quarter.

“F**k yes. Finally. More order bumps is what I'd like to have most.”

A top-revenue seller, research interview
04 · Key decisions

Keep the money work inside our admin, and redirect only when forced to

The lowest-lift version of this project handed sellers to Stripe's own dashboard for anything financial. I built an exploratory high-fidelity prototype that pulled Stripe's data into our admin instead, and ran concept tests against both.

ChoseOur own front-end components against Stripe's back end, plus Stripe's embedded components where speed mattered more than fit.
RejectedA full redirect to Stripe's hosted dashboard. Testers read it as two products glued together.
CostReal engineering lift, and a permanent seam at identity verification and a handful of payment methods, where the seller still leaves for Stripe.

Stripe over PayPal or a custom solution

Engineering spiked a rewrite of our stack with feature parity to Stripe. It came back measured in years, and it ended with us maintaining the thing we were trying to escape.

ChoseStripe, for an API-first surface we could brand and for the pace at which they ship new payment methods.
RejectedAn in-house rebuild, and PayPal, whose narrower feature set would have forced the redirect experience testers had already turned down.
CostVendor dependency, and less freedom to shape the parts of the experience Stripe owns.

New sellers first, established sellers later

Existing sellers carried the volume, the feature attachment, and the live transactions. Moving them first meant discovering our mistakes on the accounts we could least afford to break.

ChoseA phased rollout: new sellers first, as a joint call with product and engineering.
RejectedA single cutover for everyone.
CostOur highest-value sellers waited longest for the conversion and approval gains.

A hand-managed path for the accounts that carry the revenue

Migrating live transactions for the highest-revenue accounts is a relationship problem before it's a design problem. Customer support owned those relationships and needed to say the same true things on every call.

ChoseA support-led migration, for which I built a pitch deck and feature comparison that ran on those calls.
RejectedThe self-serve path new sellers got. It was never seriously on the table.
CostMy own time, spent on sales collateral instead of design work. It was a small price to pay for a smoother migration path.
05 · The correction

I stopped stress-testing a vendor component too early

Stripe ships an embedded payments table, and I planned the transaction experience around it. It was enough for new sellers, and I relied on perceived flexibility rather than stress testing it further.

ObservedConcept testing with high-revenue sellers during migration prep showed the embedded table did not surface the transaction detail their businesses ran on. These were the accounts we had explicitly sequenced last for this very reason.
IntervenedRather than negotiating the requirement down to what the component could do, we built a custom table on our own front-end components, pulling from both Stripe's back end and our own data.
What changedNo seller lost transaction history in the migration. It cost design and engineering time that wasn't scoped, and as a result pushed the migration rollout start date by a sprint.
06 · Deep dive

Connecting a payments account

This is the first thing a seller does and the one place we accepted a handoff. Identity verification is Stripe's regulated surface, so the honest move was to make the handoff look deliberate rather than pretend it was not happening.

1Entry point in the Sales tab. Payments settings sit with transactions, payouts, and coupons rather than in account settings, because we moved every commerce surface under one tab after IA testing.
2The handoff, stated plainly. The copy tells the seller they are going to Stripe before they go. We chose disclosure over disguise because concept testing showed an unannounced redirect is what made the old approach feel broken.
3Co-branded return path. Stripe's onboarding carries Teachable's mark and returns the seller to our admin, so the detour reads as one product borrowing another rather than a dead end.
Payment settings empty state with country select and continue to Stripe onboarding 1 2
Co-branded Stripe onboarding carrying the Teachable mark 3

Turning on the payment methods that customers actually use

The old stack supported 7 payment methods and adding one was a project in itself. This page is what 27 payment methods looks like when a seller has the ability to control them all individually.

1Grouped by how buyers pay, not by Stripe's internal taxonomy. Cards, wallets, bank redirects, and buy now pay later.
2Regional context on every row. “Popular in the Netherlands” tells a seller whether a toggle is relevant to their location.
3The seam, again, and on purpose. A few methods still require Stripe's dashboard. We surfaced that as a labeled path rather than hiding the capability.
Payment methods settings grouped into cards, wallets, bank redirects, and buy now pay later 1 3 2

Styling a checkout without breaking it

Sellers lost custom testimonial and copy blocks in this migration. What they got instead was control over the things that change conversion, with a preview and a guardrail.

1Live preview beside the controls, so a seller sees their buyer's view while choosing, rather than after publishing.
2Flexibility, with guidance. Brand color pickers produce unreadable checkouts. The page names the ratio, the standard, and three colors that pass.
Checkout customization tab with brand colors, contrast warning, and live preview 1 2

The transaction table, custom built

A suitable experience for new and old sellers alike: one that utilizes both Stripe and Teachable's data to offer an exhaustive front end experience.

1Earnings broken out. Author and affiliate splits, tax held, fees collected, chargebacks, refunds. A seller running a business needs the composition, not the total.
2Disputes has its own tab. Refunds and chargebacks are handled in a Stripe table, offering more functionality than previously we offered.
3Search and saved filters across the full history. Multi-year reconciliation was the specific task the embedded component could not complete.
Custom transactions table with purchaser, product, earnings breakdown, and saved filters 2 1 3
{{ modalImg }}
07 · What research changed

Two interview findings that moved scope, not opinions we already held.

“It's great that students' payment currency changes automatically according to the student location.”

Sellers had been treating international buyers as a cost of doing business, not a market. Adaptive pricing moved from a nice-to-have in the MVP debate to a launch requirement, and became the lead capability in the migration materials.

“Teachable's current subscription billing capabilities don't meet my needs. What you're showing here definitely would.”

The gap sellers felt most was recurring revenue, not one-time checkout. We scoped Stripe Billing and the student-facing subscription portal into the MVP rather than treating subscriptions as a follow-on.

08 · Reflection

I relied too heavily on Stripe's embedded payments table. It was fine for the sellers we launched to, and I let that be enough. Concept testing with our highest-revenue accounts later showed it would not carry the transaction data their businesses actually ran on, and we built a custom table as a follow-up to make sure nobody lost history in the migration.

What I would do differently is treat a vendor's components as a question rather than an answer, and go to Stripe's own design team early instead of reading their documentation. The part I would keep is the handoff. I transferred the finished prototype along with the reasoning behind every decision in it, so that when someone challenged one of them, the PD I managed could defend it themselves.