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 manadatory fields for KYC, please refer to this file specification: Clients API

Returning payers using passkeys previously needed to authenticate twice when making a payment above their existing PayTo agreement limit.

With this improvement, payers now only authenticate with their banking app to approve the amended agreement amount. No secondary passkey authentication required.

This reduces friction, improves conversion, and aligns with user expectations.

We’ve enhanced the Pay by Bank experience to make the payment journey smoother for your customers. Instead of prompting payers to set up a passkey before they have set up an agreement to make a PayTo payment, they are now shown the option to create a passkey for future payments on the main payment landing page that asks them to enter their PayID.

This new opt-in approach keeps the payment flow seamless while still giving customers easy access to the added security and convenience of passkeys. It also makes it simpler for merchants to include the passkey option in their Azupay UX configuration with confidence.

For payment requests that accept multiple payments, users are allowed to make multiple partial payments toward a single transaction. The intended flow is that after completing a partial payment, the user should be redirected directly to the partial payment received screen, and when they choose to pay remaining amount, they should remain on the secure checkout page—even after a page refresh.

However, during testing of this flow, an unexpected redirection sequence was observed:

• After completing a partial payment , the user briefly sees an intermediate screen before being redirected to the correct ‘Partial payment received’ screen.
• When clicking ‘Pay remaining amount’, the user is redirected to the ‘Secure checkout’ page as expected, but refreshing this page causes an incorrect redirect back to the ‘Partial payment received’ screen.

This behaviour in the payment flow has now been fixed!

This feature introduces greater flexibility for merchants using Azupay’s Pay and Subscribe UX solution. Merchants can now define both the type of agreement (fixed or variable amount) and an end date for recurring PayTo agreements. This enhancement supports use cases where merchants want to establish variable payment agreements that can be managed offline while still leveraging Azupay’s checkout UX.

Previously, only open-ended, fixed-amount agreements with an initial payment were supported.

For more information about coonfiguring Pay and Subscribe for your payment request use case, please refer to this API file spec: https://developer.azupay.com.au/reference/createpayidpaymentrequest#/

And this guides documentation: https://developer.azupay.com.au/docs/3-comprehensive-integration-guide#/

We’ve enhanced the payment success screen to improve how longer PayIDs are displayed within iFrames. Previously, extended PayIDs could wrap awkwardly across lines, affecting readability. With this update, long PayIDs are now neatly truncated with an ellipsis (…) to maintain a clean layout.

Users can simply hover over the PayID to view the full identifier, ensuring clarity without compromising design or user experience.

Azupay has made the Pay By Bank UX even simpler for customers that return to you for repeat purchases.

Currently, when a returning payer attempts to make a payment that exceeds their PayTo agreement's maximum amount limit, they encounter a two-step process that creates friction in the user experience. (The customer must approve an agreement amendment to increase the maximum amount limit and then after amendment approval, the customer must click again to initiate the actual payment.)

We have updated the Pay by Bank UX to remove the two-step process and ensure our customers can make a payment with you in the easiest way possible.

To support merchants with strict account verification requirements, this enhancement ensures that payer details—such as PayID or BSB/Account—are securely prefilled and locked when creating a PayTo payment agreement via the Pay by Bank UX.

In order to prefill BSB/account number or PayID field shown to your customer, simply send in a value in suggestedPayerDetails field. Please refer to the PaymentRequest API file specification for further details on this field.

Note: you will also need to raise a ticket with Azupay service desk to enforce the guardrails of changes to payer PayID or BSB/account number details. We will make changes to your client configuration Pay by Bank setup

You can now use the Azupay Payment Request API via the Pay by Bank UX solution to collect an initial once-off payment from your customers and then setup a PayTo agreement to collect future payments in one transaction!

Collect an initial amount from your customers, while setting up a recurring PayTo agreement . Recurring PayTo agreements can be for a recurring regular amount, or a flexible PayTo agreement for future ad-hoc payments.

Key features

• Initial payment – one-time setup payment or first billing cycle amount.
• Recurring payments – collect ongoing payments via a simple API call.
• Automatic agreement creation – payment agreements are created during checkout, linking initial and recurring amounts.

For more information - refer here: and talk to your Azupay account manager or Sales representative to understand how to integrate this feature into your current payment flows

Currently, when Virtual Accounts are enabled in a client’s configuration, Payment Requests automatically have Virtual Accounts created by default.

However, as some clients have indicated they require more control over when Virtual Account BSB/account numbers are created, Azupay have introduced a new field enableVirtualAccount to specify that a payment request should have a Virtual Account number created for it, rather than applying this behaviour universally to all new payment requests.

For more information on this new feature, pelase refer to the Payment Request API file spec here: https://developer.azupay.com.au/reference/createpayidpaymentrequest#/