Customer accounts and portals

A customer account system stores personal information — names, addresses, order history, sometimes payment details — the moment a customer creates one. That is true whether or not you thought of it as “handling personal data” when you added the account feature. It triggers real privacy considerations. Separately, requiring an account at all is a genuine conversion trade-off. It’s worth deciding deliberately rather than defaulting to whatever a platform ships with.

The guest checkout decision

Requiring account creation before a customer can complete a purchase is one of the more consistently cited reasons for cart abandonment. It adds friction between a decision to buy and the ability to actually pay. Offering a genuine guest checkout — buy without creating an account — alongside an optional account for customers who want order history and faster future checkout generally serves both groups better. It works better than forcing everyone down one path.

What a customer account lets customers view, track and manage — and what it needs to store to support that

Data	Why it’s needed	Worth reconsidering
Name and contact details	Order fulfilment and communication	—
Delivery and billing addresses	Shipping and invoicing	Avoid requiring more address history than needed
Order history	Customer convenience, support	—
Saved payment details	Faster future checkout	Only store via the payment gateway’s own tokenisation, never raw card numbers on your own server
Password	Account access	Use a reputable platform’s built-in authentication rather than building your own from scratch

The privacy obligation this creates

Storing customer names, addresses and order history is personal information under the Privacy Act 1988 (Cth), and handling it engages the Australian Privacy Principles where your business is not covered by the small-business exemption — an exemption currently based on an annual turnover threshold, and one that has been the subject of active reform without a settled removal date as at the time of writing. Regardless of whether the exemption technically applies to your business, storing customer data with a genuine privacy policy, reasonable security practices, and a clear statement of what you collect and why is good practice that increasingly matters to customers directly, independent of the strict legal threshold.

Never store raw card numbers from a purchase yourself

If your account system offers “save my card for next time,” that data should be tokenised and held by your payment gateway. Never store it as a raw card number on your own server or database. This is a PCI compliance requirement, covered on payment gateways explained. It is also a straightforward security practice regardless of the compliance framing. A data breach involving stored card numbers is a categorically worse outcome than one involving order history alone.

Building versus using an existing system for managing customer accounts

Almost every mainstream ecommerce and membership platform includes a built-in, tested account and authentication system. Building a custom account system from scratch — password storage, session handling, password reset flows — introduces security risk. A well-maintained, widely used existing system has already been tested and hardened by a much larger number of implementations. Reserve custom account development for a genuine, specific requirement the platform’s built-in system cannot meet. It should never be the default approach.

Account data retention — deciding how long to keep order history and customer data

Decide explicitly how long customer account data is retained after an account becomes inactive. Don’t just keep everything indefinitely by default. Long-term retention of data you no longer need increases your exposure if a breach occurs. It has no corresponding benefit to the business or the customer. A stated retention period, and a process for deleting data at the end of it, is good privacy practice. It is also a smaller target if something does go wrong.

Social sign-in, and the trade-off it introduces

Offering sign-in through an existing account — a Google or social media login — reduces friction for customers who don’t want to create yet another password. But it also introduces a dependency on that third-party provider remaining available. Your business’s account data becomes at least partly tied to a service you don’t control. Consider whether this trade-off suits your specific customer base. Don’t assume it’s a purely beneficial addition with no downside.

Data minimisation as a practical, not just legal, discipline

Beyond what the Privacy Act requires, collecting only the account information genuinely needed for the relationship — rather than every field a platform’s default account form happens to offer — reduces both your privacy compliance surface and your exposure if a breach ever occurs. A shorter account creation form, collecting less data by design, is frequently also a better conversion outcome. That makes data minimisation one of the rare cases where the privacy-conscious choice and the commercially convenient choice point the same direction.

What happens to an account when a customer asks to close it

Under the Australian Privacy Principles, where they apply, an individual generally has rights around accessing and correcting their personal information, and a business should have a clear, workable process for closing an account and handling the associated data on request, rather than discovering there’s no defined process only when the first such request arrives. Confirm this is something your chosen platform supports before you need it urgently.

What to do next when building customer account pages

Decide whether accounts will be optional or required before a build starts, and confirm with whoever builds your account system that no raw payment card data is ever stored outside the payment gateway’s own tokenisation. Both decisions are cheaper to make correctly at the outset than to retrofit later.

Account and authentication systems are ongoing engineering, not a one-off setting — development as an ongoing engagement covers what that commitment actually looks like.