Business logic flaw

The rules your product exists to enforce. One discount per order. A refund cannot exceed the payment. A trial does not restart. Approval before dispatch.

The flaw is a gap between that rule and the code. Everything works. The result is simply not what you meant, and only you can say what you meant.

A good one can, provided the scope says so and the tester learns your product first. It is manual work. Somebody has to understand the rules before they can bend them.

Ask a supplier directly whether logic is included and what they would need from you. A vague answer usually means a scan with a report wrapped around it.

Not really, and treat anyone who claims otherwise with care. A scanner matches patterns. A logic flaw has no pattern, because every request in it is valid and every response is normal.

We will be straight about our own position. Our business-logic module ships on 4 January 2027, so we do not test this class today.

Safer, and not safe. Moving the rules to the server stops somebody editing a price in their browser. It does nothing about a rule that is wrong, or one that only holds when the steps happen in order.

Write the rule down plainly, then ask what a determined customer would try. Out of order. Twice at once. Backwards. A negative number.

It often shows up as one. Fire the same request twice in the same instant and a one-per-customer rule can pay out twice, because both requests read the balance before either changed it.

Look at anything counted, limited or spent: vouchers, credits, one-time codes, withdrawal limits. Where the check and the change are separate steps, that gap is where it goes wrong.