Retries and duplicates
Eknas: Bills Recorded Once
A retried bill with the same Idempotency-Key returns the original result with duplicate: true. Reusing the key for a different bill returns a 409 error, so a bad connection cannot double points.
Logic Verification & Code Review
I’m Ujjwal Rupakheti, a full-stack developer in Itahari, Nepal. My logic verification and code review service checks the rules your software runs on, such as prices, VAT, points, dates and permissions, and proves with test cases that they stay correct at the edges.
- Every rule written in plain words, then tested
- Failing inputs, code locations and suggested fixes
- Tests left in your repository, so bugs cannot return
01Overview
What is Logic Verification?
Logic verification is a focused code review of the rules your business depends on. I read the code that calculates prices, points, taxes, dates and permissions, write test cases for normal and edge inputs, and show you every case where the software gives a different answer from the one your business expects.
Functional testing asks whether a button works. Logic verification asks whether the number behind the button is right, every time, including when the network drops, two staff members act at once, or a customer types something unexpected.
These bugs rarely show up in a demo. They show up months later as a ledger that is a few rupees out, a reward redeemed twice, or a report that does not match the bank statement. That is why I treat them as a separate review rather than part of a general QA test round.
I build the same kind of software I review: loyalty points in Eknas, a charter ledger in HeliGo Nepal, and Nepal payroll rules for VAT, SSF and TDS in Eutaa. I know where these rules break, because I have had to make them hold.
Three Questions for Every Rule
Each rule is compared three ways before it gets a pass or a fail.
- What do you say it should do, in plain words?
- What does the code actually do, for normal input?
- What happens at the boundaries: zero, the maximum, the retry, the last day of the month?
02Example
What a Logic Check Looks Like
Two rules from my own products, written the way I write them for clients: the rule in one sentence, the cases that prove it, and the reason it matters. Your review gets the same format for every rule in scope.
RuleA bill is recorded once, even if the till’s network drops and it retries.
| Case | Request | Expected | Result |
|---|---|---|---|
| First request | key A, bill 1 | Recorded | Pass |
| Network retry | key A, bill 1 | duplicate: true | Pass |
| Key reused | key A, bill 2 | 409 error | Pass |
RuleThe operator’s share plus the platform’s commission always equals what the traveller paid.
Rupees as decimals0.1 + 0.2= 0.30000000000000004
Whole paisa10 + 20= 30, exactly
03Proof
Edge Cases I Have Solved in My Own Products
Three examples from software I built and run. Each one is a rule that looks simple, fails quietly when it is wrong, and needs a deliberate design and a test to keep it right.
Limits and safe exports
Nimtto: Safe RSVP Exports
RSVP exports escape spreadsheet formulas, so a guest who types one into the name field cannot run it when the family opens the file in Excel. Couples can correct names three times and move the date by up to 60 days.
Money and rounding
HeliGo: A Ledger in Paisa
Prices, commissions, refunds and settlements are added and split as whole paisa, without floating-point rounding, so the operator’s share and the commission always equal what the traveller paid.
Dates need the same care. In Pustau, my family tree app, Bikram Sambat to AD conversion is checked against published calendar data for every day from 1970 to 2100, because BS month lengths follow no fixed formula.
04Scope
What Do I Check in a Logic Review?
The rules where a wrong answer costs money, trust or legal trouble: calculations, limits, retries, state changes, permissions, dates and data exports. We agree the list of rules before I start.
Calculations & Rounding
Prices, discounts, 13% VAT, commissions, and SSF and TDS where payroll is involved, as in Eutaa. I look for floating-point maths on money, rounding in the wrong place and totals that do not reconcile.
Limits & Rules
Reward caps, coupon stacking, plan limits, approval thresholds and expiry dates. Rules like these need tests on both sides of the limit, not only in the middle.
Retries & Duplicates
A double click, a refreshed payment page, a webhook delivered twice or a request retried after a timeout. Payment and points systems need idempotency, not luck.
State & Workflow
Orders, bookings and approvals that move through states. I check that invalid jumps are refused, such as a cancelled order marked as delivered, and that every step is logged.
Permissions & Data Exposure
Every rule checked on the server, not only hidden in the interface. I call the API directly as each role and look at what responses leak, such as full phone numbers where a masked one would do.
Dates & Time Zones
Bikram Sambat and AD conversion, fiscal years that start in Shrawan, Nepal’s UTC+5:45 offset and daylight saving for clients abroad. Off-by-one-day bugs hide here.
05Process
How a Logic Verification Engagement Works
You tell me the rules in plain words, I read the code that implements them, write test cases that prove or break each rule, and report every mismatch with a failing case and a suggested fix. You keep the tests, not only an opinion.
Rules in Plain Words
Each rule as a sentence you agree with, such as “a bill is recorded once, even if the till retries”.
Code Reading
I trace each rule through the code, database and API, in TypeScript, Python, Java or SQL.
Test Cases
Normal, boundary and hostile inputs for each rule, written as automated tests where possible.
Findings
Each mismatch with the failing input, the likely cause and a suggested fix, ranked by impact.
Verify Fixes
I rerun the cases after your fixes and leave the tests in your repository.
06Deliverables
What You Get from a Code Review
A written report of every rule I checked, with a pass or fail for each, the failing inputs, the code location and a suggested fix. Where your stack allows, the test cases come as automated tests, so the same bug cannot quietly return later.
In the Report
Written for your developers, with a summary you can read in five minutes.
- A rule-by-rule table: expected, actual, status
- Failing inputs that reproduce each problem
- File and function references for every finding
- Suggested fixes, with code snippets where they help
- Automated tests for each rule, in your test framework
- A call to walk your developers through the findings
- Languages
- JavaScriptTypeScriptPythonJavaSQL
- Frameworks
- Next.jsNode with Express or FastifyFastAPIFlask
- Databases
- PostgreSQLMySQLSQLite
Where business logic touches security, such as access control or injection through exports, I follow the OWASP Top 10. This is not a formal penetration test. For schema problems behind the logic, see database design.
07Timing
When Should You Get Your Business Logic Verified?
Before you launch anything that moves money or points, before you open an API to partners, after a large refactor, and whenever two reports disagree about the same number. Finding a rounding bug in a review costs far less than finding it in your accounts.
Good Moments for a Review
- Before launching payments with eSewa, Khalti or Fonepay
- Before opening a public API or webhooks to partners, see API development
- After moving to a new framework, ORM or database
- When payroll, VAT or commission totals do not match by hand
- When a contractor built the core logic and has since left
Once the rules are right, keep them right with a regression test suite that runs before every release. The tests from a logic review drop straight into it.
Logic verification is quoted per project, based on how many rules and how much code are in scope. A review of one payment or points flow is a small job; a full review of a payroll or marketplace system is a larger one. You get a fixed quote after a short call and a look at the code.
International clients are invoiced in USD by bank transfer, Wise or PayPal, and I am happy to sign an NDA before you share access. Starting prices for builds and audits are on my services page.
Want the rules built right the first time?I build business software, payroll and payment systems with these checks from day one, so the review is part of the build.
Software developmentFAQ: Logic Verification & Code Review
Edge cases, paisa, idempotency, code access and price, answered before you ask.
Ask me on WhatsAppLogic Verification vs Code Review: What’s the Difference?
A general code review looks at style, structure and readability. Logic verification is a code review focused on correctness: does each business rule give the right answer for every input your users can send. I do both, but this service puts correctness first.
What’s an Edge Case in Software Testing?
An edge case is an input or situation at the limit of what a rule handles: zero, the maximum, an empty field, the last day of a month, two actions at the same moment, or a retry after a timeout. Most expensive logic bugs live at these edges.
Why Store Money in Paisa Instead of Rupees with Decimals?
Computers store decimal fractions approximately, so adding 0.1 and 0.2 does not give exactly 0.3. Storing whole paisa, as HeliGo Nepal does, keeps every sum exact, so commissions, refunds and settlements always add up to what the customer paid. The same rule works in any currency: store the smallest unit.
What Does Idempotency Mean for Payments?
An idempotent request gives the same result however many times it is sent. If a bill or payment request is retried after a network drop, idempotency means it is recorded once, not twice. Eknas uses an Idempotency-Key header for exactly this.
Do I Need to Share My Source Code?
For a full review, yes, usually as read-only access to the repository, and I am happy to sign an NDA first. If you cannot share code, I can still test the rules from outside through the app and API, though the findings will be less precise.
Which Languages Do You Review?
JavaScript and TypeScript on Node, Express, Fastify and Next.js, Python with FastAPI or Flask, Java, and SQL on PostgreSQL, MySQL and SQLite. These are the languages I build production software in. If your code is in another language, tell me and I will say honestly whether I can review it properly.
Can You Check Nepali VAT, SSF and TDS Calculations?
Yes. I built Eutaa, an HR, payroll and finance system with Nepal payroll rules for VAT, SSF and TDS, so I know where these calculations go wrong. I check your code against the rules you or your accountant set; I do not give tax advice.
Is This a Security Audit?
No. I check security problems that are really logic bugs, such as missing access checks, data leaks in API responses and formula injection in exports. A formal penetration test or compliance audit needs a specialist security firm, and I will tell you if your project needs one.
How Much Does a Code Review Cost?
It is quoted per project, based on how many rules and how much code are in scope. One payment or points flow is a small job; a full payroll or marketplace system is larger. You get a fixed quote after a short call, and fixes can be quoted separately.
Do You Work with Clients Outside Nepal?
Yes. I work remotely from Itahari on Nepal time (UTC+5:45), invoice international clients in USD by bank transfer, Wise or PayPal, and sign an NDA on request before you share repository access. Findings and tests are written in clear English, so any developer can act on them.
Tell Me the Rule You’re Least Sure About.
Describe the calculation, limit or permission that worries you and the stack it runs on. I reply within one working day with questions or a quote.
Ujjwal RupakhetiReplies within one working day
What should I check?
Opens WhatsApp with your message started.