Compliance has a reputation as something that happens at the end, in a document nobody reads. That is a good way to end up rebuilding a billing flow. Most of the rules that apply to Australian consumer software are not document problems at all. They are specifications for how a screen has to behave.
Here is the set that has actually changed what we build. As before: not legal advice, and a solicitor should read your version.
Consumer guarantees are not a warranty policy
Under the Australian Consumer Law, goods and services supplied to consumers come with guarantees that cannot be excluded, restricted or modified. Not by your terms of service, not by a checkbox at checkout, not by a clause imported from an American template.
The parts that matter for software:
- Services must be supplied with due care and skill, be fit for purpose and be delivered within a reasonable time.
- A major failure entitles the customer to a refund or replacement, and to compensation for reasonably foreseeable loss.
- A failure that is not major entitles the customer to have it fixed in a reasonable time, and if that does not happen, to cancel and get a refund for the unused part.
- These apply on top of whatever your published policy says, and a more generous policy is allowed while a less generous one is not.
The product consequence is that “no refunds” is not a policy you can have, and a refund process designed to be exhausting is a legal risk as well as a bad experience. Build the path that assumes a person who asks for a refund will get one, and make it cheap to grant.
There is a second consequence that is easy to miss: misleading claims are their own offence, independent of anything going wrong. Marketing copy that overstates what a product does is not enthusiasm, and neither is a comparison table with a favourable thumb on the scale. If the software cannot do the thing in the screenshot, the screenshot is the problem.
Subscriptions have to be as easy to leave as to join
Recurring billing attracts regulatory attention everywhere, and Australia is no exception. The pattern regulators object to is consistent: easy to start, hard to stop, renewal by silence, and a price change nobody was told about.
What we build instead, as product requirements rather than policy text:
- Cancel from inside the product, in the same number of clicks it took to subscribe. No phone call, no retention queue, no email-us-to-cancel.
- Say what happens when you cancel on the cancellation screen itself. Access until the end of the paid period, no further charges, data retained or deleted on a stated schedule.
- Show the renewal date and amount before the first charge and on every receipt.
- Email before a price change, well in advance, with the option to leave first.
- Make a free trial say when it ends and what it becomes. A trial that silently turns into a charge is the pattern everyone is complaining about.
None of that is charity. A person who leaves cleanly comes back. A person who had to fight their way out lodges a chargeback and tells people.
App stores are a second regulator
If you ship a mobile app, the store’s rules apply on top of the law, and the store enforces them faster than any regulator will.
The things that catch small developers:
Purchases of digital content generally have to go through the store’s billing, which means the store’s commission, the store’s price tiers and the store’s subscription management. Both major stores run reduced commission rates for developers under an annual revenue threshold, which materially changes the arithmetic for a small company.
The store sets the price tiers and the currency in each country. You do not choose a number and have it appear everywhere. This is exactly why a corporate site should not publish a single price in a single currency and call it universal.
The store often becomes the merchant of record, collecting and remitting local taxes on the sale. That is convenient and it means the tax treatment of a store purchase differs from a web purchase of the same product.
Cancellations and refunds go through the store. A customer who subscribed on a phone cancels in their store account, not in your app, and your support has to know that.
Privacy labels are a published commitment. The disclosure you make in a store listing has to match what the app actually does, and updating one without the other is how an honest team ends up with a false statement on a public page.
Tax and records, briefly
Australian businesses registered for GST generally charge it on sales to Australian customers, and receipts need to look like tax invoices when they are one. Sales through an app store may be handled differently because of the store’s role in the transaction. Business records need to be kept for five years.
The engineering consequence is small but real: your receipts are financial documents. They need the entity name, the ABN, the amount, the tax component where it applies and the period covered. Retrofitting that into an email template after a year of sales is unpleasant, and getting it right on day one costs nothing.
Accessibility is a legal question here
The Disability Discrimination Act 1992 makes it unlawful to discriminate in the provision of goods and services, and Australian courts have applied that to websites. The well-known case from the Sydney Olympics organising committee is more than twenty years old, which tells you this is not a new or exotic idea.
The practical standard is WCAG, at level AA. For a product team that means:
- Real colour contrast, checked rather than eyeballed. Every foreground and background pair on this site clears AA, and the two we had to adjust were both “surely that’s fine” cases.
- Every interactive element reachable and operable by keyboard, with a visible focus ring.
- Form fields with real labels, and errors that say what to fix.
- Images with alt text that carries the information, and decorative images marked as decorative.
- Content that survives being zoomed, and a layout that works at 400 pixels wide.
- Semantic HTML, because it is the cheapest assistive technology support there is.
This is a day of work on a small product if you do it as you go, and a project if you leave it. It also makes the software better for everyone, which is the argument that actually persuades people.
Sector rules, if they apply to you
Some products land inside a specific regime. My Energy Agent sits near the Consumer Data Right, which was extended to the energy sector, and near the retail rules administered by the Australian Energy Regulator. A health-adjacent product touches health information, which the Privacy Act treats as sensitive and subject to stricter handling.
The general lesson is to find out early whether your sector has its own rules, because they tend to constrain the data model, and a data model is expensive to change after launch.
How we hold it
Three practices, all cheap:
Write the policy from the software, not the software from the policy. Every sentence in a terms page should describe something the product actually does. If it does not, one of the two is wrong.
Put the constraint in the ticket. “Cancellation must complete in-app without contacting support” is an acceptance criterion. “Comply with the ACL” is not.
Review when the product changes, not annually. A policy review on a calendar is theatre. A policy review triggered by shipping a billing change is useful.
Next, and last in the series: shipping with a small team.