Payment Confirmation App for Small Merchants Against Fake Screenshots
A final year project that builds an Android app for small shops and social media sellers that confirms wallet and bank payments from the merchant's own incoming alerts, matches them to open orders, and announces them aloud, so goods are never released on a customer's edited screenshot. Local processing, no bank integration needed.
Intermediate
A small team, or one strong student willing to learn something new.2 semesters · 2 to 3 students
7 to ship
3 optional extrasSuggested stack
What you should ship
- Notification listener that reads payment alerts from the merchant's own wallet and banking apps, with explicit consent and an app allow-list
- Parser that extracts amount, sender name or masked number and transaction ID from alerts of at least 3 providers, with a test corpus
- Open orders list (amount and customer) and automatic matching of incoming payments to orders, with manual resolution of ambiguous matches
- Spoken announcement of each confirmed payment in Urdu or English, like a payment soundbox
- Screenshot check mode that tells staff plainly: this order has no matching payment alert yet, do not hand over goods
- Daily reconciliation screen of received, matched and unmatched payments with CSV export
- Evaluation on a labelled corpus of real and synthetic alerts, plus a two-week trial with at least 3 merchants
If you have time left
- Customer-facing payment request with an order reference to make matching exact
- Multi-device mode so a counter phone and the owner's phone share confirmations
- Parser rules updated from a small signed rules file without an app update
The problem merchants have with payment proof
Instant mobile payments have made it normal for a customer to pay a small shop or an Instagram seller by wallet or bank transfer and show a screenshot as proof. Edited and fake payment screenshots are a well-known scam: the customer shows a convincing image, the staff member hands over goods, and no money ever arrives. The owner often is not at the counter, and a busy helper will not open the wallet app and scroll through transactions for every sale.
This happens wherever instant payments are common: JazzCash, Easypaisa and Raast transfers in Pakistan, UPI in India, M-Pesa in East Africa, and bank transfers in many other markets.
What already exists and the gap
- Paytm Soundbox and similar devices: a speaker linked to one provider's QR that announces payments; hardware, one provider, no order matching.
- Wallet merchant apps (JazzCash Business, Easypaisa merchant): show payments to that provider only.
- UPI payment alert apps on Google Play: read notifications and speak the amount; no link to orders and no reconciliation.
The gap is a provider-neutral app that turns the merchant's own trusted alerts into confirmations, matches them to what is being sold, and gives staff a clear yes or no.
What you build
- Owner: sets up allowed payment apps, sees daily reconciliation, resolves unmatched payments.
- Counter staff: creates an open order (amount and name), hears a confirmation when it is paid, checks status before releasing goods.
Flows: create order, payment arrives, match, announce, release; end of day reconcile.
The technically interesting part
Parsing untrusted, changing formats. Payment alerts differ per provider and change without notice. Build a rule-based parser per provider, backed by a test corpus of real alert texts collected with consent and anonymised. Unknown formats must fail safely (unmatched, not misread).
Trust boundary. Only notifications posted by allow-listed package names count, never text shown in a customer chat or image. Explain in the report why a screenshot cannot be trusted and a notification from the merchant's own wallet app can, and where that assumption breaks (a compromised phone, a notification spoofing app). Use the OWASP mobile guidance to review your own app.
Matching. Two orders of the same amount at the same time are ambiguous. Use amount, time window and optional sender name, and hand ambiguous cases to a person rather than guessing.
How to evaluate it
- Parser precision and recall per provider on a corpus of at least 200 alerts, including format changes and non-payment notifications.
- Matching accuracy on a simulated busy day with duplicate amounts.
- Time from alert to spoken confirmation on a low-end phone.
- A two-week trial with at least 3 merchants: payments confirmed, mismatches, and staff feedback.
Suggested plan
- Weeks 1 to 3: interview merchants, collect alert samples with consent, check Google Play policy on notification access.
- Weeks 4 to 8: notification listener, allow-list, parser and corpus tests.
- Weeks 9 to 14: orders, matching and announcements.
- Semester 2, weeks 1 to 5: reconciliation, export, security review.
- Weeks 6 to 10: merchant trial.
- Weeks 11 to 14: evaluation and report.
Path to a product
Charge merchants a small monthly fee; social media sellers with many transfers a day feel this pain most. A payments company or bank could license it as a merchant tool for its customers. Keep all processing on the phone, which makes the privacy story simple.
Scope warning
Do not move money, hold funds or integrate with bank APIs. Do not read SMS inboxes (Play policy restricts this). Do not attempt image forensics on screenshots; the design point is to never need the screenshot.
Learn what you need on Sefism
- Mobile roadmap : Android services, permissions and storage.
- Mobile cheat sheet : quick reference for background work and permissions.
- OWASP mobile application security : threat model and checks for your own app.
- Google Play Console help : policy on notification access and sensitive permissions.
- Android developers documentation : NotificationListenerService and TextToSpeech.
Get help with this idea
Play policy and the trust boundary are the two things to get right before writing code. A mentor can help you cut the scope to what your team can finish, choose between the stack options above, and design an evaluation your examiners will respect. You still build it; the help is on decisions, not code.
New here? Create a free account first.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.