Asking a customer to provide a one-time-passcode (OTP) in the Pay by Bank payments journey adds friction to the experience. In the Pay by Bank "single payment" journey, it is redundant given that the customer will always be asked to approve the PayTo agreement in their banking app or online banking. We have made the safe assumption that authentication to gain access to a customer’s banking app or online banking is sufficient and that they indeed do own the account that payment is being taken from.

For this feature, we have removed the need to provide an OTP, instead once the customer provides their PayID or BSB/account details to create a PayTo agreement, they are then asked to approve the agreement in their banking app or online banking.

Inbound payments to payment requests with BSB/account number specified (“Virtual accounts” payment request feature) have historically not contained any payer account information. Azupay have made the change to include payer name and BSB/account number information with the transaction information sent through so that clients can retrieve this information as required (in the case of fraud etc.)

To make the customer experience for 1-click Checkout more streamlined, when a customer has authorised a PayTo agreement created through 1-click Checkout but the payment initiation fails, an error message will be displayed letting the customer know that the payment failed due to insufficient funds. A link to 'Change PayID” will be shown within the error message and clicking this link will allow the customer to enter in another PayID for which they can create another PayTo agreement against.

When your customer clicks on the 'Cancel' button on the 1-click Checkout app payment landing page, the PayTo agreement created for that customer will be cancelled before any redirection occurs back to your website, so that no payment is inadvertently taken.

Clients who have outbound payments settled via DE, and opt in for this new custom field in their daily transaction report will now see a new column in their daily transaction report called ‘Sent via DE’. If this column in populated with ‘true’ for that row then the transaction was settled via DE instead of by NPP outbound payment methods.

Given that you know a customer's payer name BSB/ account number information, when you provide this to us in the Payment Agreement Request API then Azupay will pre-fill this information in the Subscriptions App main landing page for the customer. This leads to a more seamless payment experience for your customers setting up an agreement with you using Subscriptions app!

Azupay have enhanced features offered in the recently launched Subscriptions app to offer merchants the ability to craft bespoke PayTo agreements.

Here's is what merchants can now tailor PayTo agreements for their customer:

• Frequency
• Start date
• End date
• Description

Additionally, we've ensured that validation has been enhanced when PayTo agreements are created. No more formatting mishaps! We’ve added:

• Amount Check: Ensures amounts have the correct format (like two decimal places).
• End dates can't precede start dates.
• Start dates must be today or later.
• Error Feedback: If inputs go awry, clear error messages will guide you back on track.

With these new features, setting up recurring payments is smoother than ever, offering a customised and streamlined experience for everyone involved.

Previously, when we tried to do refunds for merchant or partner accounts that had insufficient balance, our system retried multiple times to check if sufficient balance was available for the operation and continued to retry till the account had sufficient balance.

But now, we have updated our core system to send an error when there is insufficient balance and will not retry the refund. Our clients will see the 400 status (Bad Request) with a failure code “ERR0.11 – Insufficient Balance”.

When creating sub-merchants via the Clients API, partners can now specify an optional 'Trading Name'.
This will help differentiate sub merchants with the same legal entity name, but may operate multiple stores or have different brands.
The 'tradingName' field will also be displayed on the dashboard, making it a breeze for partners to identify and manage different sub merchants.

For Azupay merchants that don’t have an NPP-enabled account for their sweep settlement, they can have scheduled sweeps settled in to their account via Direct Entry. This is not available by default, but the Azupay support team can set it up if our onboarded merchants or partners opt-in for this feature