Self-Directed System · Affiliate & Creator Growth · Case Study 05
Connecting acquisition to attributable revenue, commissions, reversals, payouts, and risk
A governed creator-revenue system connecting referral acquisition to Stripe-derived revenue, commissions, reversals, payout eligibility, analytics, risk, and creator performance.
Financial SystemsStripeFull-Stack
7Implementation Checkpoints
1 MonthCOMMISSION HOLD
Append-OnlyFinancial Ledger
01 / Problem & Context
What had to become true
The challenge
A governed creator-revenue system connecting referral acquisition to Stripe-derived revenue, commissions, reversals, payout eligibility, analytics, risk, and creator performance.
My role
I owned the problem framing, system/product decisions, implementation direction, validation, and iteration represented in this case study. The emphasis is on the decisions that changed the system—not a feature inventory.
02 / Decisions & Tradeoffs
Architecture follows the constraint
Key decisions
- Treat existing users as canonical identity and affiliate status as a capability, not a separate user role.
- Store money in minor units and commission rates in basis points.
- Keep financial state backend-authoritative and historically reconstructable.
- Use append-only commission/reversal records instead of mutating financial history.
- Keep affiliate payouts human-controlled while customer collection and revenue ingestion are automated through Stripe.
Working loop
PROBLEM → INVESTIGATE → ARCHITECT → BUILD → VALIDATE → ITERATE
The implementation was treated as a measured loop: diagnose the actual constraint, make the smallest architectural change that resolves it, then verify behavior and quality before moving forward.
03 / System Design & Build
What I built
- Applications → affiliate accounts → programs → historical assignments → campaigns/referral links.
- Clicks and cookies bind attribution to registration without exposing referred-customer PII to affiliates.
- Stripe payment events feed idempotent revenue processing.
- Monthly payments receive a one-calendar-month commission hold; annual commissions vest monthly and each tranche receives its own one-calendar-month hold.
- Refunds/disputes create explicit negative reversal rows.
- Analytics, risk controls, authorization isolation, and creator-performance learning complete the lifecycle.
04 / Validation & Outcomes
Evidence over claims
Validation
- Seven implementation checkpoints completed and tested.
- Financial history remains reconstructable across program changes and reversals.
- Calendar-month hold logic handles corresponding dates and month-end edge cases.
What changed
Affiliate software becomes financial infrastructure the moment attribution changes money. Auditability, historical state, privacy boundaries, and reversals are core architecture—not admin afterthoughts.
05 / Skills & Positioning
What this project demonstrates
Financial Systems · Stripe · Full-StackThis case sits inside a broader portfolio spanning AI systems and agents, full-stack products and revenue infrastructure, design engineering, and creative AI leadership.
Portfolio Map
Explore the full system of work
Each project is a different proof point. The current project is highlighted so the portfolio reads as one connected capability map rather than a collection of isolated case studies.
