Understand the merchant
Identify the business and keep merchant identity separate from likely reward coding.
Back to Work
Venture · Fintech · Decision intelligence
Klariq Know which card to use before you pay.
Compare estimated rewards for a specific merchant, with uncertainty visible. A working prototype using a simulated wallet.
Open live Klariq prototypeInteractive prototype · Simulated wallet · No issuer connection
AudienceB2C
RoleProduct designer · UX engineer
ProductCard recommendation prototype
PlatformMobile web
Model20 cards · 6 banks
Merchant uncertainty
Unknown merchant? Ask only what matters.
Hotel Restaurant separates business identity from reward coding. Velora shows the recovery path when a name alone is not enough.
- It uses the same merchant classifier as normal search instead of a separate shortcut.
- Low confidence stays visible instead of being promoted to certainty.
- Purchase context is requested only when it can change the recommended card.
Financial reasoning
Compare value, not raw reward numbers.
The demo catalog models 20 cards across six banks with explicit reward rules.
- Explicit rules combine base rate with category, context, cap, activation, and dynamic category logic.
- Point Valuation converts reward currencies into estimated dollar value without changing the raw earning rate.
- Recommendation Style changes how floor, expected, and upside are weighted: Prefer certainty 60 / 40, Balanced 80 / 20, Maximize upside 70 / 30.
Track and learn
Track the purchase. Keep later verification separate.
Track Purchase saves the recommendation, confirms it, and returns the user to Home. The new row is a non-interactive Pending status, not a verification trigger. If verification becomes available later, it appears as a separate contextual step.
- The purchase-time card set stays attached to the original decision.
- Valuation and purchase context remain as they were when the recommendation was made.
- Later verification can add evidence without rewriting the original comparison.
Behind the product: the recommendation model
Overview
A recommendation system that starts with the merchant.
Most card tools begin with a category and a list of multipliers. Klariq begins one step earlier: what is this merchant, how might the purchase be rewarded, and does the user need to clarify anything before the ranking can be trusted? That separation keeps the interface useful when the merchant is obvious, while still giving uncertain cases a clear recovery path instead of hiding them behind a confident score.
Problem
The decision gets harder before the percentages.
The same card can perform differently by merchant, purchase context, cap status, activation, and reward currency. I designed the experience to expose only the uncertainty that can change the choice, then keep the result readable. The product therefore treats clarification as a decision tool, not as a default form step, and keeps raw reward rates distinct from the dollar value used to compare cards.
Decision system
Four steps from merchant to recommendation.
Klariq asks for extra context only when it could change the winner.
Evaluate card rules
Run cards in the simulated wallet against base rates, category rules, purchase context, caps, and activation.
Normalize and rank
Convert cash back, points, and miles into estimated value, then weigh floor, expected, and upside.
Explain the choice
Show the strongest card first, then Why this card, alternatives, Evidence, and Track Purchase.
What changed
The prototype got better when the shortcuts started breaking.
Implementation and QA exposed where the early model looked convincing but failed under real edge cases.
Reward logic became explicit
Generic multipliers became baseRate plus rules, with category, context, caps, activation, and dynamic behavior modeled separately.
Questions became decision sensitive
Clarification appears only when the answer can change the recommendation, and opaque descriptions use the same classifier as normal search.
History stopped depending on current state
Purchase time snapshots preserve wallet, valuation, context, and per card outcomes so later changes do not rewrite the decision.
The implementation was hardened
Reset, input escaping, keyboard focus, accessibility, responsive behavior, and safe area handling were tightened across the prototype.
Prototype only. No backend, issuer feed or AI model.
Next project
Aurelia
Hospitality tasks brought into one conversation.
