Online forms and payments for SA councils and small businesses: a practical guide

Most South Australian councils and small businesses still run part of their customer service on PDF forms, email inboxes and phone payments. A resident downloads a permit application, prints it, signs it, scans it and emails it in; a customer reads a card number over the phone; a staff member retypes everything into another system. Moving those journeys online saves rekeying and makes life easier for customers, but a form that takes personal information and money touches accessibility, privacy, card security and record keeping all at once. This guide explains the obligations that shape a good design, the payment choices that keep your PCI DSS scope small, and a practical 90-day plan. It is general guidance, not legal or compliance advice; confirm details with your acquiring bank, governance team and advisers.

Why PDF and email forms cause trouble

• They are hard to use. Fillable PDFs often fail on phones, with screen readers and with keyboard-only navigation, which shuts out the people who most need an easy channel.
• Errors are found late. A missing document or wrong lot number is discovered days later by an officer, who then has to chase the applicant.
• Data is retyped. Every manual copy into a property, finance or case system is a chance for mistakes and a cost that grows with demand.
• Personal information spreads. Attachments sit in shared mailboxes, downloads folders and personal drives, outside your records system and your retention rules.
• Card details travel the wrong way. Card numbers written on forms, emailed or noted during calls bring your inboxes, phones and staff into PCI DSS scope.

The obligations that shape the design

Accessibility

Forms are where most accessibility failures hurt. SA Government and most councils expect WCAG 2.2 Level AA (see our guide to WCAG 2.2 for SA Government and council websites). For forms, the criteria that matter most are:

• Labels and instructions (3.3.2) that stay visible, rather than placeholder text that disappears when someone starts typing.
• Error identification and suggestion (3.3.1, 3.3.3) in plain words, next to the field, and announced to screen readers.
• Identify input purpose (1.3.5) so browsers and assistive technology can autofill names, addresses and phone numbers.
• Redundant entry (3.3.7): do not make people type the same information twice in one process.
• Accessible authentication (3.3.8): no puzzle or memory test to log in or prove you are human without an accessible alternative, and allow password managers and paste.
• Target size (2.5.8) so buttons, checkboxes and date pickers work on a phone.

Privacy

There is no general privacy statute for SA councils. State agencies are bound by the Information Privacy Principles Instruction (Premier and Cabinet Circular PC012), councils usually adopt a privacy policy aligned with similar principles, and many businesses and not-for-profits are covered by the Privacy Act 1988 (Cth), which currently exempts many small businesses with turnover under $3 million, with important exceptions. Whichever applies, the design rules are similar: collect only what the process needs, show a clear collection notice at the point of collection, limit who can see submissions, and delete or archive data on a schedule. If a breach happens, our guide to notifiable data breaches explains what to do next.

Card payments and PCI DSS

Anyone who accepts card payments must meet the Payment Card Industry Data Security Standard (PCI DSS), currently version 4.0.1, and validate compliance in the way your acquiring bank requires. Most councils and small businesses validate with a Self-Assessment Questionnaire (SAQ), and the payment design you choose decides which one, and how much work it is. The aim is simple: card data should never touch your web server, your inboxes or your staff.

Records and evidence

For councils and agencies, a submitted application is an official record under the State Records Act 1997 (SA). Submissions, attachments, decisions and receipts should be captured into the records system with the right classification (for councils, against General Disposal Schedule 40), not left in a form tool forever. Our guide to council records and FOI workflows covers the wider design. The Electronic Transactions Act 2000 (SA) generally allows electronic forms and signatures, but some legislation prescribes a particular form, witness or signature, so check the law behind each permit before you remove the paper version.

Choosing how to take payments

Approach	How it works	What it means for you
Redirect or hosted payment page	After the form, the customer is sent to the payment provider’s page, pays there and returns with a reference.	The smallest scope for most organisations; usually eligible for SAQ A. You still protect the page that sends people to the provider.
Embedded payment form (iframe or hosted fields)	The provider’s card fields appear inside your page, so the customer never leaves your site.	Smooth experience and often still SAQ A, but under PCI DSS 4.0.1 you must confirm your page is not susceptible to script attacks, either with controls like requirements 6.4.3 and 11.6.1 or with written confirmation from your provider.
Direct API or your own card fields	Card data passes through code you control before it reaches the provider.	Much larger scope (SAQ A-EP or more) and ongoing testing. Rarely worth it for council or small business forms.
Pay later by link, BPAY or PayTo	The form creates an invoice or reference, and the customer pays through a link, BPAY or an agreed PayTo payment.	Useful when fees depend on assessment. Fully outsourced links keep card scope minimal; reconcile by reference.

