Partner Requirements

Paysense is an ATO-registered digital service provider (DSP). When you embed Paysense or call it from your platform, your users reach payroll data through your product. Some of our obligations to the ATO and to Beam therefore apply to your platform as well.

This page sets out those requirements. Read it before you start building. The authentication, Beam and data handling requirements all affect how you design your product.

Area	Summary
Payroll responsibilities	Paysense keeps the payroll engine compliant. You and your employers own configuration, pay data and pay run approval.
Authentication	Every user who can reach payroll data through your platform must sign in under the ATO's authentication standards, and you keep a log of those sign-ins.
Beam Clearing House	Each employer registers with Beam directly, through the Paysense landing page, using Beam's approved wording unchanged.
Data handling	Paysense holds the payroll data. You give each person their own Paysense user, confirm employer contact details, and protect anything you store.

Payroll responsibilities

Payroll outcomes depend on both the engine and how it is set up. Responsibility is split as follows.

Paysense:

• Keeps the payroll engine current with tax, Single Touch Payroll (STP) and superannuation legislation.
• Fixes calculation errors caused by the engine.

You and your employers:

• Configure pay items, employee details and settings correctly.
• Supply the pay rates and conditions that apply under each award or agreement, through the API or in Paysense settings. Paysense does not interpret awards.
• Enter accurate pay data (hours, rates, leave, allowances).
• Review and approve each pay run before it is finalised.

Where your platform serves several businesses, the employer for each pay run is the business whose employees are being paid, not your company. Build your product so that each employer reviews and approves its own pay runs.

Authentication

The ATO requires multi-factor authentication (MFA) for everyone who can access tax, payroll or superannuation information, whether for themselves or for others. As a DSP, Paysense must make sure that anyone who reaches payroll data through an integrated platform meets this standard.

With the UI integration or the partner API key, your users sign in to your platform, not to Paysense. Your sign-in must therefore meet the controls below.

Control	Requirement
MFA	Required for all staff and end users who can access payroll data.
MFA cannot be turned off	MFA is permanent. Users and employers must not be able to disable it.
No shared logins	Each login belongs to one person. Shared logins must be blocked.
Idle session timeout	Lock the session after no more than 30 minutes of inactivity (15 minutes preferred). Unlocking a locked screen does not need full MFA.
Remember me	Limited to a maximum of 24 hours.
Brute force lockout	Lock the account after no more than 5 failed sign-in attempts. How you lock and unlock is up to you.
Tokens and temporary credentials	Tied to a single device, expire once used, and expire within 24 hours at most.
Authenticator apps	Allowed, for example Microsoft Authenticator, Google Authenticator or Symantec VIP. You must be able to show how MFA is enforced at sign-in.
Social media sign-in	Do not use social media accounts (for example Facebook or TikTok) as an MFA factor.

warning

If you cannot meet a control in full, talk to Paysense before you go live. Variations need to be agreed with the ATO, which may accept other compensating controls.

Paysense may ask you to show how your platform meets each control, for example in a demo or with screenshots of your security settings.

Keep sign-in logs

Your users sign in to your platform, so Paysense never sees those events. Keep a log of them for at least 12 months, and do not delete entries within that period. Each entry must include:

• the user's unique identifier
• the date and time
• the event, for example sign-in, MFA challenge, lockout, or a change to the user's permissions
• whether it succeeded or failed
• the device or location, for example IP address and user agent

Log changes to privileged access, and make privileged users identifiable in the log.

Beam Clearing House

Paysense pays superannuation through the Beam Clearing House. Beam needs each employer to have its own relationship with Beam, so:

• Each employer signs up to Beam directly. Your company does not register on behalf of the businesses you serve.
• Each employer gives its own direct debit authority. Super contributions are debited from the employer's own account.
• Sign-up starts from the Paysense landing page. Embed the Beam Landing Page in your product. It shows Beam's approved introduction and disclaimers, and hands the Register with Beam click to your page.

Beam controls how it is described to employers:

• Use Beam's approved wording exactly as it is. Do not edit, shorten or rewrite it. The landing page does this for you, which is why it must be framed from Paysense and not copied.
• Do not recommend Beam or Australian Retirement Trust (ART), or their products, anywhere in your product, emails or support material. Describe Beam as the clearing house Paysense uses, and leave the decision to the employer.

