We’ve updated PayID validation rules so Azupay APIs can now accept longer PayID values where required, instead of applying the previous 50-character restriction. This change supports PayIDs up to 140 characters for the relevant EMAIL and ORG validation flows, and also updates suggested payer details field validation to align with the new limits. This reduces unnecessary validation failures for valid PayIDs and improves compatibility across Enquiry, Payment, Payment Request APIs where PayID is passed in.

For more detailed information, select the API file reference you want to check on this page: https://developer.azupay.com.au/reference/createpayidpaymentrequest

We’ve added a daily disbursement report for clients using Azupay’s batch solution for outbound payments. Generated as a CSV file for the previous business day, the report helps clients reconcile disbursement activity and review payment outcomes across their outbound payment batch files.

The report includes key transaction details such as payment status, completion timestamps, failure and return information, transaction identifiers, and whether a payment was sent via Direct Entry. It also supports header-only files when there are no transactions for the reporting period, giving clients a more consistent and efficient way to monitor outbound payment activity.

For more informarion on Azupay batch solutions - please refer to:
https://developer.azupay.com.au/docs/connectivity-guide

We’ve improved batch file delivery for clients using Azupay’s batch app by supporting a separate SFTP destination for generated summary response files. This means clients can continue uploading batch files to Azupay as usual, while Azupay can send generated response files to a different configured SFTP location when needed.

If a separate destination is configured, Azupay will deliver RECEIVED, PROCESSED and REJECTED summary response files there. If not, files will continue to be delivered using the existing SFTP configuration. This gives clients more flexibility in how batch file outputs are received, without changing the core batch submission flow.

For more information on Azupay's batch processing solution - please refer to the below guides: https://developer.azupay.com.au/docs/connectivity-guide

We’ve updated the Pay by Bank help content and onscreen guidance to make it clearer for customers how to pay to a PayID when completing their payment in their banking app or online banking. The guidance now more explicitly explains that customers need to choose PayID type - email address when making the payment, rather than selecting other available PayID options such as Org ID or ABN. This change benefits payers by giving them clearer, more practical instructions at the point of payment, helping them choose the correct PayID type and avoid confusion in their banking app.

Azupay have improved the Pay by Bank UX experience by automatically removing common formatting characters from BSB, account number, and PayID inputs before validation. This means customers can enter details in more familiar formats, such as adding spaces or dashes, without being blocked unnecessarily. We’ve also added logic to convert PayIDs entered with +61 into the expected local mobile format.

This benefits payers by making the payment experience more intuitive. It also helps clients and internal teams by reducing avoidable validation errors, lowering payment friction, and helping more customers complete their payment successfully.

We’ve introduced support for .dat batch files so clients can submit bulk disbursement instructions via SFTP for automated payments processing. Our solution validates the file structure, validates individual records, and generates status response files to show whether the file has been received, processed, or rejected.

This is a meaningful improvement for our clients who need to pay refunds, rebates, or compensation to customers at scale. It creates a more efficient and structured way to manage bulk outbound payments, while reducing reliance on slower and more manual disbursement methods.

We’ve introduced configurable end date behaviour for once-off PayTo agreements in the Pay By Bank UX, giving merchants greater control over how agreements are displayed to customers in their banking app.

By default, once-off PayTo agreements will now be created with 'end date' of the agreement = 'start date'.

This ensures agreements are presented as true “once-off” arrangements in banking apps and online banking, improving payer confidence at the approval step.

Merchants can override this default behaviour via configuration, allowing a custom agreement duration where required by setting agreement duration in days. (Please raise an Azupay service desk ticket if you would like to request a different agreement duration configuration for once-off PayTo agreements)

We’ve added a new Description field in Test Bank when making payments via BSB & Account Number, allowing clients to better simulate real banking experiences and test reconciliation flows.

When navigating to the Pay with BSB tab in Test Bank, users can now enter:

• BSB
• Account Number
• Description

Where webhooks are configured, the submitted description value is now included in the payment webhook payload, enabling end-to-end reconciliation testing

We’ve updated the payment confirmation screen on the Pay by Bank UX to proactively inform payers when an incorrect PayID payment is automatically returned and may take up to ~5 minutes to appear back in their account

This change applies to payments that are auto-returned by Azupay and does not related to merchant-initiated refunds).

This new refund message is displayed when:

• A single-use payment request receives an underpayment or overpayment and is auto-returned
• A multi-payment request receives an overpayment and the excess amount is auto-returned

To ensure more consistent request validation (and clearer error handling), we’ve updated the Account Check API input validation rules for the accountName field

Requests will now be rejected with HTTP 400 (Bad Request) when accountName is:

• a single character (e.g. "a")
• blank / whitespace-only (e.g. " ")
• includes leading or trailing spaces (e.g. " ddd ")

Where validation fails, the response includes a structured failure reason (including a failure code) to make it easier to identify the exact issue and handle errors predictably.

Refer to this file specification for further details: https://developer.azupay.com.au/reference/post_accountcheck