allanninal.dev/build

Part 3 of 7 · Warranty registration handler series ~9 min read

How a purchase gets verified

A registration is only trustworthy if the purchase behind it is real. This post is about the check that makes the whole system honest: matching the submitted serial and receipt against the business’s own order records, and turning away the three things that shouldn’t become a warranty — a serial that was never sold, one that’s already registered, and a purchase that’s outside the window.

Key takeaways

  • A registration is only trusted if the purchase behind it is real, so the serial and proof are matched against the business’s own order records.
  • Three things are turned away here: a serial that was never sold, a serial already registered, and a purchase outside the eligibility window.
  • The order records are mirrored into DynamoDB and keyed by serial, so verifying a registration is a direct lookup, not a slow scan.
  • The eligibility window is computed from the purchase date on the order record — the date the buyer types is never trusted on its own.
  • A near-miss — a receipt image but no clean order match — isn’t rejected outright; it’s handed to a person to confirm rather than guessed.

A warranty needs a real sale

By the time this step runs, Part 2 has given it a clean, singular job: a normalised serial, a proof of purchase, and the product line. What it hasn’t done is decide whether any of that is true. That’s this step’s whole purpose, and it’s the check that makes the difference between a warranty database worth having and one that’s quietly full of fiction. A registration form that believes whatever it’s told will happily record warranties on units that were stolen, counterfeited, bought grey-market, or simply invented by someone chancing a free repair — and every one of those looks identical to a genuine record until a claim arrives and nobody can trust it.

So the verifier does one deterministic thing: it matches the submission against the business’s own order records — the sales data mirrored into AWS — and only a submission that corresponds to a real sale is allowed to become a warranty. There’s no model here and no judgement call in the common case; a serial either was sold or it wasn’t. Everything in this post is about the three ways a submission can fail that test, and the one careful exception where a person is asked to look.

The three rejections

Consider Bramble & Moss, a mattress company offering a ten-year guarantee. Every mattress carries a serial sewn into the side seam, and every sale — through their own site or a handful of stockists — lands in the order records as a row: serial, purchase date, channel. When a registration comes in, the verifier looks the serial up in that mirror and asks three questions in turn.

Was it ever sold? If the serial matches no order at all, the registration is rejected. This is the counterfeit-and-typo gate: a made-up serial, a mistyped one, or a genuine-looking unit that never passed through the books gets no warranty. A plain typo is handled gently — the buyer is told the serial wasn’t found and asked to check it — but the system will not invent a sale to cover it. Is it already registered? If the serial matches an order but a warranty record already exists for it, the registration is rejected as a duplicate. Someone re-submitting their own registration is simply told it’s already done; someone trying to register a mattress that isn’t theirs is stopped cold. (The permanent enforcement of this lives in Part 4’s conditional write; the verifier checks it early so it can give a clear answer instead of failing at the last step.) Is it inside the window? If the sale is real and unregistered but the purchase date on the order record is outside the registration window — say, more than 90 days ago for a product that must be registered promptly — it’s rejected as out of window, with the reason made plain.

The crucial detail is that every one of these answers comes from the order record, not from the buyer. The buyer’s typed order number is used to find the sale; the purchase date, the channel, and the product all come from the sale itself. A buyer can’t backdate a purchase to slip inside the window, or claim a product they didn’t buy, because the facts that decide eligibility are the business’s own, not theirs.

Verifying a purchase: look up the serial in order records, then three checks — sold, not already registered, in window On the left, a box “Verify job from queue” lists the serial, the proof of purchase, and the product line. An arrow leads into a box “Verify Lambda” inside a dotted AWS account container. The verify Lambda reads a DynamoDB orders table, mirrored from the shop and keyed by serial, to find the matching sale. From the verify Lambda a vertical sequence of three decisions runs downward. First “Was it sold? (serial in orders)”; a serial found in no order exits right to a “Reject: never sold” box. Next “Already registered?”, checked against the DynamoDB warranties table; a serial with an existing record exits right to a “Reject: duplicate” box. Next “Inside the window? (purchase date + term)”, computed from the order’s purchase date; a purchase too old exits right to a “Reject: out of window” box. A serial that passes all three continues down to an arrow labelled enqueue store job, carrying the verified sale. A separate branch from the first decision, labelled “receipt but no clean match”, goes to a box “Escalate to a person”. A note reads: eligibility is decided from the order record, never from what the buyer typed — a real sale is the only thing that becomes a warranty. Verify job serial proof of purchase product line AWS account Verify Lambda match the sale DynamoDB orders PK serial, from shop look up Was it sold? serial in orders Reject: never sold no match Already registered? check warranties Reject: duplicate exists Inside the window? from purchase date Reject: out of window too old Enqueue store job pass all three Escalate person confirms receipt, no match Eligibility is decided from the order record, never from what the buyer typed.
Fig 3. Verifying a purchase. The verifier looks the serial up in the mirrored order records and asks three questions in order — was it sold, is it already registered, is it inside the window — rejecting each failure with a clear reason. A receipt with no clean match goes to a person; a full pass becomes a store job.

A direct lookup, not a scan

Verification has to be quick and cheap because it runs on every registration, so the order records aren’t queried live from the shop platform each time — they’re mirrored into a DynamoDB table keyed by serial. A scheduled sync (covered in Part 7) keeps that mirror current: new orders flow in, so a mattress sold this morning can be registered this afternoon. Because the table is keyed by the serial, verifying a registration is a single-item lookup rather than a scan across the whole sales history, which is what keeps this step to a fraction of a penny even for a brand with years of orders behind it. The order number the buyer typed is used as a secondary confirmation — it should match the order the serial belongs to — which catches an honest mix-up where the right serial is paired with the wrong receipt.

When to ask a person

Not every imperfect submission deserves a flat “no”. The common awkward case is a buyer who has a genuine receipt — a photo of a paper till slip from a stockist — but whose order isn’t in the mirror cleanly: a dealer who batches their sales weekly, a marketplace order that lists the item differently, a serial that’s a digit off from a real one. Rejecting these outright would punish real customers for the business’s own messy data. So a submission that looks genuine but can’t be matched automatically isn’t discarded — it’s handed to a person, with the serial, the receipt image, and the closest order records attached, for a quick human yes-or-no. If they confirm it, the registration proceeds exactly as if it had matched; if they don’t, it’s declined with a note. The automatic path stays strict, and the escape hatch keeps it fair.

Everything that clears all three checks — the overwhelming majority — becomes a store job on the SQS queue: the verified serial, the sale it matched (with the real purchase date and channel), and the product line whose warranty terms apply. Part 4 takes that and turns it into a durable record.

Design rules that shaped verification

  • Match against real sales. A warranty only exists behind an order in the business’s own records — nothing is taken on trust.
  • Three clear rejections. Never sold, already registered, and out of window each get a plain reason, not a silent failure.
  • The record decides, not the buyer. Purchase date, channel, and product come from the order, so eligibility can’t be gamed by what’s typed.
  • Look up, don’t scan. The orders mirror is keyed by serial, so verifying a registration is a single cheap lookup.
  • A genuine near-miss goes to a human. A real receipt with no clean match is confirmed by a person, not rejected on a technicality.
  • No model here. Verification is deterministic; a sale either exists or it doesn’t, and that’s not a question for a language model.
All posts