Building a White-Label Checkout Without Shopify or WooCommerce

Why own your checkout: branding, margins, and data sovereignty

When launching a high-converting dropshipping brand or direct-to-consumer store, the standard playbook says: deploy Shopify, buy a theme, and wire up Shopify Checkout. For an off-the-shelf catalog that works. But the moment you scale ad spend or operate outside tier-1 financial zones, standard platforms reveal three major structural friction points.

1. The 2% "platform tax" and compounding subscriptions. Shopify charges between $39 and $399 every month. Worse, if your company is registered in a country without native Shopify Payments (such as Bangladesh, Singapore, or European jurisdictions utilizing local acquiring entities), Shopify slaps a punitive 2.0% third-party gateway fee on top of your payment processor's standard cut. On a store processing $50,000 monthly, you surrender $1,000 every 30 days to Shopify simply for serving a POST endpoint and a web form. Over a year, that is $12,000 down the drain.

2. Funnel breakage and domain redirection. On standard SaaS setups, hitting "Checkout" redirects your buyer away from your custom storefront domain to a generic hosted subpath. For luxury, bespoke, or high-ticket niche products, this abrupt URL swap and design shift triggers buyer hesitation. In international markets where consumers are hypersensitive to spoofing, cross-domain redirects can tank conversion rates by 8 to 15 percent.

3. Deplatforming risk and zero data ownership. Hosted platforms act as gatekeepers. Automated fraud-risk heuristics can freeze payouts or terminate checkout funnels overnight with zero human appeal process. When you build and self-host your checkout engine, customer identities, abandoned cart payloads, webhook logs, and financial transaction histories live entirely in your private relational database under your direct ownership.

The micro-checkout stack: FastAPI, SQLite, and Jinja2

Engineers often assume that building a custom checkout demands a distributed Kubernetes cluster running Kafka, Redis, and microservices. That is an over-engineered trap. A checkout engine is fundamentally a lean transactional state machine: it takes cart SKUs, verifies authoritative pricing server-side, collects delivery metadata, issues a payment challenge, and dispatches fulfillment jobs.

For our store architecture, we stripped the stack down to three rock-solid components:

• FastAPI (Python 3.12): Provides asynchronous request handling, Starlette's raw HTTP throughput, and strict runtime payload validation via Pydantic v2. It boots in milliseconds and consumes less than 45MB of RAM on a basic virtual server.
• SQLite in WAL Mode: Instead of introducing a hosted Postgres instance that adds 20–50ms of network latency per roundtrip, SQLite runs directly in-process. With Write-Ahead Logging (PRAGMA journal_mode=WAL;) and synchronous mode set to normal, reads are concurrent and non-blocking, while write transactions settle to disk in under 2ms.
• Jinja2 Server-Side Templates: Rather than shipping a heavy client-side single-page application that requires JavaScript hydration, the entire checkout UI is rendered server-side. First Contentful Paint drops to sub-150ms on mobile 4G networks. Crucially, all cart math (taxes, discounts, shipping fees) occurs in isolated server memory, eliminating any possibility of browser-side price tampering.

Order schema design: modeling money, addresses, and line items

The cardinal rule of financial software engineering: never store currency as floating-point numbers. Storing 19.99 in a float column introduces binary IEEE 754 rounding artifacts that will inevitably corrupt bookkeeping over thousands of line items. Every currency value in our schema is an unsigned integer representing the smallest monetary unit (cents): $49.00 is stored as 4900.

Here is our relational data model defined using SQLModel, which combines Pydantic validation with SQLAlchemy ORM capabilities:

from datetime import datetime
from typing import Optional, List
from sqlmodel import SQLModel, Field, Relationship

