Refund limbo is a real problem
You returned the thing. The company said seven to ten business days. Now you're in refund limbo: the money is owed to you, nobody disputes that, and yet the only way to know when it arrives is to log into your bank portal and squint at the transaction list. Again. Every morning.
There's no good tooling for this. Banks won't let you set an alert for "a credit from this specific merchant." Budgeting apps are built around spending, not waiting. So people just check. For days.
An agent with live access to your transactions turns the whole thing into a one-line prompt plus a schedule. Here's how to set it up.
The two tools that do the work
BankBridge gives your agent 11 read-only tools, and this job needs exactly two of them.
search_transactions finds transactions matching a text query, a date range, and an amount range, across every connected account. Refunds show up as credits, so "find any Comcast credit in the last 14 days" is a single call.
get_merchant_history pulls everything from one merchant: every charge, every credit, going back months. That's how you build the paper trail (when the original charge hit, how much it was, whether a partial refund already landed) when a refund is late and you need to escalate.
And because BankBridge live-fetches on every call, each check runs against your bank's current data. There's no cache that might be a day behind.
Start with a one-off check
Before you automate anything, just ask. In Claude Code, Claude Desktop, ChatGPT, or whichever host you've connected BankBridge to:
Did my Comcast refund post yet? It should be a credit of about $89.99 to my checking account, sometime in the last two weeks.
The agent calls search_transactions with "Comcast" as the query, a credit filter, and your date window. If it's there, you're done. If it's not, you get a clear "no matching credit yet," which is more than a scan of the bank portal gives you.
One tip: name the amount if you know it. Merchants sometimes issue refunds under descriptors that don't match the original charge, and an amount match catches those. More on that in the gotchas section.
Write a watch prompt worth repeating
A watch prompt is just the one-off check, made specific enough to run cold. It should pin down five things: the merchant text, the expected amount (exact or approximate), which account, the date window, and what you want reported in each case.
Check whether a refund from Comcast has posted to my checking account (the one ending in 4872). Expect a credit between $85 and $95, any time after June 20. If you find it, tell me the date, amount, and descriptor. If you don't, say "not yet" and tell me how many days it's been since June 20.
That last line matters. "Not yet, day 9 of the 10 they promised" tells you something. A bare "no results" doesn't.
Save the prompt somewhere you can rerun it: a note, a saved prompt in your host, a slash command if your host supports them.
Schedule the re-check
Nobody wants to paste a prompt every morning either. The fix depends on your host.
Claude Code has scheduled agents, and a plain cron job running your watch prompt through claude -p works too. ChatGPT has scheduled tasks. Other hosts vary; worst case, a daily reminder that links to your saved prompt still beats the bank portal.
Daily is the right frequency for refunds. Banks post most credits in an overnight batch, so checking hourly buys you almost nothing. Set it and let the agent report in.
Have the report land somewhere you'll see it: a push notification, an email, a message. The whole point is that you stop looking until there's something to see.
When the refund still hasn't shown up
Day 11, nothing. This is where get_merchant_history earns its spot.
Show me every Comcast transaction across all my accounts for the last 90 days. Then draft a short note I can send their support with the original charge date, the amount, and how many business days it's been since they promised the refund.
Now you have the exact charge date, the amount, and a documented gap, without piecing anything together from statements. If you paid by credit card, that timeline is also the core of a dispute: most card networks give you at least 60 days from the statement date, and "merchant promised a refund and never sent it" is a standard dispute reason.
The agent can't file the dispute for you (BankBridge is read-only by design), but it can hand you everything the dispute form asks for.
It works for charges you're dreading, too
Watching for something you hope never appears is the same mechanics with the logic flipped.
I cancelled my Hulu subscription on the 3rd. Tell me if any new Hulu charge appears in the next 45 days. If one does, include the date and amount so I can dispute it.
Same idea for a free trial that's about to convert, an annual renewal you meant to cancel, or a merchant that double-charged you once before. The prompt becomes "alert me if X appears" instead of "alert me when X appears," and a quiet report is good news.
If you're watching a whole roster of subscriptions rather than one merchant, get_recurring_charges is the better starting point. The subscription audit guide covers that pattern.
Timing and descriptor gotchas
A few things that trip people up.
Refunds are slower than charges. A charge can show as pending within minutes; the matching refund often takes 5 to 10 business days, because the merchant batches it and the card network settles it before your bank posts it. Nothing on day 3 is normal, not a red flag.
Descriptors drift. The refund from "COMCAST CABLE COMM" might post as "CCB REFUND" or under a parent company's name. That's why the watch prompt includes an amount range: ask the agent to also flag any credit near the expected amount inside the window, whatever the name says.
And pending credits may not appear at all. Many banks only surface a refund once it's fully posted, so don't read much into its absence from pending. If the merchant refunded a card you've since replaced, the credit usually still reaches the account, but it can add a few days.