Who this is for

You're building a product that needs to lodge STP Phase 2 pay events to the ATO on behalf of Australian employers — a neobank with embedded payroll, a fintech offering contractor pay, a SaaS HR product, a staffing platform, or a payroll vendor that wants to drop the ATO compliance burden. Beeswax STP is the lodgement backend; your product is the user experience.

This page covers the commercial terms, the OSF boundary, and what you get when you sign the Partner Agreement.

We use this ourselves. The main Beeswax accounting product is a Beeswax STP customer on Pattern B below — the same offering you're reading about. Beeswax customers never see the STP product surface; payroll lodgement appears inside the Beeswax app as a native feature. That's a commercial arrangement between the two businesses, and it's also how we dogfood the partner path. Everything on this page works the same way for you as it does for us.

What you get

Platform

  • Full access to the JSON API — see OpenAPI spec
  • Production + EVTE sandbox environments on the same URL (token selects)
  • Webhooks with 90-day event archive and replay API
  • M2M credential management via the web UI (you host the keystore per customer)
  • YTD accumulation and EOFY finalisation
  • Ready-to-go PAYEVNT.0004 XBRL — we track ATO schema updates, you don't
  • Rate limits scaled to the API plan (600 req/min in test, 120 req/min in live; neobank tier available)

Compliance shelter

When you lodge through Beeswax STP, the ATO's DSP audit boundary sits with us, not you. You're out of scope for:

  • The 12-control OSF self-assessment (we attest annually)
  • SBR2 transport conformance testing (we re-run after every ATO schema update)
  • The LS-ATO binary licence ($50/month, paid by us)
  • Managing the M2M keystore algorithm agility (RSA, ECDSA, post-quantum roadmap)
  • CAA (Cloud Authentication & Authorisation) integration with the ATO OAuth server

You still need your own CAA presence if your product authenticates end-users to the ATO directly (e.g. to read from MyGov). If you only need to lodge, we're sufficient.

Partner tooling

  • Sandbox seed endpoint — one call provisions a test employer + 3 employees
  • Letter of Confirmation — we provide a signed attestation of DSP status for your compliance team / insurance underwriter
  • OSF self-assessment summary — available under NDA for your security review
  • Slack channel for release notes, breaking changes, and ATO field guide updates
  • SLA: 99.9% monthly uptime on the API and AS4 transport

What it costs

Your customers pay you, you pay us. You become a reseller of the API plan. You decide the retail price; we invoice you monthly.

Metric Price
Setup $0
Per active employer per month $5 AUD
Per accepted lodgement $0.10 AUD
Support hours (first 4/month) Free
Support hours (additional) $150 AUD
Letter of Confirmation Free (annual renewal)

No minimum monthly commit for the first 12 months. After that, if volume is still under 10 active employers, we have a conversation.

Co-signed customer contracts

For larger platforms we can dual-sign the customer contract so the customer has both you and Beeswax STP on their paperwork. Pricing is the same; ask for details.

Why the per-employer and per-lodgement model

  • Per-employer covers fixed infrastructure cost (audit log retention, M2M token management, YTD storage)
  • Per-lodgement covers the marginal cost of the ATO transport (LS-ATO licence amortised, CloudWatch, SMS notifications)
  • This tracks your revenue shape, not your transaction mix — a customer with 20 employees paid weekly costs the same as one paid monthly

If your business model is "pay-per-employee" we can invert the per-lodgement dollar into a per-employee-per-month charge. Same maths, different labels.

The OSF boundary (what stays with you)

You are still on the hook for:

  • Identity — the ATO requires MFA on every user who can create or lodge pay events. If your product exposes lodgement to end-users, you enforce MFA on your side. (Our API tokens are machine credentials, not end-user identity.)
  • Personnel security — your engineers need appropriate access controls to the keys/credentials you use to call us
  • Notifiable Data Breach response — if your system leaks customer data before it reaches us, that's your notification obligation
  • Customer contracts — the employer is contracting with you; we're your subprocessor

We document the split clearly in the Partner Agreement and provide a responsibility matrix on request.

The technical onboarding path

  1. Signup — create a Beeswax STP account, upgrade to the API plan
  2. Sandbox — POST /api/v1/sandbox/seed gives you a test employer + employees
  3. Test lodgement — cycle through pay event creation, submission, and webhook delivery against EVTE
  4. Go-live readiness check — we schedule a 30-minute call, run through:
    • Your TFN handling on your side (per API → TFN handling)
    • Your webhook retry/dead-letter handling
    • Your customer onboarding flow for M2M credential upload
  5. Production token issue — we flip the live token on, you test one real lodgement, you go
  6. Partner Slack — you're added to the release-notes channel

Median time from signup to first live lodgement for partners: 9 days. Fastest: 2 days.

Provisioning customer employers

There are two patterns:

Pattern A — Direct signup

Customer signs up to Beeswax STP in the web UI, uploads their M2M keystore, shares the employer ID with your integration. You call the API against their employer. Billing is on the customer; you add a margin by up-selling other services.

Pattern B — White-labelled provisioning

You POST /api/v1/employers to create the employer under a platform-level account, upload the keystore via the API, and handle all UX yourself. The customer never sees Beeswax STP. Billing is on you; you invoice the customer at your retail price.

Pattern B is the neobank default. Pattern A works well for accounting software pairing with an existing customer base.

The question of which account pays for the API plan when the customer is also a Beeswax STP standalone user is handled by pricing pass-through — see Commercial terms above.

What we're building next (partner-visible)

  • Dynamic Client Registration with the ATO OAuth server for production CAA
  • Payday Super (QE) support — already in the data model, on by default from 1 July 2026
  • OAuth 2.0 handshake for partners who need per-end-user delegation (currently Bearer-only)
  • Read-only event stream (gRPC) for partners at >10 rps sustained volume

If any of those matter for your go-live, let us know and we'll prioritise accordingly.

Contact

  • Partnerships: partners@stp.beeswaxapp.com
  • Security / DPO letter: security@stp.beeswaxapp.com
  • Slack invite: request via partnerships email

Partner Agreement, DPA, and the DSP Letter of Confirmation are provided after an initial call. The agreement is AU-law (NSW), arbitration-default, with a standard data-processing addendum compatible with most fintech vendor review programmes.