Order Code Generator

Designing a good order number

An order number — código de pedido in Portuguese — is the unique identifier a merchant assigns to every commercial transaction. It travels through the checkout, the payment gateway, the WMS, the invoicing engine (Nota Fiscal Eletrônica), the shipping label, the marketplace API and finally the customer support ticket. A bad order number causes lost orders, ghost refunds and angry phone calls; a well-designed one is short, sortable, unique and human-readable.

A typical pattern combines three blocks: a prefix (ORD, PED, SO for Sales Order, PO for Purchase Order), a date or epoch component and a sequence with optional check digit. Examples in production today: PED-2026-001234, SO20260615123, ORD-2026-06-0001234.

Properties of a robust order ID

• Unique across all channels and time windows.
• Monotonic (or at least roughly increasing) — useful for sharding, indexing and ordering by recency.
• Human-readable — customer support reads it over the phone; 8–12 characters is the sweet spot.
• Channel- and environment-aware — embed flags for DEV, STAGING, PROD and for online / in-store / B2B / marketplace orders.
• Collision-resistant — append a timestamp, serial and random salt.

Algorithms compared

UUID v4 is collision-proof but unreadable — terrible for phone support. Snowflake IDs (originally from Twitter) embed a timestamp and machine ID, are 64-bit, monotonic and shard-friendly. NanoID is URL-safe and shorter than UUID. The pragmatic favourite for Brazilian e-commerce is prefix + counter + check digit, occasionally combined with a daily reset and a Luhn-style check character to catch typos when an attendant rekeys it.

Integration touchpoints

Order numbers flow through the entire stack: ERPs (SAP, TOTVS, Bling, ContaAzul, Omie), CRMs (HubSpot, Salesforce, RD Station), marketplaces (Mercado Livre, Magazine Luiza, Amazon BR, Shopee) and shipping carriers (Correios, Jadlog, Loggi). For B2B vendor portals each customer may have its own numbering scheme that must be stored alongside the merchant's internal ID. In Brazil the order number must appear on the NF-e — usually in the xPed field or in infCpl observations — so the tax authority can reconcile invoice and order.

Order status lifecycle

A canonical flow: created → confirmed → paid → picked → packed → shipped → out for delivery → delivered → (optionally) returned → refunded. Some retailers expose a shortened version to the customer (Pedido recebido / Em preparação / Enviado / Entregue) while keeping the granular states internal. Friendly user-facing IDs ("Pedido P-123-ABC") with emoji are common in D2C brands.

FAQ

Random or sequential? Hybrid is best — daily sequential counter plus a short random suffix so competitors cannot scrape volumes from sequential IDs.

Can I reset the counter every year? Yes, as long as the year is part of the prefix (PED-2026-0001). Without a year prefix, resetting breaks idempotency in downstream systems.

Does the order number need to be visible to the customer? Yes — show it on the confirmation page, the receipt e-mail and the shipping tracking page so the buyer can reference it in any support contact.

Should I expose internal IDs in URLs? Avoid it. Use an opaque token or hashed identifier in the public URL and keep the raw sequence number for internal use only — it prevents enumeration attacks and competitive scraping.