Receipt loyalty fraud: who can claim a purchase?

A genuine store receipt records a purchase. Receipt loyalty fraud can still occur because it usually does not say who made it. The member who uploads it could be the buyer, a family member, or a coworker. It could be someone who found it in the bin by the exit.

A receipt-based loyalty program gives rewards for scanned receipts. Receipt ownership checks need more than proof that the paper is real. May this account claim the purchase? Has another account claimed it already? These are separate decisions that need separate evidence.

Who may claim a receipt in a loyalty program?

Receipt hunters. A clothing retailer asked how to match a nameless receipt to a loyalty member. It was worried about people collecting discarded receipts near stores. The paper is real. The products were bought. A forgery check has no reason to fail it.

Shared baskets. A franchise food brand raised a related problem: three people taking photos of one product box. Several photos do not prove several purchases. If a campaign also needs a receipt, check that purchase across accounts before issuing rewards.

Staff and family. A cashier can keep a customer’s receipt. A relative can submit it through their own account. Some programs allow household claims. Others require the buyer to claim. Put that rule in the terms before asking a reviewer to enforce it.

The receipt fraud field guide covers the wider list of patterns. Here, the hard case is a real purchase. It is unclear whether the person who claims it has the right to do so.

How duplicate receipt checks match a purchase

Start with the fields printed on the paper. These include store, purchase date, time, receipt number, till or terminal ID, and total. Together, they can identify a purchase even if a second account uploads a fresh photo.

Steve’s fraud controls can match images that look alike, called perceptual image matching. They also support identity fingerprints across a workflow’s history. These are sets of fields you choose to identify a purchase. Receipt duplication detection uses your configured workflow and its history, not a global cross-client database. Agree which fields to use for your receipts. Do not assume every retailer prints the same ones.

One field is rarely enough. Receipt numbers can repeat between branches or tills. Totals repeat. In one Steve demo, two scans read the same receipt number in different ways. Matching the date and time still caught the duplicate. This shows how other fields can help when one differs. It is not a measured detection rate or a reason to use timestamps alone.

This invented comparison shows what a reviewer might need. It shows a matching decision. It is not the format of an API response:

{
  "current_customer_id": "synthetic-member-27",
  "prior_customer_id": "synthetic-member-11",
  "matched_fields": {
    "store_id": "synthetic-store-04",
    "purchase_date": "2026-10-12",
    "purchase_time": "18:42:09",
    "terminal_id": "03",
    "total": "42.80",
    "currency": "EUR"
  },
  "receipt_number": {
    "current_read": "804B1",
    "prior_read": "80481"
  },
  "proposed_action": "review_prior_claim"
}

Signal	What it catches	What can go wrong
Store + terminal ID	Tells purchases at different tills apart	Missing terminal ID or numbers reused elsewhere
Receipt number	Reprints and new photos of one purchase	Misread letters or digits, or numbers that repeat locally
Purchase timestamp	Helps match when another field differs	Rounded times or several purchases in one minute
Total + currency	Helps confirm the purchase is the same	Common basket totals repeat
Perceptual image match	Reused receipt images or ones that look alike	A fresh photo may look different

Duplicate invoice claims need the same choice of fields to identify a purchase. The fields and rules on who may claim differ.

First-claim rules and ownership disputes

“First eligible claim wins” is a workable policy. It means the first claim that meets the rules wins. It does not prove the first uploader bought the goods. Define what happens in each case:

• Same account, same submission: count a technical retry only once. Link a requested retake to the first claim. Do not treat it as a new purchase.
• Different account, same purchase: stop a second reward. Your policy may block delivery to the next system or flag the claim within the configured workflow. The loyalty system must enforce the reward rule. Show the prior claim with the flag.
• Partial match: send it to review. A matching total and date alone should not settle ownership.
• Unreadable identity fields: ask for a better photo. Poor evidence does not mean fraud.

The review queue should show the earlier claim, fields read from it, and decision context. For wording members see, read retake versus rejection. For repeat events caused by delivery, see API retries and loyalty rewards.

The second person to claim may be the real buyer. Publish a way to dispute the result. Decide what evidence can overturn the first claim. Receipt matching shows the conflict. It cannot decide who owns a piece of paper with no name on it.

Program design that reduces the value of hunting

Keep the claim window close to the purchase date. Older discarded receipts stop qualifying sooner. Give an ordinary member enough time to submit. Explain the deadline clearly.

Consider camera capture in your app. Your app can restrict uploads from the photo gallery. Steve does not impose that choice. Steve records image metadata when the capture channel provides it for review. Metadata is information attached to an image, such as a timestamp. A timestamp alone proves neither who took the photo nor who bought the goods.

Cap rewards per member per period. Enforce these limits in the loyalty platform, such as through Open Loyalty campaign limits. Pair them with purchase matching. A per-member cap alone leaves other accounts free to claim the same receipt.

Require a qualifying basket you can identify. The terms can set a minimum threshold for a basket to qualify. That does not prove ownership. If the fields needed to identify the purchase are missing, request a retake or review.

Sample approvals during the first weeks. Have a person check some accepted claims as well as flagged ones. Look for repeat purchases, confusing receipts, and rules that penalize members with valid claims.

Where the member identity comes from

The logged-in app session supplies the member’s identity. Your integration, or link between systems, passes the customer ID with the evidence. Steve links the submission to that account. A login does not prove the member bought the goods. Use the same identity across capture channels. This keeps purchase history from splitting between app and web claims.

A member who forgot their loyalty card may need to add a purchase later. Set an ownership policy for this too. Define the claim window and check prior claims. Decide what happens if another member already received points. The Open Loyalty receipt connection explains how approved purchases reach the loyalty platform. The receipt still cannot supply a buyer’s name it never printed.

Steve can read purchase fields, show prior matches, and send approved purchases to Open Loyalty. It cannot prove the uploader is the buyer or has the paper receipt. Set those expectations before launching receipt verification.

Checklist before launch

• Choose fields to spot duplicates from receipts your stores actually print.
• Give reviewers the prior claim and the fields behind each match.
• State who may claim, who wins a conflict, and how a buyer disputes it.
• Set per-member caps in the loyalty platform.
• Publish the claim window and retake instructions.
• Label a test set with duplicate receipts across accounts and similar valid purchases.
• Run a pilot with 10–20 real receipts to agree the fields. Include fresh photos of the same paper and unreadable examples.

Bring 20 real receipts, including the ones you suspect, to a discovery call. We can agree the fields that identify a purchase and the review policy before connecting rewards.

Decide who wins the receipt. Then automate it.