What is a warranty registration handler?

It is a small serverless system that turns product registration from a paper card nobody posts into a scan-and-done job. The buyer scans the QR sticker on the product (or fills a short web form) with the serial number and proof of purchase; the system checks that serial and receipt against the business’s own order records, works out how long the warranty runs and when it expires, saves the record, and texts or emails back a confirmation that says what’s covered in plain words. Reminders for servicing and for the approaching expiry are scheduled automatically, and if the customer ever makes a claim it lands with a real person, the full record already attached.

How much does it cost to run?

About $1.80/month at a typical small-brand volume of roughly 200 registrations a month. There is no always-on compute, so the bill is almost entirely usage-priced — a small Bedrock call per confirmation and the outbound reminder messages are the main moving lines, and the only real fixed cost is Secrets Manager for the form and order-lookup keys. At ten times the volume (around 2,000 registrations a month) the bill lands near $9, because the fixed lines don’t move.

Which AWS services does it use?

Lambda (Python 3.14, arm64) behind a single Function URL for the registration form and QR post, DynamoDB on-demand for the serial ledger, warranty records, and order mirror, EventBridge Scheduler for the maintenance and pre-expiry reminder sweeps, SES for email and SNS for SMS, SQS with a dead-letter queue, Secrets Manager for the form and order-API keys, CloudWatch Logs with 7-day retention, AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) to write the confirmation and explain the coverage. No API Gateway, no NAT Gateway, no always-on compute. One region, eu-west-2.

How fast does it register a product?

Within seconds of the form being submitted. The buyer scans the QR or opens the short form, enters the serial and a proof of purchase, and taps send; the system verifies the serial against the order records, checks it hasn’t been registered before and that the purchase is inside the eligibility window, computes the expiry, stores the record, and fires back a confirmation with one Bedrock call. Reminders are then scheduled far in advance — a service nudge a few months in, a heads-up before the cover lapses — and released on their due dates, so the customer hears back at the right moment rather than all at once.

Only to write the wording. Bedrock’s Claude Haiku 4.5 fires once per confirmation to turn the stored coverage terms into a warm, plain-language message — “your frame is covered for five years, the motor and battery for two” — and it is handed only the facts it may use, with instructions to use nothing else. The verification against order records, the duplicate and out-of-window checks, the term and expiry maths, and the reminder scheduling are all deterministic Python. The model never decides whether a registration is valid, how long the cover runs, or when a reminder goes out.

Can the same product be registered twice?

No. Every registration is claimed by a conditional write on the serial number in DynamoDB — the first valid submission for a serial wins and creates the record; any later attempt on the same serial is rejected as already registered, whether it’s an honest re-submit or someone trying to register a unit they didn’t buy. The same gate rejects a serial that doesn’t match any order and a purchase that falls outside the registration window. One serial, one warranty, and every record is kept queryable so a later claim can be tied straight back to it.

Series · 7 parts Published July 6, 2026

Warranty registration handler

A new product goes home in a box and the warranty card goes straight in the bin — so when something fails a year later, nobody can prove what they bought or when. This is the design of a small serverless system that turns registration into a thirty-second job: the buyer scans the QR on the product or fills a short form with the serial and proof of purchase, and the system verifies that purchase against the business’s own order records, computes the warranty term and expiry, stores the record, and sends back a confirmation that explains the coverage in plain language. It schedules the maintenance and pre-expiry reminders so the customer hears from the business again at exactly the right moment, and routes any later claim to a person with the whole record attached. It registers a serial exactly once, rejects duplicates and out-of-window purchases, and keeps every record queryable. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

01

A warranty registration handler on AWS for a few dollars a month

The whole system on one page — the QR-or-form submission, verification against order records, the term-and-expiry maths, the stored record, and the scheduled reminders, plus the guardrail that a serial registers exactly once and duplicates and out-of-window purchases are turned away.
02

How a registration gets submitted

How a registration gets submitted — the QR sticker or short web form, the single Lambda Function URL that receives the post, the anti-abuse checks, and how a raw submission becomes a clean, claimed job carrying the serial and proof of purchase.
03

