Where the IMEI sits in a buyback flow

Buyback is a pricing business with an identity problem. You are quoting money against a description someone else typed, and every gap between the described device and the actual device comes out of your margin. The IMEI is the cheapest way to close that gap.

The four points where it earns its keep

A lookup is not free, so it is worth being specific about where in the pipeline it pays for itself.

1. Quoting

A customer selecting their model from a dropdown will get it wrong at a meaningful rate — they pick the family rather than the variant, or the storage tier they wish they had bought. Resolving the IMEI instead turns a self-reported claim into a known model before you have committed to a price. The saving is not the occasional fraud; it is the steady drip of honest mistakes that would otherwise become repricing at the warehouse.

2. Intake

When the parcel arrives, the question is whether the device inside is the device that was quoted. Comparing the resolved model against the quoted model turns that into a machine check rather than a judgement call by whoever opened the box — which matters when the person opening the box is on their two-hundredth parcel of the day.

3. Grading and routing

Knowing the exact hardware determines what the device is worth refurbishing into and which market it can be sold to. Band support is the underrated field here: a handset whose radio profile does not match a target market is not a discount, it is unsellable stock.

4. The audit trail

Recording the IMEI of everything you handle, with a timestamp and a counterparty, is what lets you answer questions later. In several jurisdictions second-hand dealers are legally required to keep exactly this; where it is not required it is still the record that separates cooperating with an enquiry from being the subject of one.

Designing the check so it does not fight you

The most common implementation mistake is making the lookup a gate. It should be an input.

• Validate the checksum in the browser, before any request. A mistyped IMEI should be caught while the customer is still looking at the field, not by a server round trip — and it should never cost you a lookup.
• Treat "not found" as a normal answer. A phone launched three weeks ago may not be in any register yet. Falling back to manual model selection is correct; refusing the trade-in is not.
• Cache on the first eight digits. Everything the register knows is a property of the TAC, so a cache keyed on the full fifteen digits stores a million copies of the same answer.
• Re-resolve your unknowns on a schedule. Registers fill in. A device you could not identify last month is often identifiable now, and re-running the misses is far cheaper than the manual handling they otherwise cause.

What a lookup will not settle

Be clear internally about the boundary, or someone will eventually build a policy on top of a field that cannot support it. Resolving an IMEI tells you what the hardware is. It does not tell you the cosmetic condition, the battery health, whether the device is locked to an account, whether it has been reported stolen, or who owns it.

Those are separate checks against separate sources. The identity lookup makes them cheaper to run, because it tells you what you are running them against — but it does not replace any of them.