PayCheckpoint

Inspiration

Mobile financial services make sending money fast and convenient, but a small mistake can have serious consequences. A single incorrect digit, a misleading payment request, or missing transaction evidence can turn an ordinary payment into a stressful situation.

I wanted to explore a simple question: What if people had a separate checkpoint to compare what they intend to pay with what they are about to enter, before confirming a transfer?

A wallet's confirmation screen shows the details entered into that wallet. PayCheckpoint adds something different: an independent record of the user's original intent. I also wanted the experience to continue beyond prevention, helping people review suspicious requests and organise evidence when something goes wrong.

The goal was not to build another wallet or claim to detect every scam. It was to give individuals a clearer, more structured way to make payment decisions.

What it does

PayCheckpoint is a bilingual (English and Bangla) B2C payment-safety companion designed for individual mobile financial services users in Bangladesh.

It supports three everyday situations:

1. Before sending money — Check before you pay

Users record the recipient and amount they intend to send, then compare those values with the details they are preparing to enter in their wallet. PayCheckpoint highlights mismatches, including differences in individual digits, so users can pause and recheck before proceeding.

2. Before responding — Review suspicious messages

Users can review a suspicious payment-related message or examine a labelled conversation for warning patterns such as urgency, threats, impersonation and credential requests. The interface explains why something may deserve attention without treating a warning pattern as proof of fraud.

3. After a payment problem — Organise evidence and next steps

Users can review fictional receipt information, organise evidence, build a timeline and prepare a factual complaint draft that they can copy and take to the relevant official support channel.

The central idea is continuity: intent → instruction → entered details → evidence → action.

PayCheckpoint works alongside a person's existing wallet. It does not access, send, cancel, reverse or authenticate real transactions. A match between entered values is not proof of recipient identity or payment legitimacy.

How I built it

I built PayCheckpoint as a browser-based application with a local-first approach, using JavaScript, HTML and CSS, with Cloudflare Pages for hosting.

The core comparison and guidance workflows use deterministic logic rather than relying on an AI model to make financial decisions. This makes important checks explainable and allows the private offline action plan to work without a model request.

I also integrated an optional Qwen3 Copilot through Cloudflare Workers AI. It can interpret a user's consented, minimised case summary and produce more contextual next-step guidance. The cloud output passes through server-side validation and safety checks. Users can choose the offline plan instead.

The interface supports English and Bangla, with separate flows for prevention, suspicious-message review and recovery. I added evidence provenance, explicit uncertainty, privacy notices and safeguards against presenting a comparison as identity verification.

I used automated unit, browser, responsive and release checks throughout development. The final reported validation included 273/273 unit tests, 10/10 release checks, 36/36 browser checks and 70/70 responsive checks. These are software QA results, not evidence of real-world fraud-detection accuracy.

Challenges we ran into

One of the biggest challenges was balancing useful guidance with financial safety. A tool that confidently labels a recipient or promises a refund could create more harm than it prevents. I therefore designed the product to distinguish between a detected mismatch, a warning signal, an unknown fact and something that has actually been verified.

Another challenge was making the AI useful without making the product dependent on it. The deterministic offline plan remains available when cloud inference is unavailable.

The bilingual evaluation exposed an important limitation. In a developer-run evaluation of eight fictional scenarios, the cloud Copilot returned 7 of 8 English plans, while all four Bangla requests failed with HTTP 502. A later English spot-check succeeded for the English case that initially failed. The offline plan returned all eight English plans in the evaluation, although it missed an uncertainty detail in one conflicting-information case.

I also encountered the challenge of keeping a multi-step product understandable. Prevention, message review, receipt analysis and recovery can easily become overwhelming, so I worked on clearer entry points, progressive guidance and a more consistent evidence workflow.

Accomplishments that we're proud of

I'm proud that PayCheckpoint became more than a simple recipient-number comparison.

It connects a user's original intention with the details they prepare to enter, then extends that context into evidence organisation and practical next steps. The product is designed around an individual consumer's experience rather than a bank, merchant or enterprise dashboard.

I'm also proud of the local-first safety approach, the bilingual interface, the optional AI-assisted workflow and the decision to make limitations visible instead of hiding them.

The project has a working public deployment, a documented developer-run Copilot evaluation, regression coverage and automated release checks. The evaluation also tested a prompt-injection scenario; the returned English cloud plan did not follow the embedded instruction.

Most importantly, the project deliberately avoids claiming that it can verify wallet ownership, prevent every scam or recover someone's money.

What we learned

I learned that adding AI does not automatically make a product more useful or more reliable. In a financial-safety context, predictable behaviour, clear uncertainty and safe failure modes matter just as much as contextual intelligence.

I also learned that a technically successful feature is not necessarily a validated user experience. Automated tests can catch regressions, but they cannot replace real people trying to complete tasks, misunderstandings being observed, or independent reviewers evaluating AI outputs.

The Bangla cloud failure reinforced this lesson: bilingual interface support is not the same as reliable bilingual AI. A working offline alternative is valuable, but the cloud-language limitation still needs to be fixed and independently tested.

What's next for PayCheckpoint

The next priority is improving the reliability of Bangla cloud inference and making the transition to offline guidance even clearer.

I also want to conduct genuine first-use usability sessions with Bangladeshi MFS users, obtain independent English and Bangla reviews of the Copilot, and evaluate receipt and message processing against more realistic examples.

Longer term, I want to explore responsibly verified provider guidance and stronger privacy and security reviews before considering any use with real transaction information.

PayCheckpoint is currently a prototype, not a production financial service. Its next step should be proving that people can understand and use its core workflow safely—not simply adding more features.

Built With

• css3
• html5
• javascript
• node.js
• python
• qwen3
• tesseract.js