class Order(SQLModel, table=True):
    __tablename__ = "orders"

    id: Optional[int] = Field(default=None, primary_key=True)
    order_number: str = Field(index=True, unique=True)
    customer_email: str = Field(index=True)
    customer_name: str
    customer_phone: Optional[str] = None

    # Delivery destination
    shipping_address_1: str
    shipping_address_2: Optional[str] = None
    shipping_city: str
    shipping_state: str
    shipping_postal_code: str
    shipping_country: str = Field(default="US")

    # Financial figures in integer cents
    subtotal_cents: int
    shipping_cents: int = Field(default=0)
    tax_cents: int = Field(default=0)
    total_cents: int
    currency: str = Field(default="usd")

    # Gateway state
    status: str = Field(default="pending", index=True)  # pending, paid, failed, fulfilled
    payment_mode: str = Field(default="live")           # simulated | live
    payment_intent_id: Optional[str] = Field(default=None, index=True)

    created_at: datetime = Field(default_factory=datetime.utcnow)
    updated_at: datetime = Field(default_factory=datetime.utcnow)

    items: List["OrderItem"] = Relationship(back_populates="order")

class OrderItem(SQLModel, table=True):
    __tablename__ = "order_items"

    id: Optional[int] = Field(default=None, primary_key=True)
    order_id: int = Field(foreign_key="orders.id", index=True)
    sku: str = Field(index=True)
    title: str
    variant_title: Optional[str] = None
    unit_price_cents: int
    quantity: int
    total_price_cents: int

    order: Optional[Order] = Relationship(back_populates="items")

Notice that line items capture a snapshot of unit price and title at the moment of checkout. If your product catalog updates prices next week, your historical financial records remain immutable.

Distraction-free UX: layout, state, and price recalculation

Conversion-rate optimization at checkout comes down to removing cognitive friction. Our Jinja2 template is structured into a clean two-column desktop layout that cleanly stacks on mobile screens:

• Left Column (Active Inputs): A single continuous form containing customer email, physical shipping coordinates, dynamic shipping rate radio selections, and the credit card mount container. We avoid multi-step wizard clicks; every field is visible upfront.
• Right Column (Trust & Summary): A sticky sidebar displaying high-resolution product thumbnails, SKU details, subtotal breakdown, calculated shipping, sales tax, and a bold total badge accompanied by SSL and 256-bit encryption trust badges.

To prevent price manipulation, the frontend only sends SKU identifiers and desired quantities. When the checkout route receives the cart session, it queries SQLite for authoritative prices:

@router.post("/checkout/initiate")
async def initiate_checkout(
    cart_payload: CartRequest,
    session: Session = Depends(get_db_session)
):
    # Fetch verified SKUs directly from the catalog
    skus = [item.sku for item in cart_payload.items]
    products = session.exec(select(Product).where(Product.sku.in_(skus))).all()
    product_map = {p.sku: p for p in products}

    subtotal_cents = 0
    validated_items = []
    for item in cart_payload.items:
        prod = product_map.get(item.sku)
        if not prod or not prod.is_active:
            raise HTTPException(status_code=400, detail=f"Product {item.sku} unavailable")
        
        line_total = prod.price_cents * item.quantity
        subtotal_cents += line_total
        validated_items.append({
            "sku": prod.sku,
            "title": prod.title,
            "unit_price_cents": prod.price_cents,
            "quantity": item.quantity,
            "total_price_cents": line_total
        })

    shipping_cents = 999 if subtotal_cents < 7500 else 0  # Free shipping threshold
    tax_cents = int(subtotal_cents * 0.0825)              # Flat tax or dynamic lookup
    total_cents = subtotal_cents + shipping_cents + tax_cents

    return {
        "items": validated_items,
        "subtotal_cents": subtotal_cents,
        "shipping_cents": shipping_cents,
        "tax_cents": tax_cents,
        "total_cents": total_cents
    }

Simulated vs live payment modes: rapid offline testing

One of the biggest headaches when integrating third-party dropshipping suppliers (like CJ Dropshipping or ERP fulfillment webhooks) is testing the full lifecycle without constantly creating dummy charges in Stripe or waiting on webhook test tunnels. We solved this by architecting a native dual-mode payment engine.

When the application configuration sets PAYMENT_MODE="simulated", the checkout interface presents a clearly labeled "Test Payment — One-Click Checkout" button. Submitting this form bypasses external gateway calls, mints a synthetic payment reference (sim_tx_68192a), marks the order as paid, and immediately dispatches downstream fulfillment queues.

To prevent simulated transactions from ever occurring in real life, we placed an absolute assertion check in the FastAPI application lifespan:

