Fake E-commerce Order Generator

Fake e-commerce orders: lifecycle, anatomy and realistic mock data

A fake e-commerce order generator is one of the most useful pieces of mock data when building checkout flows, admin dashboards or integrating payment gateways. The output mimics what real platforms — Shopify, WooCommerce, Magento, Vendure, MedusaJS, Saleor, VTEX and Mercado Livre — produce when a customer hits "Place order". Synthetic orders let designers populate Figma prototypes, let backend engineers seed integration tests against Stripe, Mercado Pago, PagSeguro and PayPal sandboxes, and let demo presentations show realistic sales funnels without exposing real customer PII.

A typical order document includes nine sections: a unique order_id (UUID, sequential or composite like #ORD-2026-0042), customer info (name, email, phone, document), an items list (each line with SKU, product name, quantity, unit price), totals (subtotal, tax, shipping fee, discount, grand total), order status, payment method, shipping address with ZIP code, a billing address that may differ, and tracking metadata (carrier, tracking code, ETA).

The finite state machine of order status

Almost every e-commerce platform models orders as a finite state machine that transitions across the same canonical states: Pending (created but not paid) -> Paid (payment authorised and captured) -> Processing (warehouse picking) -> Shipped (carrier scanned) -> Delivered (final scan) plus exception branches like Cancelled, Refunded, Returned and Chargeback. Realistic mock data should respect this graph: a refunded order must have been paid first, a shipped order must have items in stock.

Brazilian e-commerce specifics

In Brazil the payment mix is unique. PIX commands roughly 27% of online transactions, credit card stays around 50%, boleto bancário fills another slice and BNPL options like Picpay Parcelado, Mercado Pago and Koin are growing fast. Every paid order also triggers an NF-e (electronic fiscal note) and the shipping status integrates with Correios tracking codes (format AA123456789BR). The market leaders are Mercado Livre (~70% C2C share), Magazine Luiza, Americanas and Shopee — each with their own checkout flow and payload schema.

Making mock data realistic

Naive generators emit uniform random orders, which is fine for UI work but useless for ML training or BI dashboards. Real e-commerce data follows known distributions: a Pareto curve on products (20% of SKUs drive 80% of revenue), a log-normal curve on order value, and a bi-modal time-of-day pattern with lunch and evening peaks. For load testing, generate 10k-1M orders; for design previews, 5-20 is enough. Compliance is a bonus: synthetic data sidesteps PCI-DSS for card numbers and LGPD for customer records.

Common use cases

• Designing admin dashboard UI in Figma, Sketch or directly in code
• Populating Magento / Shopify / WooCommerce demo stores
• Integration tests for Stripe, Mercado Pago, PIX and PayPal sandbox APIs
• ERP demo data (SAP, Totvs, Bling) and CRM sales pipeline previews
• Anti-fraud rule tuning for ClearSale, Konduto and Hugger Antifraud

Frequently asked questions

Can I use these orders to test a real payment gateway? Only against the sandbox endpoint. Stripe, Mercado Pago and PagSeguro all publish test card numbers and sandbox PIX keys that accept the mock customer data without charging real money.

How realistic does mock data need to be? It depends on the consumer. UI work tolerates very low realism; analytics dashboards need correct distributions; ML training needs realistic seasonality, basket composition and churn signals.

Can I reuse real product IDs or customer emails? No. Generated SKUs and @example.com emails are the safe defaults. Reusing real data violates LGPD/GDPR and breaks idempotency in test environments.

How do I export the data? CSV is the universal format for Excel and BI tools, JSON for APIs and seed scripts. For Brazilian ERPs, XLSX with the right column headers tends to import cleanly into Bling and Tiny ERP.