Order Number Validator

Order ID validation: formats, strategies and trade-offs for e-commerce and B2B SaaS

An order ID (or numero de pedido) is the canonical identifier a system uses to reference a purchase, contract or service request. It anchors the entire downstream workflow — fulfillment, invoicing, customer service, returns, accounting and tax reporting — so its format, uniqueness and guessability are surprisingly load-bearing engineering decisions. A bad choice locks you into either leaking business metrics, customer-service friction or expensive migrations later.

There is no single national standard like CPF or NF-e key. Each company designs its own scheme, typically combining a prefix, a date component and a sequential or random core: PED-2026-001234, ORD-2026-W-001, MAG-2026-77B8A2. The validator on this page checks for the structural rules (length, allowed chars, prefix, checksum) — semantic uniqueness still requires a database lookup.

The five common ID strategies

• Sequential integer (AUTO_INCREMENT BIGINT): smallest, sortable by creation time, trivial to debug. Major downside: leaks volume — a competitor placing an order on Monday and another on Friday can subtract IDs to estimate weekly orders. Easy to enumerate (ID guessing in URLs).
• UUID v4 (128-bit random, 36 chars hex): zero collision in practice, unguessable. Downsides: ugly in URLs (/orders/3f29c1a8-3b7e-4c2a-8f1d-...), bloats DB indexes (B-tree fragmentation), not sortable.
• UUID v7 (time-ordered, RFC 9562, 2024): keeps unguessability of v4 but the first 48 bits are a millisecond timestamp, so the index stays compact and sortable. Recommended modern default.
• Snowflake (Twitter/Discord, 64-bit int): timestamp_ms | worker_id | sequence. Sortable, distributed, fits in a BIGINT, smaller than UUID. Used by Mercado Livre, iFood backends.
• Human-readable (PEDIDO-2026-00001): great for customer service ("dictate your order number"), bad if you also need cryptographic unguessability. Compromise: human prefix + random suffix (PED-2026-7K9MX2).

Trade-off summary

• Sequential: small, sortable, leaks volume, enumerable — never expose in public URLs.
• UUID v4: opaque, no leak, ugly, big index, unsortable.
• UUID v7: opaque, sortable, modern — best default for new systems.
• Snowflake: distributed, sortable, compact — best for high-throughput microservices.
• Hash-based (HMAC-SHA256(secret, internal_id)): keeps internal sequential PK and publishes an opaque ID. Used by Stripe (ch_3M...) and Shopify.

Use cases in Brazilian commerce and SaaS

Real-world patterns across the Brazilian ecosystem:

• E-commerce: Magazine Luiza, Mercado Livre, Americanas and Shopee use opaque order numbers (10-15 chars alphanumeric) so competitors cannot scrape volumes. NF-e infAdic/obsCont field carries the internal pedido reference.
• B2B SaaS: RD Station, Pipefy, Conta Azul typically use Snowflake or UUID v7 for tenant isolation — each customer has its own ID space, often prefixed by tenant code.
• Enterprise ERP: TOTVS Protheus and SAP Business One historically use sequential per-branch (filial + year + seq). Modern installs often add a public hashed ID for portal access.
• Logistics: a single NF-e can reference multiple pedidos, so the validator must accept comma-separated lists.
• Marketplaces: each seller has its own pedido ID plus a marketplace-side ID — joining them is a frequent integration bug.

Anti-patterns and the Soundcloud lesson

The most common bug is exposing a sequential internal ID in the URL. In 2017 a Soundcloud bug let any user iterate /tracks/{id} and discover private uploads simply by guessing. The same class of bug hit Trello, Snapchat and several Brazilian e-commerces — the fix is always the same: keep an internal sequential PK in the database, publish an opaque ID (UUID, Snowflake or HMAC hash) to the outside world. The hash-based pattern is simple: public_id = base62(HMAC-SHA256(secret, internal_id))[:12]. The validator on this page checks structure only; you still need to enforce uniqueness server-side and rate-limit guessing attempts on the order-lookup endpoint.

Pegadinhas of order-ID formats

• Changing format breaks links: every confirmation email, NF-e and external integration carries the ID forever. Decide once, version the scheme (PED-V2-...) if you must change.
• Leading zeros: 00001234 serialized as JSON number becomes 1234 — always treat order IDs as strings end-to-end.
• Ambiguous chars: avoid 0/O, 1/I/l, 5/S when humans must read the ID over the phone — use Crockford base32 or remove vowels (also dodges accidental profanity).
• Multi-tenant collisions: never share an ID space across tenants without a tenant prefix — a cross-tenant data leak becomes one missing WHERE clause away.

FAQ

Should I use incremental or random IDs? A hybrid is the modern best practice: keep an internal sequential BIGINT PK for joins and indexing, and publish an opaque random ID (UUID v7 or HMAC hash) externally. You get the index efficiency of sequential and the security of random.

What length should a public order ID be? Typically 12-20 characters. Shorter than 10 invites collisions and enumeration; longer than 24 hurts UX in confirmation emails and customer-service calls. Stripe uses ~24-char prefixed IDs; most Brazilian e-commerces converge on 10-14.

How do I handle multi-tenant ID spaces? Prefix every ID with a short tenant code (ACME-PED-2026-...) or use a separate ID space per tenant. Validate the tenant prefix on every request — never trust the body alone, since IDs from another tenant could be replayed.

Does this validator check if the order exists? No — it validates structure only (length, prefix, charset, checksum). Existence requires a database lookup. The structural check is still useful as a fast pre-filter at the edge to reject obviously malformed IDs before they hit your ERP.