Whichever you pick, ask your acquirer which SAQ applies before you build, keep the provider’s attestation of compliance on file, and never ask for card numbers in a form field, attachment, email or chat. For phone payments, a provider’s secure phone payment service or a pay-by-link sent during the call keeps card numbers away from staff and call recordings.

A practical design

1. An accessible form layer. Build each form from one tested set of components, with plain-language questions, conditional sections so people only see what applies to them, save-and-return for long applications, and server-side validation as well as browser checks.
2. Spam protection that does not lock people out. Use hidden honeypot fields, rate limiting and server-side checks first. If you need a challenge, choose one that meets WCAG 2.2 accessible authentication rather than a visual puzzle.
3. Payment handed to a PCI DSS compliant provider using a redirect or embedded form, with the payment reference written back to the submission automatically.
4. Workflow and routing. Each submission becomes a case with a status, an owner and a due date, routed to the right team, with acknowledgement and status updates sent to the customer. Our council customer request and field service architecture shows this pattern for councils, and the state government citizen service architecture shows it at agency scale.
5. Integration instead of rekeying. Push the data into the property, licensing, case or CRM system through its API, and post payments to finance. For small businesses, our CRM and accounting integration architecture shows how online payments reconcile to Xero or MYOB.
6. Records capture and retention. File the submission, attachments and receipt as a record, then purge the copy in the form platform after an agreed period so personal information does not pile up.
7. Simple reporting. Track completion rates, drop-off points, time to decision and payment failures so you can improve the form instead of guessing.

Configure, buy or build?

• Configure what you own. If your CRM, customer request system or Microsoft 365 platform already has a forms capability that meets WCAG 2.2 AA and integrates with your payment provider, start there.
• Buy a forms platform when you have many forms, non-technical staff who need to change them, and standard payment and records connectors. Check accessibility claims by testing a real form, and confirm where data is hosted.
• Build custom for a small number of high-volume or complex journeys, such as a multi-step permit with fee calculation, map lookups and integration with several systems. Our guide to custom software vs SaaS for SA small businesses walks through the trade-offs.

Security controls to insist on

• Control the scripts on form and payment pages. Keep an inventory of every script, remove analytics and chat widgets from payment steps, use a Content Security Policy and Subresource Integrity, and monitor for unexpected changes.
• Scan uploads. Limit file types and sizes, scan attachments for malware and store them outside the public web root.
• Protect the back office. Require MFA for anyone who can see submissions or change forms, review access regularly, and log exports. Our Essential Eight guide covers the baseline controls.
• Know where data lives. Prefer Australian hosting for submissions and attachments, and check where the form platform’s support staff and backups sit (see Australian data residency for SA Government ICT).
• Test before every change. Run automated accessibility and security checks in the delivery pipeline, and a quick keyboard and screen reader check on any changed form.

A 90-day plan

1. Weeks 1 to 2: inventory. List every form, PDF and payment channel, who owns it, the system it feeds and how often it is used. Pick two or three high-demand forms that cause the most rework.
2. Weeks 3 to 4: decide the pattern. Choose configure, buy or build, choose the payment approach, confirm the SAQ with your acquirer, and agree the records classification and retention for each form.
3. Weeks 5 to 8: build the first forms. Write questions in plain language, build them from accessible components, connect payment and the back-office system, and set up routing and notifications.
4. Weeks 9 to 10: test with real people. Test with keyboard, screen readers and phones, run a small pilot with customers and front-counter staff, and fix what confuses them.
5. Weeks 11 to 12: go live and retire paper. Publish the online form, keep an assisted channel for people who need it, redirect the old PDF links, and start reporting on completion and drop-off.

Questions to ask before you engage anyone

1. Will card data ever touch our servers, inboxes or staff, and which SAQ will we validate against?
2. How will you prove the forms meet WCAG 2.2 AA, including on phones and with screen readers?
3. Where are submissions, attachments and backups stored, and for how long?
4. How do submissions and payments reach our case, property, finance or CRM system without rekeying?
5. How are submissions captured as records, and what is purged from the form platform afterwards?
6. Can our own staff safely change wording and add simple forms without a developer?
7. How are scripts on form and payment pages controlled and monitored?

This article reflects common practice as at late 2026. PCI DSS, privacy law and accessibility guidance change, so confirm current requirements with your acquiring bank, the PCI Security Standards Council, the OAIC, State Records and your advisers before committing.

Talk to an Adelaide team

If you want to turn PDF forms and phone payments into accessible online journeys that feed your systems directly, talk to us about a forms and payments review or call 0402 401 584. We can start with a short, fixed-price review of your highest-demand forms that produces a prioritised plan you can use with any supplier. You can also read about our application development, website design and intelligent automation services.