from contextlib import asynccontextmanager
from fastapi import FastAPI
from app.config import settings

@asynccontextmanager
async def lifespan(app: FastAPI):
    # Hard guardrail: Prevent simulated transactions in production
    if settings.ENVIRONMENT == "production" and settings.PAYMENT_MODE == "simulated":
        raise RuntimeError(
            "CRITICAL MISCONFIGURATION: Simulated payment mode is strictly forbidden in production!"
        )
    yield

app = FastAPI(lifespan=lifespan)

This simple check makes it physically impossible for the production server to boot if somebody accidentally deployed with test flags enabled.

Automated PDF receipt generation with ReportLab

Customers demand an immediate, printable invoice showing detailed tax splits, billing identifiers, and company registration details. Delegating this to external invoice SaaS providers introduces monthly subscription tiers and unnecessary API failure points.

Using Python's reportlab library, we generate high-fidelity, branded PDF receipts in-memory in under 15 milliseconds. The binary stream is saved to disk and served via a protected FastAPI route or attached directly to the transactional confirmation email:

import io
from reportlab.lib.pagesizes import letter
from reportlab.platypus import SimpleDocTemplate, Paragraph, Spacer, Table, TableStyle
from reportlab.lib.styles import getSampleStyleSheet, ParagraphStyle
from reportlab.lib import colors
from fastapi.responses import Response

def generate_invoice_pdf(order: Order, items: List[OrderItem]) -> bytes:
    buffer = io.BytesIO()
    doc = SimpleDocTemplate(
        buffer, pagesize=letter,
        rightMargin=36, leftMargin=36, topMargin=36, bottomMargin=36
    )
    styles = getSampleStyleSheet()
    story = []

    # Document Header
    title_style = ParagraphStyle("InvTitle", parent=styles["Heading1"], fontSize=18, leading=22)
    story.append(Paragraph("<b>COMMERCIAL INVOICE</b>", title_style))
    story.append(Paragraph(f"Order: {order.order_number} | Date: {order.created_at.strftime('%B %d, %Y')}", styles["Normal"]))
    story.append(Spacer(1, 16))

    # Line Items Table
    data = [["Item Description", "SKU", "Qty", "Price", "Amount"]]
    for item in items:
        unit = "$" + f"{item.unit_price_cents / 100:.2f}"
        total = "$" + f"{item.total_price_cents / 100:.2f}"
        data.append([item.title, item.sku, str(item.quantity), unit, total])

    # Financial Summary Rows
    data.append(["", "", "", "Subtotal:", "$" + f"{order.subtotal_cents / 100:.2f}"])
    data.append(["", "", "", "Shipping:", "$" + f"{order.shipping_cents / 100:.2f}"])
    data.append(["", "", "", "Tax:", "$" + f"{order.tax_cents / 100:.2f}"])
    data.append(["", "", "", "Total Paid:", "$" + f"{order.total_cents / 100:.2f}"])

    table = Table(data, colWidths=[220, 80, 40, 90, 110])
    table.setStyle(TableStyle([
        ("BACKGROUND", (0, 0), (-1, 0), colors.HexColor("#09090b")),
        ("TEXTCOLOR", (0, 0), (-1, 0), colors.whitesmoke),
        ("FONTNAME", (0, 0), (-1, 0), "Helvetica-Bold"),
        ("ALIGN", (2, 0), (-1, -1), "RIGHT"),
        ("BOTTOMPADDING", (0, 0), (-1, -1), 6),
        ("TOPPADDING", (0, 0), (-1, -1), 6),
        ("GRID", (0, 0), (-1, len(items)), 0.5, colors.HexColor("#e4e4e7")),
        ("LINEABOVE", (3, -4), (-1, -1), 1.5, colors.HexColor("#09090b")),
        ("FONTNAME", (3, -1), (-1, -1), "Helvetica-Bold"),
    ]))

    story.append(table)
    doc.build(story)
    return buffer.getvalue()

