βΊ About BunqPal
π‘ Inspiration
The idea started with a small, painful moment: one of us realized β three days too late β that a refund window had quietly closed on an
order they'd meant to return. That same week, another teammate noticed they'd been auto-charged for a streaming subscription they thought
they'd cancelled. And the third was out of dog food again, two weeks earlier than expected.
We started talking about how strange it is that, in 2026, banks can see exactly where your money went, and browsers can see exactly what you're about to buy β but nothing connects the two. Nobody is paying attention to the intent behind a payment, or the consequence that arrives thirty days later. Refills get forgotten. Renewals slip through. Refund windows expire at midnight while you're asleep.
We wanted to build the layer that lives in that gap β something that sees a payment not as a single transaction, but as a lifecycle.
π± What it does
BunqPal is a Multi Model Ambient AI checkout layer that understands payment intent before money moves, fixes friction during checkout, and remembers what each payment will become β a refill, a renewal, a refund window, or a future mistake to prevent.
It runs as a Chrome extension paired with a Python backend and the bunq sandbox API. Three real demos drive it:
- Smart checkout β at the moment you hover "Pay now," BunqPal whispers: "Use your Pet Essentials sub-account β top up β¬4 to cover this." One tap and the right money moves to the right place before you pay.
- Future memory β thirty days after a dog-food order, BunqPal already knows you're running out. It nudges you, you approve, and the
extension drives the re-purchase autonomously, click by click. - Refund radar β two days before a refund window closes, BunqPal opens the form, prefills the reason, and hands it to you ready to send.
Critically, BunqPal only ever proposes. Money moves and purchases execute only after an explicit user approval β and the extension never reads card, CVC, PIN, or IBAN inputs.
π How we built it
The team (three people, every hour counted):
- Shengan β Lead Developer. Owned the entire engineering spine: the Flask backend, the Claude-powered agent loop (checkout_analyst and
post_purchase_analyst), the bunq sandbox integration with full RSA-SHA256 request signing, the APScheduler tick that turns due
future_actions into live notifications, the policy gate, and the audit log. - Xinyue β UI/UX Design. Owned every pixel β from the floating shadow-DOM bubble that appears next to the "Pay now" button, to the
notification cards for refills, renewals, and refunds, to the brand identity (the mint-green #7bffb0 accent that became BunqPal's signature). Designed the entire visual language of an "ambient" product that needed to feel present without ever feeling intrusive. - Zhonghao β Demo & Product Storytelling. Owned the AH mock site adapter, the end-to-end demo flows, the product narrative, and the final
showcase video. Made sure that on demo day, every click of every flow worked deterministically, and that the story landed.
The stack:
- Frontend: Chrome MV3 extension β TypeScript content script, React floating bubble mounted into a shadow-DOM host (so the host page's
CSS can never leak in), page-intent detection by URL + visible-text heuristics, mouse tracker for cursor proximity, site adapters for the AH mock with deterministic data-bunqpal-action selectors. - Backend: Python + Flask. A Claude-driven tool-use loop with structured outputs for single-shot analysis and multi-turn execution.
APScheduler ticks every 5 seconds and converts due future actions into pending notifications, which the extension polls via
chrome.alarms. - Banking: Full bunq sandbox integration β three-step handshake (installation β device-server β session-server), RSA-2048 keypair, signed
requests, internal sub-account transfers, sandbox top-ups, and webhook handling.
- Data: Supabase for orders, future_actions, notifications, and audit_logs.
- Safety: A policy gate restricts automated purchase execution to allowlisted hosts with hard caps. Every mutating action is appended to
an immutable audit log.
π§ Challenges we ran into
- Building an "ambient" UI is harder than building a loud one. Xinyue iterated through six versions of the bubble before it felt right β
present enough to notice, quiet enough to ignore. The shadow DOM helped isolate styling, but getting the bubble to appear at the right
moment near the cursor without ever feeling like a popup took real design judgment. - The bunq sandbox handshake is unforgiving. The three-step installation β device-server β session-server flow with RSA-SHA256 body
signing is one wrong byte away from a 401. Shengan spent a long evening narrowing it down β every request has to be signed exactly the
way bunq expects, including header ordering. - Making an autonomous purchase agent feel safe. It's one thing to have an agent that can click "Pay now" β it's another to make a user
actually trust it. We landed on a strict pattern: the agent only ever proposes; nothing executes without an explicit user_approved=true
from the extension; automated purchases are restricted to allowlisted hosts; and every action lands in an audit log. The safety boundary became a feature, not a constraint. - Demo determinism on a hackathon timeline. Real checkout pages are unpredictable. Zhonghao added data-bunqpal-action hooks to the AH
mock so the extension can drive it deterministically, with text-based fuzzy matching as a fallback β which meant we could rehearse the
demo end-to-end without worrying about a stray DOM change breaking the flow. - Keeping the visual language consistent across browser, banking app, and product video. With #7bffb0 as the only accent color and a deep
#06231a as the dark companion, Xinyue locked a palette that worked equally well in a Chrome extension, a notification card, and a
cinematic showcase video.
π Accomplishments we're proud of
- A complete, working end-to-end loop: hover β propose β approve β top-up β pay β analyze β schedule β notify β autonomous re-purchase.
All three demo flows run. - A safety model we'd be comfortable putting in front of a real user: agent proposes, user approves, audit log records β and the
extension never sees sensitive payment fields. - A visual identity that already feels like a real product, not a hackathon prototype.
- Three people, three lanes, zero overlap β and somehow it all came together.
π What we learned
- Payment isn't a moment, it's a lifecycle. Once you start treating a transaction as the middle of a story (not the end), a whole class
of product opportunities opens up. - The hard part of an AI agent isn't the AI β it's the boundary. Defining what the agent can and cannot do, where human approval is
required, and what gets audited, is what turns a demo into something a person could actually trust. - Ambient UX is a design discipline, not a feature. Knowing when not to appear is harder than knowing when to appear.
- A great hackathon team is three people who each completely own a layer. Shengan owned the engine, Xinyue owned the surface, Zhonghao
owned the story. Nobody was waiting on anyone.
π What's next
- More merchants beyond the AH mock β generalizing the site adapter pattern.
- A mobile companion that mirrors the browser experience.
- Smarter post-purchase analysis β learning your refill cadence over time instead of using fixed +30d windows.
- Real bunq production integration once we move past sandbox.
Built with β€οΈ by Shengan, Xinyue, and Zhonghao.
Log in or sign up for Devpost to join the conversation.