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

Multi-factor authentication (MFA) is now available to be enabled for user login access to the Azupay dashboard to improve account security. MFA helps protect account access by requiring a one-time code from an authenticator app, in addition to username and password. This reduces the risk of unauthorised access and supports industry best-practice security standards.

Once enabled for your company - users on their next login will be prompted to set up one time code access to the Azupay dashboard with an authenticator app (e.g. Microsoft Authenticator / Google Authenticator) on a chosen mobile device.

Azupay are planning a rollout of MFA for Azupay dashboard users, and we will be in contact with you to commence rollout plans.

You can refer to this page for more information on MFA setup for Azupay dashboard accounts: https://developer.azupay.com.au/docs/multi-factor-authentication

Outbound Payment clients can now enforce daily and per-transaction payout limits to help reduce fraud exposure. If a payout transaction would exceed your configured limits, the payment API request will be rejected (HTTP 400) so you can prevent over-limit payouts from being processed.

To enforce daily payout limits or transaction limits - contact your Azupay account manager to set payout limits for your client account.

For more information on payout limits, refer to this page:
https://developer.azupay.com.au/docs/making-payments#payout-limits

Azupay's Pay by Bank checkout UX now remembers a payer’s previously used payment method and defaults to it on future transactions. If a payer has successfully completed a payment using PayTo or PayID with any Azupay merchant in the past, and the current merchant supports PayTo payments for its customers, Azupay's Pay by Bank UX will automatically land on that same payment method when a new transaction is created.

The payment method toggle remains visible, allowing payers to easily switch methods if needed, while reducing friction and improving checkout conversion.

On the Pay by Bank payment landing page, PayIDs can vary in length depending on their format (for example, email-based PayIDs). When a PayID is long enough to require wrapping, the previous layout used caused the copy button to become misaligned, affecting visual consistency and usability.

To ensure a clean and reliable experience on the Pay by Bank payment landing page, the PayID display was updated to handle longer values more gracefully. Wrapping the PayID from the “@” symbol allows the identifier to remain readable while keeping the copy button correctly aligned, improving both presentation and ease of use for customers.

Some PayID payment requests are set up as open static PayIDs, allowing client's customers to make multiple payments without a predefined amount. Previously, this resulted in a blank amount field in the Pay by Bank checkout UX, which could be unclear for some customers.

The Pay by Bank checkout UX now displays “Pay any amount” when no fixed amount is included in the PayID payment request. This provides clearer guidance, reduces confusion, and helps customers understand that they can enter the amount they wish to pay.

Some merchants - such as subscription or membership based businesses - need the flexibility to collect a customer’s next recurring payment slightly before the current billing period officially ends. Previously, the Azupay PayTo payment initiation logic required the full period (e.g., 12 months) to pass before another payment could be processed. This caused issues for some merchants, who collect renewal fees a few days before the annual term expires.

To address this, we have enhanced our Pay & Subscribe UX solution to allow merchants to process one additional payment within the same billing period for eligible agreement types. This ensures smoother renewal experiences and removes unnecessary payment initiation failures.

To improve clarity and reduce confusion for your customers during checkout, we’ve updated the payment method selection to make PayTo and PayID payment method options easier to understand and more visually appealing for payers. Clients told us that previous labels such as “Pay by Bank (PayTo)” and “Bank Transfer (PayID)” sometimes leads to uncertainty about which option to choose.

This enhancement introduces official trademarked PayTo and PayID logos, along with simple explanatory text to help payers confidently select their preferred payment method.

Compliance changes from our banking provider made recently require sub-merchants of Distribution partners created via the Clients API to supply a minimum KYC dataset.

This update ensures Distribution partner merchants submit all required KYC fields when onboarding sub-merchants, preventing downstream creation failures.

For more information on required mandatory fields for KYC, please refer to this file specification: Clients API

Note: the requirement to ensure the correct information is supplied in the KYC object when calling the Clients API to create new sub-merchants only impacts a select number of Distribution Partners. We will advise you if you need to make any changes to your API integration in order to fulfil your compliance requirements.