E-commerce Order ID Generator

Order codes for online stores: multi-channel identifiers that scale

When an online store sells through several sales channels — its own website, a mobile app and one or more marketplaces — a single sequential #0001 stops being enough. The same code may collide across systems, customer support cannot tell at a glance where the order came from, and reconciliation with payment processors becomes a manual chore. The pragmatic answer is a channel-prefixed identifier: a short, URL-safe, alphanumeric code that encodes the origin, then a sequence or timestamp, and optionally a checksum.

ORD-W-000123     // website (web)
ORD-M-000124     // mobile app
ORD-ML-007821    // Mercado Livre
ORD-SH-004499    // Shopee
ORD-AM-128340    // Amazon
ORD-MG-099122    // Magalu (Magazine Luiza)

Hubs and integration platforms in the Brazilian market

Brazilian e-commerce relies heavily on hub-style aggregators that ingest orders from many marketplaces into a single ERP-like interface. Bling, Tiny, Olist, Tray and Anymarket are the dominant names. Each hub assigns its own internal order ID, then exposes the original marketplace ID and your e-commerce platform's ID alongside. A single order can carry four identifiers at once: the marketplace one (Mercado Livre, Shopee, Amazon), the hub one (Bling, Olist), the store one (VTEX, Tray, Loja Integrada) and the ERP one (Bling, Omie, ContaAzul). Designing your code generator with a stable, traceable prefix from day one saves weeks of detective work later.

Order lifecycle and payment states in Brazil

Brazilian online orders move through a state machine that mirrors the local payment methods: aguardando pagamento (awaiting payment) → pago (paid) → em separação (picking) → enviado (shipped) → entregue (delivered) → finalizado (closed) — with branches into cancelado and devolvido (returned). PIX clears in seconds, credit card auth is immediate but capture may be deferred, and boleto bancário can take up to three business days to confirm. Mock order codes used in integration tests should cover every state transition so QA does not have to wait for real payments to clear.

{
  "orderCode": "ORD-W-000123",
  "channel": "website",
  "status": "em_separacao",
  "payment": { "method": "pix", "txid": "E12345..." },
  "shipping": { "carrier": "loggi", "tracking": "JT0012345BR" },
  "createdAt": "2026-05-29T14:22:11-03:00"
}

Shipping integrations: Correios, Loggi, J&T, Total Express

Once an order ships, the order code typically gets paired with a carrier tracking number. Correios uses 13-character codes ending in BR (e.g. AA123456789BR); Loggi, J&T Express, Total Express, Jadlog and Mandaê each have their own formats. Mock order generators are ideal for seeding test environments with realistic combinations so the dashboard, the customer-area tracking page and the WhatsApp notification template can all be visually QA'd before launch.

Fraud, BI and platform-specific format constraints

• Fraud detection providers (Konduto, ClearSale, Stone Antifraude) score each order; the order code is the join key across their feedback API and your ERP.
• BI dashboards in Power BI, Metabase or Looker Studio typically slice by channel prefix — yet another reason to keep the prefix consistent.
• Stripe uses pi_, ch_, cs_; Magento defaults to a 9-digit sequential; Shopify uses #1001 incrementing per store. Pick a length of 10–15 characters total to fit gracefully in all of them.
• UUIDs are valid but overkill for customer-facing display — too long to read on the phone, no human pattern. Reserve them for internal IDs and use the short code for display.
• Test prefix: add a TST- prefix in non-production environments so a leaked code never accidentally matches a real one.

FAQ

Should I use a different prefix for each channel? Yes, ideally. It makes customer support faster (the agent knows the origin without lookup), enables clean BI slicing and avoids cross-channel collisions during the rare cases when systems get merged.

What is the ideal length? Ten to fifteen characters total. Short enough to read aloud over the phone, long enough to keep entropy and avoid collisions across millions of orders.

Can I just use a UUID? Technically yes, but UUIDs are 36 characters with hyphens — too long for customer display, hard to dictate over the phone, no embedded channel information. Use UUIDs internally and a short code for the customer-facing layer.

How do I avoid collisions across marketplaces? Let the marketplace own its native ID (Mercado Livre's, Shopee's) and add your internal short code on top. Store both, search by either, and customer support always wins.