Billing logic is where security testing meets revenue. A flaw here does not leak data, it lets somebody use your product without paying, and those techniques circulate quickly once one person finds them. OWASP treats business logic testing as its own discipline because no scanner can know that a downgrade should remove a feature or that a trial should only be available once.
The paths worth testing
Start with the state changes rather than the pages. Upgrade, downgrade, cancel, reactivate, add seats, remove seats, change payment method and apply a credit are each a transition where entitlements are recalculated. Test what happens when they are performed in unusual orders, when a request is repeated, and when a step is skipped by calling the endpoint directly. Cancelling a subscription and then reactivating it within the billing period is a common way to obtain a second free trial, and paying for one seat while adding ten is a common way to discover that seat counts are enforced only in the interface rather than in the API behind it.
Where the money is calculated
Anything computed on the client is a suggestion rather than a fact. Prices sent from the browser, discounts applied in JavaScript and usage totals reported by the application all need recalculating on the server before they touch an invoice. Metered billing deserves particular attention, since usage is frequently reported by the client or by a job that trusts client-supplied figures without any independent check. Proration is worth testing too, because the arithmetic of mid-cycle changes is complex and errors there tend to favour whoever discovers them rather than the business.
“The finding that costs real money is usually the coupon system. Single-use codes that can be applied twice, expired codes that still validate, referral credits that can be claimed by inviting yourself with a plus-address. None of it needs technical skill, which means your customers will find it, and one post on a deals forum turns a quiet flaw into a very expensive weekend.”
William Fieldhouse, Director, Aardwolf Security Ltd
Trusting the payment provider correctly
Webhooks from your payment provider drive entitlement changes, and they arrive at a public endpoint. Verify the signature on every one, check the event has not been replayed, and confirm the amount and currency match what you expected rather than accepting the event as authoritative. Applications that grant access on receipt of an unverified webhook can be given a subscription by anyone who learns the URL and the payload format, both of which are documented publicly by the provider.
Scoping this into a test
Tell the tester how the money works, because they cannot infer the rules from the interface. Explain the plans, the entitlements attached to each, the trial policy and how usage is measured. Then ask for business logic penetration testingas an explicit objective rather than assuming it falls out of a general assessment. Where mobile clients or partner integrations can also change subscriptions, include API business logic testing, since those paths often bypass the checks the web front end performs.
Frequently asked questions about billing logic testing
These questions come up whenever a subscription product is assessed.
Do scanners find any of this?
No. A scanner has no idea what a plan entitles a user to do, so it cannot recognise that a downgraded account still has access to a premium feature. Every finding here comes from someone understanding the product.
How much time does it need?
A day or two on top of a standard application test for most products, more where plans are complex or usage is metered. It is usually the best value time in the engagement for a subscription business.
