Missing-Cashback Detector

An integration spec that cross-checks your cashback-portal activity against your actual bank transactions, so a purchase that should have earned cashback but never got credited gets flagged while you can still file a claim.

Date: 2026-08-04 Type: Integration Theme: Discounts + Rewards Status: Idea

What it is

A design for a background reconciliation service that sits between a cashback shopping portal (the Rakuten/TopCashback style of site — click through, then buy, then wait for the cashback to post) and Plaid's transaction feed for your bank or card account. It pulls both sides on a schedule, matches purchases to portal payouts by merchant, amount, and date, and drafts a claim the moment a purchase looks like it should have tracked but didn't.

Who it serves

Someone who already shops through a cashback portal — for the sign-up bonus, the extra percentage on top of a card's own rewards, or just habit — but doesn't have the patience to manually cross-check every purchase against their portal dashboard. This is the person who has, at some point, found a stray $4 cashback claim from four months ago that they never filed because the claim window had already closed.

The money problem it addresses

Cashback portals track purchases with a browser pixel or redirect link, and that link doesn't always fire: an ad blocker, a coupon extension that jumps in first, starting the shopping trip on the retailer's site instead of the portal's, or the retailer's own tracking glitching out. When it fails, the portal has no record of your purchase at all, and most portals only credit a missing-cashback claim if you file it within a few days of the purchase and can show the order confirmation. Nobody manually re-checks their bank statement against their portal history every few days, so most missed cashback just expires unclaimed. This integration automates the cross-check.

How it works

1. A Plaid SYNC_UPDATES_AVAILABLE webhook fires when a new transaction posts to the linked account, and the service pulls it via /transactions/sync.
2. For each new transaction at a merchant the user has clicked through the portal in the last 45 days, the service pulls the portal's clicks and conversions feeds and looks for a match by merchant, amount (within $0.50), and date (within 3 days).
3. A match with status: confirmed needs nothing further. A match still pending inside the portal's typical crediting window (10 business days, per the portal help pages cited below) also waits.
4. No match at all after 3 days — the minimum window portals ask you to wait before filing — gets flagged missing, and the service drafts a claim record: merchant, order date, order amount, and the click ID if one exists.
5. The draft claim isn't submitted automatically. Portals expect the claim to come from the logged-in shopper, and treat scripted submission as a terms-of-service violation, so the service hands the shopper a filled-out draft to paste into the portal's own form.

What's in this folder

• README.md — this file
• cover-image.png — cover card image for the web app
• metadata.md — workflow metadata sidecar
• integration-spec.md — the full contract: systems, auth model, endpoint and payload shapes for both the portal feed and Plaid, the matching logic, error model, sequencing guarantees, and operational limits
• sequence.md — the happy path (a purchase that never gets a conversion record) plus two failure cases: a Plaid pagination interruption and a portal rate limit
• sample-request.json — an example /transactions/sync request against Plaid
• sample-response.json — the matching response, including the transaction that later gets flagged missing

How to run / read it

Read integration-spec.md first for the full contract, then sequence.md for the call-by-call walkthrough, then sample-request.json and sample-response.json together to see the exact payload shape.

Estimated impact

Worked from the sample data in this folder: an $87.42 purchase at a merchant with a 3.5% cashback rate is $3.06 uncredited if the click never tracked. Catch two or three missed claims like that a year and it's somewhere in the $6–$15 range — not life-changing on its own, but it's found money that otherwise expires unclaimed, and the habit compounds if someone runs several cashback portals across a lot of online shopping. The bigger win is timing: most portals only honor a claim filed within days of the purchase, so the value here is being told before that window closes, not after.

Good to know

This is a reconciliation and drafting tool, not a way to auto-submit claims — portals expect a human to file the claim, and the draft this service produces still needs to be pasted into the portal's own form. It's also not a guarantee: some purchases are excluded from cashback by the retailer regardless of tracking (gift cards, certain categories), and no amount of transaction-matching recovers cashback on those. Crediting windows and claim deadlines vary by portal and change over time — check the current terms on whichever portal you actually use before relying on the timelines described here.

Sources

• https://plaid.com/docs/api/products/transactions/ — /transactions/sync request/response shape, pagination, and error codes
• https://plaid.com/docs/transactions/webhooks/ — SYNC_UPDATES_AVAILABLE webhook behavior and Plaid's default sync frequency
• https://plaid.com/docs/api/webhooks/ — webhook retry/backoff policy and delivery guarantees
• https://www.nopointleftbehind.net/shopping-portals/request-rakuten-missing-cash-back — how a missing-cashback claim is filed and what's required
• https://blog.brandumentals.com/rakuten-missing-cash-back/ — typical waiting windows before filing and typical resolution time for a claim
• https://www.shopback.com/guide/basics/how-cashback-tracking-works — common reasons a cashback click fails to track (ad blockers, coupon extensions, starting on the retailer's site)