Admiin API docs

ATO payments

Create a hosted payment to the ATO, check its status and match it back to your own records.

Before you begin

You need an access token and your partner id. See Authentication and first request.

Only server integrations using the client-credentials flow can create a payment. X-Partner-Id is required and names the partner that owns the payment.

This is not customer billing. Payments move money to the ATO. To charge your own customers for verification and KYB work, see Customer billing.

Create a payment

POST /v1/payments
X-Partner-Id: YOUR_PARTNER_ID
Content-Type: application/json

{
  "amount": 125000,
  "prn": "1234567890123",
  "payerDisplayName": "Acme Pty Ltd",
  "paymentFor": "BAS Jul-Sep 2026"
}

amount is in cents and prn is the ATO payment reference number. Both are required. contactId lets a contact's saved card be used, and redirectUrl returns the payer to your platform when they finish.

Creates a hosted payment for your partner account. The response carries the payment and the hosted URL your customer completes it on.

Check a payment

GET /v1/payments/{id}
X-Partner-Id: YOUR_PARTNER_ID

The {id} is a payment id only. Guest tokens are not accepted on this route. One in the {id} slot resolves to 404.

The partner id must match both the payment owner and the OAuth client you used to fetch the token.

List payments

GET /v1/payments?limit=20&from=0
X-Partner-Id: YOUR_PARTNER_ID

Returns the payments visible to the authenticated caller. Partner members receive only their own organisation's payments.

limit is 1 to 100 and defaults to 20. from is an offset. Pass from + limit from the previous response to fetch the next page. status optionally filters the result.

Payment webhooks

Subscribe to the payment event category to be told when a payment changes state, rather than polling. See Webhooks for signature validation, retries and handling the same event twice.

Notification history for a payment

GET /v1/channel-payments/{id}/webhook-notifications
X-Partner-Id: YOUR_PARTNER_ID

Returns the delivery attempts made to your webhook endpoints for one payment. You can only access notifications for your own payments.

This route keeps the older channel-payments prefix on purpose. In the API's own words: "The nested webhook-notifications path is kept under the legacy channel-payments prefix and is not part of the W8 prefix-drop, there is no canonical alias." So use this path even though the payment itself lives under /v1/payments.

The legacy channel-payments surface

/v1/channel-payments still exists and still works, but it is the legacy surface. Use /v1/payments for creating, reading and listing payments in any new integration.

The one exception is the notification history route above, which has no equivalent under the new prefix.