Data handling

Paysense is the source of truth for payroll data. It hosts that data in Australia, encrypts it at rest and in transit, and keeps an audit log of every action for at least 12 months. Your platform sits in front of Paysense, so some controls can only be met on your side.

Control	Paysense	You
Hosting and encryption at rest	All payroll data, hosted onshore and encrypted.	Any payroll data you copy or cache (see Data you store).
Encryption in transit	Requires TLS 1.3.	Connect over TLS 1.3. Serve every page that shows payroll data over HTTPS.
Audit logging	Logs every API and UI action against the user who made it.	Give each person their own Paysense user, and log sign-in events on your platform.
Entity validation	Checks each business's ABN against the Australian Business Register.	Make sure each employer's contact email and mobile are confirmed.
Security monitoring	Monitors the Paysense platform.	Monitor your platform and tell Paysense about incidents.

One Paysense user per person

The ATO requires every action on payroll data to be traceable to one person. Paysense records the user named in the access token, so each person in your product needs their own Paysense user:

1. When a person first needs payroll access, create a Paysense user for them with POST /api/admin/users (see Create a user).
2. For each session, exchange your partner API key for that user's token (see Get a user token) and make their calls with it.

Every call is then logged against that person.

Confirm employer contact details

The ATO requires a confirmed email address and phone number for every business using payroll. Creating a business through the API checks the ABN against the Australian Business Register, but it does not confirm the mobile number, and it confirms the email only when it matches the email of the user creating the business.

Confirm both before the business runs payroll, in one of two ways:

• You confirm them in your own onboarding, for example with a one-time code, then record that in Paysense. The record is kept in the Paysense audit log against your user, so only record a contact you have actually confirmed.
• Paysense sends a one-time code to the business contact, and the employer enters it in your product.

The calls for both are in Onboarding a Business via the API.

Data you store

Read payroll data from Paysense when you need it, rather than keeping your own copy. Webhook payloads carry only IDs and the event type, so they hold no sensitive data. If you do store payroll data, such as payslips, bank details or tax file numbers (TFNs), you must:

• host it in Australia, including backups and redundant copies
• encrypt it at rest with an approved algorithm, such as AES-256
• manage the encryption keys under a documented process covering generation, storage, rotation and revocation
• limit access to the people and services that need it

TFNs are also protected by the Privacy (Tax File Number) Rule 2015. Do not store them unless you must.

Credentials

Your partner API key and UI integration shared secret give access to payroll data, and your webhook signing secret would let someone forge deliveries to you. Keep them on your servers in a secrets store, never in browser or mobile code. If one may have been exposed, email security@fwdigital.com.au straight away so it can be revoked.

Incidents

Email security@fwdigital.com.au as soon as you become aware of a suspected security incident involving payroll data, Paysense credentials, or the accounts of users who can reach payroll data. Paysense needs this to meet its own reporting obligations to the ATO.

Checklist

Payroll and Beam

• Each employer reviews and approves its own pay runs in your product.
• Each employer registers with Beam itself, from the embedded Beam Landing Page.
• Beam wording is unchanged, and nothing in your product recommends Beam or ART.

Authentication

• MFA is enforced for every user who can reach payroll data, and cannot be turned off.
• Shared logins are blocked.
• Idle timeout is 30 minutes or less, and remember me is 24 hours or less.
• Accounts lock after 5 or fewer failed sign-in attempts.
• Tokens and temporary credentials are single-device, single-use and expire within 24 hours.
• Sign-in events are logged and kept for at least 12 months.

Data handling

• Each person has their own Paysense user, and calls use a token for that user.
• Each employer's contact email and mobile are confirmed before it runs payroll.
• Any payroll data you store is hosted in Australia and encrypted at rest.
• Partner credentials are kept server-side in a secrets store.
• You report security incidents to security@fwdigital.com.au.
• Paysense has your entity name, ABN and connection details.

Questions

Contact your Paysense partner manager (or reach out via the website) if anything here is unclear or affects your design.