Sequential, Random, or Paired Codes for Custom Gift Cards?
Every card in a gift card program carries an identifier, and there is more than one way to structure those identifiers. Sequential numbers, randomized unique codes, encoded magnetic stripes, scannable barcodes and QR codes each behave differently in how they are generated, how they are tracked at redemption. The right choice depends on the platform you run and your operations.
Serialization Is Not Encoding Or Variable Data Printing
Serialization is the structure and management of the identifiers themselves: what number each card carries, how those numbers are generated, whether they are unique, and how they are tracked from production through redemption.
Encoding is a separate question. Encoding is how that identifier is physically written to the card on a magnetic stripe, barcode, or QR code. The sequence of numbers that are encoded is serialization. The two decisions interact, but they are not the same decision, and you can get one right while getting the other wrong.
If you have not settled the encoding question yet, start with which gift card encoding format your business needs and come back here.
Everything below is about the numbers.
Sequential Numbering
Sequential numbering issues identifiers in order. Card 1001, card 1002, card 1003, through the end of the run.
Where Sequential Fits
Sequential runs are simple to reconcile. You know exactly how many cards exist, you know the range, and a missing card is visible as a gap. For a small program with cards held behind the counter and issued by staff, that inventory clarity has real operational value. It also makes internal control straightforward: you can assign block 1001 to 1500 to one location and 1501 to 2000 to another and account for every card.
The Guessability Tradeoff
Predictable sequences are predictable to everyone. If a customer holds card 1042, the existence of cards 1041 and 1043 is not a secret. Platform vendors say this directly. Lightspeed’s documentation notes that sequential numbers such as 10001 and 10002 are easy to guess and can lead to fraudulent transactions, and recommends randomized numbers instead. Square’s developer documentation is blunter, instructing developers not to use gift card account numbers that are easy to guess because doing so greatly increases the risk of fraud.
This does not make sequential numbering wrong. It makes it a choice with a known exposure, and the exposure scales with how many cards are in circulation and how easy it is to test a guessed number against a balance-check tool.
Randomized Unique Codes
Randomized serialization generates identifiers with no predictable relationship between one card and the next. Card 1042 tells you nothing about any other card in the run.
What Non-Sequential Generation Buys You
Two things. The first is that guessing a valid identifier stops being arithmetic and becomes a search across the full range of possible codes, which is why platforms specify both randomization and a minimum length. Lightspeed’s X-Series requires codes of at least 8 characters and recommends they be alphanumeric and non-sequential. Square accepts custom numbers of 8 to 20 alphanumeric characters. Shopify requires third-party physical cards to carry a unique code of 8 to 20 alphanumeric characters.
The second is duplicate prevention. A randomized generation process that checks each new code against every code already issued cannot produce two cards with the same identifier. Duplicates are not only a fraud problem, they are a data problem: Toast’s gift card import fails outright if the file contains duplicate card numbers or numbers that were previously uploaded.
The Data Side of a Randomized Run
Randomized serialization means every card in the run is physically different from every other card. That is a production capability, not a design choice. The number file has to be generated or received, validated for uniqueness and format, and merged into the print run so that card 4312 gets its own code and only its own code. This is variable data printing, and it is the mechanism that turns a list of identifiers into a box of correctly numbered cards.
Confirm who owns that file before production. Some platforms generate the numbers and hand you a file. Some expect you to generate them and hand a file back. Toast, for example, asks for a full list of every card manufactured, in CSV or XLS format.
Pairing a Printed Number With a Scannable Code
Many programs carry the same identifier twice: printed in human-readable characters and encoded in a scannable symbol. The two resolve to the same number.
The reason is redemption workflow, not redundancy for its own sake. The scannable version is what gets used at a working register, because it is fast and it removes typing errors. The printed version is what gets used when the scanner fails, when a phone order comes in, when a customer calls to check a balance, or when the card is damaged. Toast recommends third-party card numbers stay at 21 digits or fewer specifically because longer numbers cannot be keyed in manually and can only be swiped. That is a serialization constraint driven entirely by the manual fallback.
Keep the printed and scanned identifiers identical. If they diverge, you have two systems of record on one piece of plastic.
Adding a Concealed Second Value
Some programs pair the visible identifier with a second value that stays hidden until the customer reveals it. Clover’s physical gift cards work this way, carrying a 4 to 8 digit security card value alongside the card number.
The logic is specific to how cards are distributed. A card sitting on an open retail rack has its printed identifier visible to anyone who walks past. If redemption requires only that identifier, some gift card scams can be drain the card of its value shortly after it is purchased. A concealed value under a scratch-off panel means the visible number alone is not enough, and a scratched panel on a rack card is an obvious signal that something is wrong.
Serialization Approaches Compared
| Approach | How identifiers are generated | Typical program fit | Fraud exposure | Redemption and tracking |
|---|---|---|---|---|
| Sequential numbering | Issued in order across the run, usually from a starting number and a count | Smaller programs, staff-issued cards, single location or a few locations with assigned blocks | Higher. The next and previous identifiers are inferable from any card in circulation | Simplest to reconcile. Gaps in the sequence are visible immediately |
| Randomized unique codes | Generated with no relationship between cards, checked for uniqueness, merged at print via variable data printing | Programs of scale, open retail distribution, anything a platform requires non-sequential codes for | Lower. Guessing requires searching the code space rather than counting | Requires the number file as the system of record. Reconciliation is by file, not by range |
| Paired human-readable plus scannable | Either method above, with the same identifier rendered twice on the card, sometimes plus a concealed second value | Most programs with a POS at the counter, and any program where manual entry is a real fallback | Depends on the underlying method. A concealed second value reduces exposure for rack-distributed cards | Fastest at the register, with a working fallback. Both renderings must carry the identical identifier |
Matching the Method to Your Platform and Program Size
Your Platform May Have Already Decided
Some platforms constrain the identifier structure directly, and the constraint is not always where you would look for it. Character count minimums, alphanumeric versus numeric, reserved prefixes, and maximum length all appear in platform documentation. Toast asks that third-party card numbers not begin with 862, because Toast-assigned card numbers always begin with that prefix. Square requires a custom number that is unique for the seller and does not start with the same bank identification number as a major credit card.
The specifics above were confirmed against each platform’s published documentation in August 2026. Requirements change, so treat this as the shape of the conversation to have with your provider rather than a substitute for having it.
How Program Size Changes the Math
A hundred cards issued from behind a counter and fifty thousand cards on retail racks are different risk situations, not different sizes of the same one. Exposure rises with the number of cards in circulation, the number of people who can see an identifier without buying the card, and the availability of a balance-check tool that will confirm a guess. Sequential numbering that is fine at the first scale is a liability at the third.
Fraud and Redemption Management
Serialization sets the exposure. Program management determines whether the exposure turns into a loss.
The mechanisms worth understanding are straightforward. Guessing works when identifiers are predictable and there is somewhere to test a guess, which is why a public balance-check page and a sequential run are a poor combination. Draining works when a card’s identifier is visible before purchase and no second factor is required, which is what the concealed value addresses. Duplicate identifiers create ambiguity about which card holds which balance, which is why platform imports reject them.
Three practices sit alongside the serialization choice and matter as much as it does. Ship cards inactive and activate at the point of sale, so a stolen box of cards is a box of plastic. Keep the manufacturing file as the authoritative record of what exists, so an identifier presented at redemption can be checked against what was actually produced. And watch redemption patterns rather than only balances, because repeated failed lookups against near-miss identifiers is a signal that shows up before a loss does.
None of this requires a fortress. It requires knowing which of these applies to how your cards will actually be distributed.
The Serialization Checklist
Take this to your platform provider first, then to any card manufacturer.
- What identifier structure does the platform expect? Character count minimum and maximum, numeric or alphanumeric, and any character set restrictions.
- Must codes be unique and non-sequential, or is sequential acceptable? Some platforms require non-sequential. Some only recommend it. Ask which.
- Are any prefixes or ranges reserved? Reserved prefixes are a common and easily avoided failure.
- Who generates the numbers? You, the platform, or the manufacturer. If the platform generates them, ask for the file. If you generate them, ask what format the platform will accept back.
- Will the platform reject duplicates or previously loaded numbers? Most will. Confirm how the file must be de-duplicated before it is submitted.
- Do cards ship activated or inactive? Confirm it rather than discovering it on launch day.
- Will the same identifier be printed and encoded? If so, confirm both come from the same source file.
- Can a test file be validated before the full run? This is the item that saves the money.
Serialization Is Set at Production Time
A card’s identifier is fixed the moment it is printed. Changing it later means a new run, which is why serialization is worth settling before artwork is approved rather than after.
Plastek manufactures custom gift cards and, when appropriate, can handle the data side of serialized runs, including variable data printing for randomized unique codes and validation of a test file against your platform’s specification before the full production run goes ahead. If the test file loads cleanly into your platform, the run is safe to print. If it does not, you have found the problem while it is still a spreadsheet.
To work through your platform’s serialization requirements with a custom card manufacturer, request a quote on custom gift card printing or call the Plastek gift card production team at 1-888-762-2737.
Frequently Asked Questions
What is gift card serialization?
Serialization is the structure and management of the identifiers printed on each card in a program: what number each card carries, how those numbers are generated, whether they are unique, and how they are tracked from production through redemption. It is distinct from encoding, which is how that identifier is physically written to the card.
Should gift card numbers be sequential or random?
It depends on the platform and the program. Several platforms require or recommend non-sequential codes, because sequential numbers can be inferred from any card in circulation. Lightspeed recommends unique, non-sequential alphanumeric codes of at least 8 characters. Sequential numbering remains workable for small, staff-issued programs where inventory accountability matters more than guessability.
Who generates gift card numbers, the platform or the printer?
Either, depending on the platform. Some platforms generate the numbers and provide a file for production. Others expect the numbers to be supplied and a manufacturing list returned. Toast, for example, asks for a full list of every card made in CSV or XLS format. Confirm ownership of the number file before production begins.
How long should a gift card number be?
Your platform sets the range. Shopify requires third-party physical cards to carry a unique code of 8 to 20 alphanumeric characters. Lightspeed’s X-Series requires at least 8 characters. Toast recommends 21 digits or fewer, because longer numbers cannot be keyed in manually. Get the minimum and maximum in writing before artwork is finalized.
Do gift cards ship activated or inactive?
Most closed-loop programs ship cards inactive and activate them at the point of sale, so cards have no value until sold. Confirm this with your platform rather than assuming it, because it changes how a stolen or lost box of cards should be handled.
Can serialization be changed after cards are printed?
No. The identifier is fixed at production. Changing it requires a new run, which is why validating a test file against your platform before full production is the single most useful step in the process.