Django E-commerce Launch Checklist

Problem statement

An online store built with Django, Saleor, Oscar, or a custom app is about to launch or run a big campaign. Store failures are expensive in a specific way: double charges, orders without payments, overselling stock, missing confirmation emails, and a checkout that slows down exactly when traffic peaks. This checklist focuses on the parts of a Django deployment that decide whether money and orders stay consistent and whether customers can complete a purchase.

1. Verify payment flows end to end in live mode with a real card, including refunds and failed payments.
2. Make payment webhooks idempotent and stored before processing; reconcile orders with payments daily.
3. Protect inventory with database constraints or select_for_update so stock cannot go negative.
4. Send transactional emails through a provider with SPF, DKIM, and DMARC set up, via Celery with retries.
5. Load test checkout, monitor checkout-specific metrics, and have a rollback and communication plan for launch day.

Checklist

Payments

• Live mode keys configured in production only; test keys in staging.
• End-to-end test in live mode: successful payment, declined card, 3-D Secure challenge, refund, partial refund.
• Webhook endpoint verified by signature, stores events with unique IDs, processes them idempotently.
• Order state changes only on confirmed payment events (webhooks), not on the browser redirect alone.
• Daily reconciliation job comparing paid orders with provider payments, alerting on mismatches.

Orders and inventory

• Stock decrements in a transaction with select_for_update or an atomic F() update guarded by a check constraint (stock >= 0).
• Idempotency for order creation (double-click and retry safe): unique order tokens or idempotency keys.
• Abandoned reservations released by a scheduled task.
• Prices, discounts, and taxes calculated server-side; client-submitted totals never trusted.

Emails and notifications

• Order confirmation, shipping, and refund emails sent asynchronously via Celery, triggered after commit.
• Sending domain authenticated with SPF, DKIM, and DMARC; test messages land in inboxes, not spam.
• Bounce and complaint handling configured with the email provider.
• Admin notifications for failed payments, failed webhooks, and low stock.

Performance and capacity

• Load test of browse, cart, and checkout at expected peak plus margin; database indexes for order and product queries.
• Product and category pages cached (per-view or CDN) with correct invalidation on price and stock changes.
• Checkout and account pages never cached publicly.
• Database connection limits and Celery capacity checked for peak order rates.

Monitoring, legal, and launch day

• Dashboards and alerts for checkout conversion, payment failures, webhook backlog, and error rates.
• Sentry and uptime monitoring active; on-call person assigned for launch day.
• Legal pages (terms, privacy, returns), cookie consent where required, and correct tax and VAT display.
• Backups verified by a recent restore; rollback plan and status page or social channel for customer communication.

Explanation

E-commerce combines external systems (payment providers, email, shipping) with internal state (orders, stock, prices), and failures usually happen at the seams: a webhook arrives twice or late, a customer double-clicks, a Celery worker restarts mid-task. Django gives you the tools to make these seams safe: transactions, row locks, constraints, on_commit, and idempotent tasks. The checklist makes sure they are used where money and stock are involved, and that monitoring watches the business flow, not just CPU and error rates.

Edge cases / notes

• Marketplace or multi-currency. Rounding and currency conversion need explicit rules and tests.
• Subscriptions. Recurring billing adds dunning, proration, and webhook ordering concerns.
• Flash sales. Extreme spikes may need queueing or waiting rooms in front of checkout.

Next steps

• Keep card data out of scope with the Django PCI DSS Checklist.
• Make webhooks robust with Deploy Django Stripe Webhooks in Production.
• Prepare for peaks with the Django Traffic Spike Readiness Checklist.

FAQ

Should orders be confirmed on the payment redirect?

No. Confirm on the provider's webhook; redirects can fail or be faked.

How do I prevent overselling in Django?

Update stock in a transaction with select_for_update or an atomic F() update, backed by a database constraint.

How do I avoid double charges?

Use idempotency keys with the payment provider and make order creation idempotent.

What should I monitor on launch day?

Checkout conversion, payment failure rate, webhook backlog, error rate, and response times on cart and checkout.