Guide for DSPs using an SSP

This guide is for payroll software providers who connect to the ATO through a Sending service provider (SSP). For an overview, see Sending service providers (SSP) overview.

On this page

When to use an SSP

Use an SSP when your product can generate Single Touch Payroll (STP)-compliant output but you do not implement the ATO’s required SBR ebMS3 transport and STP-conforming message structure. The SSP performs the conforming transformation and transmission using its machine credential and polls for ATO outcome.

If you already implement SBR ebMS3 transport, conforming message structure, cloud authorisation and response handling, you may transport directly, otherwise an SSP must be used to meet these technical requirements.

Product prerequisites

Your product must produce STP-compliant output in line with the STP Business Implementation Guide (BIG). Keep both EVTE and production Product IDs current, and ensure the BMS/Product metadata (vendor, name, version, and Product ID) in your product matches what was registered with the ATO.

Using an SSP: what DSPs must do

If you are planning to use a SSP you will need to:

  • Design your product to output STP-compliant data in a format supported by your chosen SSP.
  • Supply product details including the Software Subscriber ID if required by the SSP for inclusion in the ebMS3 header properties of the PAYEVNT message.
  • Work with your SSP to complete conformance testing, with the scope depending on whether schema enforcement and transformation are handled by you or the SSP. 

Remember that while an SSP may validate against ATO schemas and rules, they cannot modify the contents of the data you supply them.

Messaging, transmission and responses

All STP reports are transmitted using SBR ebMS3 and must meet all current ATO schemas and metadata requirements to be accepted. In production, the SSP polls for ATO responses and forwards outcomes or rejections to you and/or your clients according to the agreed service model. If the SSP returns a rejection to you, you are responsible for correcting the data and resubmitting via the SSP.

Note that an employer / registered agent may revoke their authorisation in Access Manager. Revocations are not proactively notified to the SSP and are typically detected via a message failure response. 

Output data definitions

STP data flows through two stages. STP-compliant data is the output produced your payroll software in line with the STP BIG and containing all fields required by PAYEVNT (it may be CSV, TXT, or XML). STP-conforming data is the message after the SSP applies ATO schemas and validation rules and wraps the payload in an SBR ebMS3 envelope. The business content must not be altered by the SSP, you remain responsible for accuracy and for helping end users correct validation errors.

Message structure and identifiers

Provide your SSP with the required metadata to construct a valid submission. This includes information for the SSP to populate the business document headers (including employer details, product metadata and where applicable, intermediary identifiers and software subscriber ID) and the PAYEVNT payroll event payload aligned to current specifications. Product data (BMS name, version, and Product ID) must exactly match ATO registration records and the software subscriber ID must match the value entered in Access Manager for the employer or intermediary providing the payload to the SSP Mismatches are a common cause of rejection.

Testing requirements and certification

Before production access, you must complete assessment and External Vendor Test Environment (EVTE) testing, and obtain any required certification. The scope of EVTE depends on who enforces schema and constructs the PAYEVNT message.

If your product constructs PAYEVNT and performs all schema validation, EVTE should demonstrate that the SSP reliably transports your messages, preserves required headers and metadata (including Product ID, BMS name/version, identifiers and SSID if required), and polls and forwards ATO responses.

If the SSP performs transformation and schema enforcement, EVTE testing must demonstrate correct transformation of your STP-compliant output into a conforming ebMS3-wrapped PAYEVNT message, correct population of headers and identifiers (ABN and INT/RAN where applicable), and expected outcomes for both valid and deliberatively invalid cases.

For either model, supply representative samples and mapping notes. Passing EVTE means valid cases are accepted and responses are forwarded, and invalid cases are rejected for expected reasons.

Employer onboarding steps

  1. The employer or registered agent acquires or registers to use DSP software. Employers and registered agents must meet entity validation requirements as described in the Operational Security Framework.
  2. As part of the initial onboarding process, the SSP is alerted to the new employer / registered agent registration and generates a unique Software Subscription ID (SSID) for the submitting employer / registered agent per product ID.
  3. The SSP securely passes the SSID to the employer / registered agent – this may be sent via the DSPs payroll software.
  4. The employer / registered agent creates a Cloud Nomination through Access Manager (or via ATO Call Centre) using their unique SSID.
  5. Once setup, the employer / registered agent will be able to submit STP reports using the nominated SSP with the SSID.

Registration and onboarding

Contact the Digital Partnership Office (DPO) by raising a ticket and a member of DPO will be assigned to guide you through the DSP registration process, including on-boarding and meeting security and operational requirements, in line with the Service model for DSPs.

Security and operational requirements

Your product must implement the relevant security controls required under the Operational Security Framework (OSF). This may include self assessment (or independent audit) against ISO27001, in addition to authentication controls, audit logging and others.

Key terms

Term Description
Software Subscription ID (SSID) Identifier used in the cloud authorisation model to evidence employer/registered agent consent for an SSP to transmit on their behalf. The property is included in the ebMS3 message header metadata. Not a login credential.
Product ID Identifier for the payroll product that produces STP-compliant data. Must be included in message header to the ATO and match registration.
BMS vendor/name/version Product metadata included in the message header that must match ATO registration records to avoid submission rejections.
ABN, INT, RAN Employer and intermediary identifiers used in STP submissions (including registered agent and intermediary numbers where applicable).
Access Manager ATO service where employers manage cloud software nominations and authorisations using SSIDs.
Operational Security Framework (OSF) ATO’s framework that sets security requirements for DSPs and related services.
ebMS3 Messaging standard used by the ATO for SBR transmissions.

Guidance and resources for DSPs

Guidance and resources for employers and payroll agents

For further support, raise a ticket via the DSP service desk.

Last modified date