Every pricing change was somebody else's sprint.
When the transaction layer belongs to a provider, the roadmap for it belongs to them too. Commercial decisions the business wanted to make queued behind an external backlog.
Fintech · LMS · 2026
Payments for five million learners, brought in-house.
A ~5M-user e-learning product was renting its most revenue-critical path from a third party. I led product for an in-house payment platform — owning transaction flows, requirements and rollout with engineering and compliance, so the flows that carry the revenue are ones the business can change.
- ~5M
- Learners on the product payments were moved for
- In-house
- Transaction flows owned, not rented from a provider
- 4
- Disciplines directed — engineering, design, QA, DevOps
- Compliance
- Partnered from definition, not at review time
Executive Summary
The payment path was the one part of the product we could not change.
KnowledgeCity serves roughly five million learners. Every one of them who pays does so through a transaction flow that touches revenue, compliance and the learning experience at the same moment — and that flow sat with a third party.
That is a tolerable arrangement right up until you need to change something. Pricing structures, tax handling, refunds, enterprise invoicing, the recovery path when a charge fails: each one becomes a support ticket to somebody else's roadmap.
I led product for bringing it in-house. That meant mapping the transaction flows first, writing requirements against those maps, and putting compliance in the room at definition rather than at review. Engineering, design, QA and DevOps ran on a single cadence on US hours through delivery.
At a glance
- Role
- Senior Product Manager
- Organisation
- KnowledgeCity
- Domain
- Payments · LMS / EdTech
- Scale
- ~5M learners
- Owned
- Transaction flows, requirements, rollout
- Partners
- Engineering, design, QA, DevOps, compliance
Section 02 — The Problem
Renting your revenue path is cheap until the day it is not.
Payments and compliance are the same conversation.
Handling money at this scale is not a feature with a compliance review at the end. The constraints shape the flow itself, which is why compliance was in the definition work rather than the sign-off.
A failed charge is a failed lesson.
On an e-learning product the payment path sits directly between a learner and the thing they came for. There is no forgiving version of getting it wrong.
Section 03 — Research & Discovery
Discovery started with the flows, not the feature list.
Before any requirement was written, the existing transaction flows were mapped end to end — what happens on a successful charge, what happens on a failure, what the learner sees at each step, and where money and state actually change hands.
Mapping first is the whole trick. A requirement written against a flow you have drawn is testable; a requirement written against an assumption is a defect waiting for QA to find it.
Four groups, asked the same question differently.
Finance, support, compliance and the enterprise side all touch payments and all describe the problem in their own vocabulary. Discovery meant translating four accounts of the same flow into one map everyone would recognise — and treating any place they disagreed as a requirement rather than a misunderstanding.
Support contacts are the cheapest research available.
Payment-related tickets are a standing record of where the existing flow confuses people or fails them, collected continuously and for free. Categorising them gave the requirements a starting point grounded in what learners had already complained about, rather than what the team assumed.
Section 04 — Current State Analysis
What the old path could and could not do.
CapabilityThird-party pathIn-house platform
Transaction flow definitionProvider-definedOwned and documented
Pricing & packaging changesExternal roadmap dependencyInternal backlog
Compliance postureReviewed downstreamDesigned in from definition
Requirements artefactsProvider documentationBRD / PRD with acceptance criteria
Failure & recovery handlingProvider-defined, opaqueDesigned as a product decision
Before / After
The flows barely changed. Who could change them did.
A learner buying a course sees roughly the same steps either way. The difference is what happens when the business needs that path to behave differently — which, on a product this size, is constantly.
Before
Provider-owned
Changing the payment path
Identify the change the business needs
Raise it with the provider and wait for triage
External roadmapTake whatever ships, whenever it ships
No controlWork around the gap in the product until then
Every commercial decision that touched payments queued behind somebody else's priorities.
After
Team-owned
Changing the payment path
Identify the change the business needs
Write it against a transaction flow we documented
Prioritise it on our own backlog
Ship it with our own engineering, QA and compliance
The path that carries the revenue is now on the same backlog as everything else the team owns.
- Owned
- Transaction flows, documented and changeable in-house
- Internal
- Pricing, tax and invoicing changes now sit on one backlog
Section 05 — Competitive Research
In payments, matching the convention beats improving on it.
Checkout is the one flow where originality is a liability. Users have been trained by every other transaction they have ever made, and a novel payment step reads as a risk signal rather than a refinement — particularly on a product where the alternative is simply not buying the course.
That set the default posture: follow the established pattern everywhere the pattern exists, and spend the design effort on the parts that are genuinely specific to this product — enterprise invoicing, entitlement on settlement, and the recovery path after a failed charge.
The checkout itself was deliberately unremarkable.
Card entry, confirmation, receipt — the sequence people have completed a thousand times elsewhere. Every deviation there would have been a chance to lose a sale in exchange for nothing.
Enterprise buying does not fit a consumer checkout.
An organisation purchasing seats for a workforce needs invoicing, approval and allocation — a different job from a learner buying one course. Forcing both down the same path is how platforms end up with a checkout neither audience likes.
Section 06 — Key Insights
Three things that decided the shape of the build.
The flow is the requirement.
Written flows made acceptance criteria fall out almost mechanically, and gave QA something to test against that was not a paraphrase of a conversation.
Compliance is a design input, not a gate.
Treating it as a late review is how payment projects slip. Bringing it into definition meant the constraints shaped the flows while they were still cheap to change.
Scale removes the option of a soft launch.
At ~5M learners, rollout planning is part of the product design rather than a deployment detail handed to DevOps at the end.
Section 07 — Design Strategy
Four principles, agreed before anything was built.
Map the flow before writing the requirement.
A documented flow is testable. An assumption is a defect with a delay on it.
Compliance sits in definition, not in review.
Its constraints change the shape of the flow, so they have to arrive while the shape is still soft.
One cadence across four disciplines.
Engineering, design, QA and DevOps on the same rhythm and US hours — handoffs are where payment defects hide.
Rollout is designed, not scheduled.
At five million learners, how it ships is part of what is being shipped.
Section 08 — The System
Every transaction has a state, and every state has an owner.
Initiated
The learner has committed to a purchase; no money has moved and nothing is entitled yet.
Settled
Payment has cleared and access is granted. The only state in which the learner should see the product change.
Failed / Recovered
The charge did not complete. The state has to hold three things: a clear reason for the learner, a path back to a successful attempt, and enough visibility for support to act without guessing.
Naming the states explicitly is what makes the rest of the documentation possible. Requirements, acceptance criteria and BRD / PRD artefacts all hang off which state a transaction is in and who is accountable for moving it to the next one.
Section 09 — The Features
What actually shipped.
Platform
An in-house payment platform for a ~5M-learner product.
Transaction flows, requirements and rollout owned end to end, delivered with engineering and compliance rather than handed between them.
Documentation
Requirements written as user stories with acceptance criteria.
Stakeholder goals translated into BRD / PRD documentation, so what engineering built and what QA tested came from the same source.
Section 10 — User Flow
The happy path is four steps. The failure path is the one that matters.
Learner selects a course and commits to purchase.
Transaction enters the Initiated state. No money has moved and nothing is entitled yet.
Payment details are captured and submitted.
The step where compliance constraints are most visible in the flow, and where they were designed in rather than reviewed afterwards.
The charge clears and access is granted.
Settled — the only state in which the learner should see the product change.
The charge fails and the recovery path takes over.
The branch that decides whether a failed payment costs a sale or just a moment — which is why it was specified alongside the happy path rather than after it.
Mapping the failure branch with the same care as the success path is the part teams skip. It is also where the money leaks: a learner whose card is declined has already decided to buy, and whether that intent survives the next thirty seconds is a product decision, not a payments detail.
Section 11 — Learner Experience
The best payment experience is the one nobody remembers.
Nobody arrives at an e-learning platform wanting to have a payment experience. They arrive wanting a course. Every decision in the flow was measured against whether it got the learner to the thing they came for with less friction, not more confidence in the payment system.
Owning the flow is what makes that improvable at all. On a rented path the checkout is a fixed cost of doing business; on an owned one, every point of friction becomes a normal backlog item that a product team can argue about, measure and remove.
Section 12 — Impact & Outcomes
Payments moved in-house at five million learners.
- ~5M
- Learners on the product the platform serves
- In-house
- Transaction flows now owned by the business
- 4
- Disciplines run on one delivery cadence
The outcome stated here is deliberately structural rather than numeric: the flows, requirements and rollout are owned, and the roadmap for the revenue path now sits on an internal backlog.
Performance figures for this platform are not published, so none are claimed here. The measures that would settle it are the obvious ones — checkout conversion, failure and recovery rates, support-contact volume, and time-to-ship for a pricing change before versus after — and the last of those is the one this work was actually designed to move.
Section 13 — Reflection
What I would do differently, and what is still open.
Instrument the old path before replacing it.
Structural outcomes are easy to state and hard to prove. Baseline metrics captured before the migration would have made the after-numbers speak for themselves instead of needing narration.
Owning the flow is not the same as having optimised it.
Bringing payments in-house buys the ability to change them. Whether the checkout is actually better for the learner is a separate question, answered by conversion data over time rather than by the migration itself.