eComX Build Log — Phase 3: 47 Commits to a Payment Engine
The conversion layer: Stripe payments, Resend email sequences, cookie-based auth, cron-driven drip campaigns, full-funnel analytics, and CSRF protection. 47 commits, 8 plans, zero payment failures.
The Revenue Layer
Phase 1 built the shell. Phase 2 filled it with pages. Phase 3 made it earn money.
The Conversion Layer is the most technically demanding phase — 8 plans covering payments, email infrastructure, authentication, automated sequences, post-purchase flows, analytics, form security, and final verification. Each plan builds on the one before. Each introduces production risk that requires careful testing.
47 commits. Zero payment processing failures. Every plan documented.
Plan 01: Stripe Products and Payment Intents
8-Plan Revenue Engine
Every component of the payment infrastructure, built atomically and verified.
The product ladder — 11 products ranging from free consultations to fully managed services — needed to exist in Stripe before any payment flow could be built.
A CLI script (scripts/create-stripe-products.ts) provisions the entire catalog from a specification file:
- Product names, descriptions, and metadata
- Price points with currency (USD)
- Tax codes and billing intervals
- Feature lists for comparison display
The payment flow uses Stripe Payment Intents (not Checkout Sessions) for maximum control:
- Client requests a PaymentIntent via API route
- Server creates the intent with the product's price
- Client renders the payment form using Stripe Elements
- User completes payment, Stripe confirms the intent
- Webhook fires to confirm processing
Why Payment Intents over Checkout Sessions? Control. Checkout Sessions redirect the user to Stripe's hosted page. Payment Intents keep the user on eComX with a custom-designed payment experience that matches the design token system.
Plan 02: Resend Email Infrastructure
Every significant user action triggers an email:
- Welcome: Immediately after email capture
- Purchase Receipt: After Stripe confirms payment
- Sequence Emails: Drip campaigns over days/weeks
The email system uses React Email for templates — actual React components that render to HTML:
export const WelcomeEmail = ({ name }: { name: string }) => (
<Html>
<Head />
<Body style={bodyStyle}>
<Heading>Welcome to eComX, {name}</Heading>
<Text>Your journey with Context-First AI Development starts here.</Text>
</Body>
</Html>
);
React components for emails mean:
- Type-safe templates (TypeScript catches errors before send)
- Reusable components (Button, Section, Footer shared across templates)
- Preview in the browser during development
- Consistent styling using the design token values
The Resend SDK handles delivery with built-in retry logic and delivery status tracking.
Plan 03: Cookie-Based Authentication
The debug dashboard and admin routes need authentication. But eComX doesn't have user accounts — it doesn't need them. Visitors browse, read, and buy. Only the developer (me) needs authenticated access.
Solution: cookie-based token auth.
- Navigate to
/debug - Enter the debug token
- API route hashes the token and compares against
process.env.DEBUG_TOKEN - On match: set a secure, HttpOnly, SameSite=Strict cookie
- Subsequent requests check the cookie — no re-authentication needed
Why not Supabase Auth? Over-engineering. A single-developer debug dashboard doesn't need a full authentication system with sessions, refresh tokens, and user management. A hashed token cookie is simpler, faster, and just as secure for this use case.
Security properties:
- HttpOnly: JavaScript can't read the cookie (XSS protection)
- Secure: Only transmitted over HTTPS
- SameSite=Strict: Not sent on cross-origin requests (CSRF protection)
- Token never stored in localStorage, never in client-side state
Plan 04: Sequence Engine
The most architecturally interesting system in Phase 3: automated email sequences driven by Vercel Cron.
The problem: send 6 emails over 14 days after a user signs up. Classic drip campaign. Most solutions use dedicated job queues (BullMQ, SQS) or email platform automation (Klaviyo flows).
Our solution uses Supabase as a state machine:
sequence_queue table:
├── subscriber_id
├── sequence_name (e.g., "welcome")
├── current_step (1-6)
├── next_send_at (timestamp)
├── status (pending / processing / completed / failed)
└── retry_count
Vercel Cron runs every minute, queries for sequences where next_send_at <= now():
- Fetch eligible rows
- Mark as
processing(prevents duplicate sends) - Load the correct email template for the current step
- Send via Resend
- Increment
current_step, calculatenext_send_at - Mark as
completed(or schedule next step)
Why this approach?
- No additional infrastructure: No Redis, no message queue, no worker processes
- Verifiable state: Every sequence step is visible in the database
- Reliable: If Cron fails, next run picks up pending sequences
- Debuggable: The debug dashboard shows sequence queue status in real time
Deviation documented: Vercel's minimum cron interval is 1 minute, not 30 seconds. For email sequences with day-level delays, this is irrelevant. Documented for future projects where sub-minute timing matters.
Plan 05: Post-Purchase Activation
After Stripe confirms a payment, a webhook triggers the post-purchase flow:
- Verify webhook signature (Stripe signs every webhook — we verify before processing)
- Create customer record in Supabase
- Send purchase receipt via Resend
- Enqueue activation sequence (6 onboarding emails over 14 days)
- Log the event to the telemetry schema
The activation sequence educates the buyer:
- Email 1 (Day 0): Receipt + immediate next steps
- Email 2 (Day 1): What to expect from Context-First
- Email 3 (Day 3): The BIOS framework explained
- Email 4 (Day 5): Case study highlight
- Email 5 (Day 10): Check-in + support
- Email 6 (Day 14): Advanced resources + community invite
Each email is a React Email component. Each send is logged. Each delivery status is tracked.
Plan 06: Analytics and Tracking
Full-funnel measurement (covered in a separate entry) was integrated in this plan:
- GA4 measurement stream configured
- Client-side pixel events for PageView, ViewContent, AddToCart
- Server-side events for Purchase via CAPI
- Dual-send deduplication via
event_id - Telemetry schema seeded in Supabase
Plan 07: Form Hardening and CSRF Protection
Every form on the site received security hardening:
- CSRF tokens: Double Submit Cookie pattern with per-route token generation
- Rate limiting: API routes throttled to prevent abuse
- Input validation: Server-side validation for every field (client validation is UX, server validation is security)
- Error handling: Structured error responses that don't leak internal details
The gap analysis caught this plan's necessity. The original Phase 3 plan didn't include CSRF protection. /analyze-gaps flagged it before a single form was built.
Plan 08: Build Verification
The final plan verified everything:
- Full build passes (
npm run build) - TypeScript strict mode clean
- Payment flow works end-to-end with test credentials
- Email delivery confirmed in test mode
- Sequence engine processes at least one complete cycle
- Debug dashboard accessible and secure
- All routes render correctly
The 47-Commit Story
47 commits across 8 plans. Each commit traceable to a specific task. Each plan with a summary documenting what was done, what deviated, and what the next plan should know.
The conversion layer is where amateur projects fail — payment integration, webhook processing, email delivery, and security are all areas where partial implementation creates production bugs that lose revenue and trust.
The atomic planning methodology prevented that. Each payment feature was verified before the next began. Each email template was tested before sequences were built. Each security measure was validated before forms were deployed.
47 commits. Zero payment failures. A complete revenue engine.
Want to apply this to your brand?