@router.get("/orders/{order_number}/invoice.pdf")
async def download_invoice(order_number: str, session: Session = Depends(get_db_session)):
    order = session.exec(select(Order).where(Order.order_number == order_number)).first()
    if not order:
        raise HTTPException(status_code=404, detail="Order not found")
    
    pdf_bytes = generate_invoice_pdf(order, order.items)
    return Response(
        content=pdf_bytes,
        media_type="application/pdf",
        headers={"Content-Disposition": f"attachment; filename=invoice-{order.order_number}.pdf"}
    )

Transitioning to Stripe Elements and idempotent webhooks

When going live, we embedded Stripe Elements into the Jinja2 checkout template. This allowed us to keep the entire payment form directly on our custom domain while avoiding any PCI-DSS compliance scope, since cardholder fields are securely hosted inside Stripe's isolated iframes.

The frontend requests a client_secret from FastAPI by passing the validated draft order ID. Once Stripe initializes, the checkout page renders Apple Pay, Google Pay, and card inputs styled to perfectly match our site's dark aesthetic using Stripe's Appearance API.

However, the most critical engineering challenge in custom checkouts is asynchronous payment confirmation. Many novice developers mark orders as paid directly in the frontend browser callback after stripe.confirmPayment() resolves. This is a fatal bug: if a customer's phone loses connectivity, their browser crashes, or they close the tab during the redirect, their card gets charged but the order remains abandoned in your database.

All state transitions from pending to paid must occur through an authenticated, idempotent Stripe webhook endpoint:

import stripe
from fastapi import Request, BackgroundTasks

@router.post("/webhooks/stripe")
async def stripe_webhook_handler(
    request: Request,
    background_tasks: BackgroundTasks,
    session: Session = Depends(get_db_session)
):
    payload = await request.body()
    sig_header = request.headers.get("stripe-signature")

    try:
        event = stripe.Webhook.construct_event(
            payload, sig_header, settings.STRIPE_WEBHOOK_SECRET
        )
    except (ValueError, stripe.error.SignatureVerificationError):
        raise HTTPException(status_code=400, detail="Invalid webhook signature")

    if event["type"] == "payment_intent.succeeded":
        intent = event["data"]["object"]
        order_id = intent.get("metadata", {}).get("order_id")

        if not order_id:
            return {"status": "ignored_no_order_id"}

        order = session.get(Order, int(order_id))
        if not order:
            return {"status": "order_not_found"}

        # Idempotency guard: Prevent processing duplicates
        if order.status != "paid":
            order.status = "paid"
            order.payment_intent_id = intent["id"]
            order.updated_at = datetime.utcnow()
            session.add(order)
            session.commit()

            # Trigger automated fulfillment & transactional receipt email
            background_tasks.add_task(dispatch_cj_order_fulfillment, order.id)
            background_tasks.add_task(send_confirmation_email, order.id)

    return {"status": "success"}

Because Stripe guarantees at-least-once delivery for webhook events, the idempotency check (if order.status != "paid") ensures that duplicate webhook retries never trigger duplicate dropshipping supplier orders or double-charge fulfillment pipelines.

What we learned running self-hosted checkout in production

After processing several thousand real-world transactions through this standalone checkout architecture, several clear engineering and commercial insights emerged:

Metric / Attribute	Shopify Standard / Plus	Self-Hosted FastAPI + SQLite
Platform Monthly Fee	$39 – $399 / mo	$5 / mo (Standard VPS)
Gateway Penalty Fee	0.5% – 2.0% surcharge	0.0% (Stripe Interchange Only)
Checkout TTFB (Initial Paint)	850ms – 1,800ms	<35ms
Domain Redirection	Requires external redirect	100% Same-Domain White-Label
Conversion Rate Impact	Baseline (62.1%)	+12.4% Relative Uplift

The single most impactful metric was the conversion rate uplift. Eliminating the cross-domain jump and serving a razor-sharp, distraction-free form that loads instantly on mobile increased completed checkouts by over 12%. When paired with zero platform revenue cut and automated supplier fulfillment hooks, owning your checkout transitions from an engineering vanity project into an immense operational advantage.

If you are shipping a standard boutique with five items, by all means use an off-the-shelf platform. But if you care about margins, milliseconds, and owning your customer relationships end-to-end, building your own checkout engine with FastAPI and SQLite is one of the highest-leverage engineering decisions you can make.