How a purchase gets verified

How a purchase gets verified — matching the serial and proof of purchase against the business’s order records, rejecting serials that were never sold, duplicates already registered, and purchases outside the eligibility window, before a warranty is ever created.
04

How a warranty record gets stored

How a warranty record gets stored — computing the term and the exact expiry date from the product and purchase, claiming the serial with a conditional write so it registers exactly once, and writing a queryable record with the expiry indexed for the reminder sweep.
05

How expiry reminders get scheduled

How expiry reminders get scheduled — the EventBridge Scheduler sweep that reads the indexed expiry dates, sends maintenance nudges partway through the term and a heads-up before the cover lapses, each exactly once and honouring opt-out.
06

What the warranty registration handler costs

A line-by-line monthly cost at about $1.80 for roughly 200 registrations, where the money actually goes (a small Bedrock call and the reminder messages), and what the bill looks like at ten times the volume.
07

Engineering reference: the warranty registration handler architecture

The same system drawn for engineers — the Lambda inventory, the registration Function URL, the serial ledger and warranty tables with the expiry GSI, the reminder scheduler, SES and SNS, the Bedrock model id, IAM scope, and the region.

What is a warranty registration handler?: It is a small serverless system that turns product registration from a paper card nobody posts into a scan-and-done job. The buyer scans the QR sticker on the product (or fills a short web form) with the serial number and proof of purchase; the system checks that serial and receipt against the business’s own order records, works out how long the warranty runs and when it expires, saves the record, and texts or emails back a confirmation that says what’s covered in plain words. Reminders for servicing and for the approaching expiry are scheduled automatically, and if the customer ever makes a claim it lands with a real person, the full record already attached.
How much does it cost to run?: About $1.80/month at a typical small-brand volume of roughly 200 registrations a month. There is no always-on compute, so the bill is almost entirely usage-priced — a small Bedrock call per confirmation and the outbound reminder messages are the main moving lines, and the only real fixed cost is Secrets Manager for the form and order-lookup keys. At ten times the volume (around 2,000 registrations a month) the bill lands near $9, because the fixed lines don’t move.
Which AWS services does it use?: Lambda (Python 3.14, arm64) behind a single Function URL for the registration form and QR post, DynamoDB on-demand for the serial ledger, warranty records, and order mirror, EventBridge Scheduler for the maintenance and pre-expiry reminder sweeps, SES for email and SNS for SMS, SQS with a dead-letter queue, Secrets Manager for the form and order-API keys, CloudWatch Logs with 7-day retention, AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) to write the confirmation and explain the coverage. No API Gateway, no NAT Gateway, no always-on compute. One region, eu-west-2.
How fast does it register a product?: Within seconds of the form being submitted. The buyer scans the QR or opens the short form, enters the serial and a proof of purchase, and taps send; the system verifies the serial against the order records, checks it hasn’t been registered before and that the purchase is inside the eligibility window, computes the expiry, stores the record, and fires back a confirmation with one Bedrock call. Reminders are then scheduled far in advance — a service nudge a few months in, a heads-up before the cover lapses — and released on their due dates, so the customer hears back at the right moment rather than all at once.
Does it use AI?: Only to write the wording. Bedrock’s Claude Haiku 4.5 fires once per confirmation to turn the stored coverage terms into a warm, plain-language message — “your frame is covered for five years, the motor and battery for two” — and it is handed only the facts it may use, with instructions to use nothing else. The verification against order records, the duplicate and out-of-window checks, the term and expiry maths, and the reminder scheduling are all deterministic Python. The model never decides whether a registration is valid, how long the cover runs, or when a reminder goes out.
Can the same product be registered twice?: No. Every registration is claimed by a conditional write on the serial number in DynamoDB — the first valid submission for a serial wins and creates the record; any later attempt on the same serial is rejected as already registered, whether it’s an honest re-submit or someone trying to register a unit they didn’t buy. The same gate rejects a serial that doesn’t match any order and a purchase that falls outside the registration window. One serial, one warranty, and every record is kept queryable so a later claim can be tied straight back to it.

All posts

Frequently asked questions

Other series