Client Post Incident Advice
The incident we experienced last night impacted the PayID registration process for our paymentRequest product between 7pm and 9pm AEST, and some PayID registrations during this incident were delayed.
If you use our paymentRequest product and have a client who pays you via a payID, they may have been unable to complete a payment successfully against the PayID during this period.
Azupay successfully registered all PayIDs by 10PM AEST after the incident window, with the majority of impacted paymentRequests being registered by 9:20PM AEST.
You may need to contact customers who attempted payments during this period and request they re-attempt the payment if the paymentRequest is still in a WAITING status and you are expecting they should have paid by now.
As the PayIDs were not registered, the customer would have not been able to successfully look up the PayID in their banking portal, and no payment would have been attempted.
You should contact impacted clients, let them know the PayID is now available for payment, and they should re-attempt it.
If end customers have any issues making payment to the registered PayID, please raise a request with our service desk at https://azupay.atlassian.net/servicedesk/customer/portal/3 for support.
Additional information on the root cause is still pending.
We are awaiting a Post Incident Review from our upstream impacted connected institute, which should be supplied on the 1st of May. We will provide further details once this has been shared.
23/04/2026: Incident Summary Provided by Banking Partner
Our banking partner has provided an initial incident summary for this incident.
A more detailed Post Incident Review is still pending.
The issue was caused by an unexpected problem during scheduled maintenance at one of our partner’s data centres during maintenance by one of their vendors. While the activity was intended to be isolated and low risk, it inadvertently disrupted connectivity between PayID services and their respective databases. The vendor subsequently confirmed that the disruption was due to a network protocol blocking communication between these services.
To resume services, our Parter failed over all traffic to an alternate data centre link,, allowing service restoration.
We are working with our banking partner to improve incident response processes with their teams to minimise impact
06/05/2026
We have been provided a PIR by our partner and can provide additional information relating to the cause of this incident. The ultimate cause of the incident was a networking misconfiguration that resulted in a service interruption. Steps have been taken to ensure this configuration iscorrectly set going forward to prevent a recurrence
Details:
During a planned maintenance window at our payment infrastructure provider's data centres, an unexpected network configuration issue disrupted PayID service connectivity. Although the maintenance was intended to be isolated and low risk, a misconfiguration caused part of the internal administration network to incorrectly classify an internal connection as external. As a protective measure, the system automatically disabled several network paths, resulting in a service interruption.
To restore services, affected systems were redirected to an alternative data centre. PayID services were restored earlier in the evening, with full restoration of all payment services later that night. Once the underlying configuration was corrected and the connection was recognised appropriately, normal network communication resumed and all services stabilised.
Steps have been taken to ensure the configuration is correctly set going forward to prevent a recurrence. No further issues have been observed since restoration.