Merchant Frequently Asked Questions

The New Payments Platform is an industry-wide payments platform for Australia, national infrastructure for fast, flexible, data rich payments in Australia. The platform facilitates real-time clearing and settlements of payments between participating Australian financial institutions.

Please refer to Find an institution - NPPA for a list of NPP participants.

PayTo is a modern digital payment solution offering a fast, easy and secure way to pay. It gives consumers more visibility and control over their payments, and enables merchants and businesses to initiate real-time payments from their customers’ bank accounts.

To understand more about PayTo, read here: PayTo - See & manage payments from your bank account

PayID is used for instant, secure payments between bank accounts. It’s easier to remember than a BSB and account number too.

Benefits include:

• No separate apps

• A simpler way to pay

• Reduce fraud

• Low-cost

• Fast setup

• Straight through reconciliation

• Real Time Response

Yes, you can configure the setup of different types of PayIDs to suit your business’s specific use cases.

Currently Azupay support the setup of the following types of PayIDs: Once-off Dynamic PayID, Static Open PayID and Static Recycled PayID.

Please refer to this link on our Developer Portal that explains in detail the different PayID setups and how you can configure the setup to suit your business use cases:
PaymentRequest APIs

The maximum amount depends on the limits imposed by the payers financial institution. This is typically part of the account’s ‘Pay Anyone’ limit.

There is no limit imposed by Azupay or NPP.

No. End users are not required to have their own PayID. Source account PayID is not sent to us by the NPP as part of the payment data.

Yes, a QR Code is returned to the Merchant along with each request for a PayID when that Merchant is setup to use the Payment Request Checkout app. The QR Code, payment amount and PayID is displayed on the main landing page of the Payment Request app for the user to more easily make payment to the PayID.

Payment(s) made to an expired PayID will be immediately refunded to the customer.

1. Only Alphanumeric - Lowercase characters are allowed.

   Max 50 characters - Inclusive of the domain part.

   For more information on how to configure PayIDs, please refer to the Developer Portal here: PaymentRequest APIs

We recommend you use PayID branding. Please refer to PayID logo’s, Brand Standards and Terms & Conditions published by the NPPA.

PayID Guidelines

PayID Logos

Refunds for PayID payments can be initiated via API or through Azupay Dashboard. Partial refunds for part of the payment amount or full refunds for the total amount of the original payment can be made in this way.

No, payments cannot be rejected automatically via API. However once a payment is settled, the payment can be immediately be refunded by calling the refund API. Funds will never hit your external bank account in this case.

PayIDs are generated in email format only. Azupay will generate PayIDs for your business using your business domain name included as part of the PayID. For example: abcd12@yourbusinessname.c

Yes, Merchants are able to create Payment requests generating a PayID to accept payments using the ‘New Payment' function found at the top RHS of the screen on the Azupay dashboard landing page.

Merchants can initiate a PayOut transaction by calling the Make a Payment API and passing in required details to the payment object: Client Payment ID, Payee Name, BSB/Account number or PayID, Amount and Payment Description.

Azupay only rejects payments if the payment fails a validation rule based on specific configuration rules that you set as Client/merchant.

Example: if a PayID or amount is entered incorrectly.

Payments to AzupayOut recipients of non-NPP enabled banks will receive their funds via DE in 3-5 business days. 

User Acceptance Testing (UAT) is the final phase of testing performed by the end user or client to verify a software system or application is working to specifications before moving the application or connecting to the application in a production environment.

Access to our UAT environment can be requested via Azupay’s Service Desk portal:

https://azupay.atlassian.net/servicedesk/customer/portal/3.

• Signed Azupay’s NDA, Proposal or Merchant Service Agreement

• Provided necessary information about your business to complete the above.

You can give additional users access to the Azupay dashboard by logging in as an Admin user and inviting new users from your company to access the Azupay dashboard.

To access Production you must have:

• Signed our commercial Agreement

• Finalised and approved Due Diligence

• Passed UAT test processes

• Passed our CX & UX Review

  • If using one of our UX Apps this is likely to be a light touch exercise

  • If building your own custom UX this may be more involved and you should include us in early design work

• Depending on your situation additional requirements may be requested by our Risk and Compliance function.

In order to access Azupay production environment, you must complete the form called ‘Request a Live account’ through JIRA Service Desk: Request a Live Account - Azupay - JIRA Service Management (atlassian.net)

Login to the Azupay dashboard, navigate to Apps section, find the Checkout app and click the 'Checkout Enabled' toggle button to on.

• Create any type of PayID
  In the response body of the POST /v2/paymentRequest call, there will be a field called PaymentRequestStatus.checkoutUrl
  For futher details refer to this page on the Azupay Developer portal: Payment Request App - PayID checkout

• You can customise the Checkout app pages to match your brand by uploading a logo and adjusting some colours. Here's how:

1. 1. 1. Login to the Dashboard

      2. Navigate to Apps

      3. Find the Checkout App and click the Manage button

      4. Apply any changes you would like and click Save

      5. Your changes will be available immediately

• Incorrect Amount: this happens when the PaymentRequest is NOT a multiPayment and the payer pays the wrong amount. Will indicate that the full amount was refunded and ask for the correct payment to be done.

• Under payment: this happens when the PaymentRequest is multiPayment, has a paymentAmount and the payer pays less than the amount required.
  In this case the checkout app will indicate that there is a remaining balance to be paid.

• Overpayment: this also happens when the PaymentRequest is multiPayment, has a paymentAmount and the payer pays more than the amount required.
  In this case the checkout widget will indicate the payer that there was a refund for the excess and will take them to the confirmation page.
  This is considered a success scenario.

• Expired payments: the Checkout app can poll for expired payments, which means once a customer fails to make a payment within the time set by you, the payment request expires and can no longer accept payments. The PayID associated with the payment request is deregistered. You can set the payment expiry time in the paymentExpiryDatetime field in PaymentRequest.

The Checkout app main landing page will display a Cancel button if you supply a query string parameter cancelRedirectURL. The PayID associated with the payment request is deregistered when a user clicks the Cancel button.
The cancelRedirectURL must be URL encoded.

Redirecting back to your website after payment: if you supply a query string parameter called redirectURL at the end of URL supplied in PaymentRequestStatus.checkoutUrl, then we will redirect your user to this URL after the payment has been received. The redirectURL must be url encoded.

If you use the iframe version, the page will send events with changes on the Payment Request status so you can use these events to remove the iframe instead. Refer here for more details of how to implement iFrame version of the PayID Checkout app: Payment Request App - PayID checkout

You can render a stripped down version of this widget without logo or theme customisations that is more suitable for embedding inside you own web application as an HTML iframe. In this case the returned checkoutUrl will have a query parameter type=iframe. If the checkoutUrl that you received does not have it you can always append it, or request Azupay to set it up for you by default.

The daily transaction report is a daily report that provides you with transaction data for the previous 24 hour period (12am - 11:59pm).

The MT940 report is an hourly report that provides with you transactions in the previous 60 min period. The report is formatted as per the the SWIFT standard (Banking Communication Standard) for the electronic transmission of account statement data. This report is only available upon request.

Transaction data includes payments received from Payment Requests and Payment Initiations as well as payments made out by PayOut.

You can access this data by logging in to the Azupay dashboard and navigating to the 3rd option in the LHS navigation bar called Transactions. For further details refer here: Search for transaction data

You can see a list of your customers' existing PayTo agreement by logging into the Azupay dashboard navigating to the 4th option in the LHS navigation bar called Payment Agreements.

You can navigate to Apps which is the 7th option in the LHS navigation of the Azupay dashboard in order to manage your apps with Azupay. On this page you can enable apps and customise apps. For further details refer here: Managing apps

You can navigate to Settings which is the 8th option in the LHS navigation of the Azupay dashboard in order to manage your apps with Azupay. On this page you can enable apps and customise apps. For further details, refer here: Settings

You can navigate to Apps which is the 7th option in the LHS navigation of the Azupay dashboard in order to manage your Azupay dashboard settings. On this page you can manage API keys, manage the IP addresses you want to whitelist, enable your account specific TopUp PayID, set the events you want to receive Payment Request webhook events, subscribe to Thin payloads, and customise the branding that appears on your client specific Azupay dashboard.

For further details, refer here: User management

There are various Settlement options that you can choose from with the default option being set to next day settlement where your previous period 24 hours transactions are swept to your nominated bank account the next day at 8am. All settlement options are detailed here: Settlements of Funds

You can request to change how your settlement configuration by raising a production configuration change ticket through JIRA Service desk here: https://azupay.atlassian.net/servicedesk/customer/portal/3.

Azupay, provides a Purchased Payment Facility (PPF) to our clients. This results in the your settlement/float account being classified as a Customer Funds Account. Azupay will hold funds within Azupay’s Customer Funds Account in trust on your behalf.

Azupay sets a default float limit for all clients. Should you require extending this limit, Azupay will consider this based on your business needs.

You can request to change your PPF limit by raising a production configuration change ticket through JIRA Service desk here: https://azupay.atlassian.net/servicedesk/customer/portal/3.

You can request to change your settlement account details by raising a request through JIRA Service desk here: https://azupay.atlassian.net/servicedesk/customer/portal/3. You will be required to provide proof to Azupay that you own the account you are requesting to change your settlement account to.

Payments to recipients with accounts at non-NPP enabled banks will receive their funds via DE (Direct Entry) in 3-5 business days. 

No, Azupay currently does not support the settling of transactions in real time to your external settlement bank account. Please refer to Settlement options available here: Settlements of Funds

You can add a sub-merchant to your account by raising a service desk ticket: Request a Sub-merchant account - Azupay - JIRA Service Management (atlassian.net). Depending on the type of integration partner you are, you may also be eligible to onboard customers via the /clients API. Depending on your KYC arrangements, Azupay may still need to review the sub-merchant before they are enabled.

View instructions for raising a JIRA ticket for a sub-merchant account here.

All reporting is at a per client level. As a result, all sub-merchants will have dedicated reporting specific to their accounts.

Azupay does not have an upper limit for sub-merchant onboarding.

The Azupay Dashboard follows a hierarchical permission model, and requires a dashboard user be unique across all accounts. All dashboard users of the parent merchant account can drill down into a sub-merchant account from the dashboard, and will have access to all sub-merchant accounts on your account.

If a user should only have access to the specific sub-merchant’s details, ensure you invite them to the sub-merchant dashboard to enforce the proper access level.
If you have specific use cases where a user needs to access multiple sub-merchant accounts but should not have access to the parent account, use unique email addresses.

Most email providers support Plus Addressing, which allows you to have two or more email addresses registered to a single account by using + after the user portion of an email address, such as [ example.user+sub-merchant1@example.com, example.user+sub-merchant2@example.com]. See Plus Addressing in Exchange Online for more information on this approach.

Yes, a user who is added to the parent level will inherit permissions for all sub-merchants.

No they will not. Azupay uses a hierarchical access model for accounts, and users will only ever be able to access the account they are invited to, and any child accounts of that account. As unique user accounts are enforced across the platform, this means a user will only ever have access to itself and child accounts of itself. If a user needs to have access to the parent account and other sub-merchant accounts, their account should be deleted, and re-invited to the parent.

SFTP configuration is done at a per client level, and a user specified target folder can be set for each sub-merchant. We recommend creating a unique root folder for each sub-merchant if you plan to have all SFTP files pushed to the same server to cater for easily distinguishing between sub-merchants.

Sub-merchant client IDs are currently shared on account creation. If you need to retrieve your sub-merchant client ID, please lodge a service desk ticket.

Payments held by banks and other financial institutions are typically held for between 24-48 hours before being released. If a payment held is held for a certain period of time and then funds released but are sent to a PayID that has since expired, then Azupay will automatically return the funds to the original sender.

Not all payments are held, in fact the majority of payments are not held. All banks and financial institutions will hold funds from payments in different circumstances but typically they will hold first time payments to new accounts or payments of high value for security reasons.

No, Azupay does not receive any notification from the payer’s bank or financial institution that a payment to a PayID is being held. Therefore we cannot notify you, our merchant, that a payment has been held.

If a customer contacts you regarding a suspected held payment, you should advise them to contact their bank directly. You can advise them some banks may hold the funds and are usually released within 48 hours. If funds aren’t received after speaking to their bank, please have your customer gain the NPP transaction ID and provide to Azupay to begin an investigation.

As Azupay does not receive any notification for held payments, the payment will appear on the dashboard with a status of ‘waiting’ if the payment expiry time has not passed, or it will appear with a status of ‘expired’ if the payment expiry time has passed.

Payments held by banks and other financial institutions are typically held for between 24-48 hours before being released. If a payment held is held for a certain period of time and then funds released but are sent to a PayID that has since expired, then Azupay will automatically return the funds to the original sender.

The expiry time will depend on your business use case for PayID payments. As some banks or financial institutions hold funds for between 24-48 hours for PayID payments then if you make the PayID expiry time for payment requests you create shorter than this, you can expect that some payments may be automatically returned after 24-48 hours as the payments have been made to since expired PayIDs.

If you business use case suits we recommend setting an expiry time of 72 hours.

Azupay will use all commercially reasonable efforts to provide the “Covered Services” with ninety-nine point nine per cent (99.9%) availability subject to “Excluded Downtime”. The definitions of “Covered Services” and Excluded Downtime” can be found in the Service Schedule Guide that we provide to you during the client onboarding process.
At any time, if you want to view the status of any of Azupay’s platforms or applications, please go to: azupay Status . We hightly recommend that you subscribe to Azupay Status page updates.

You can register for access to Azupay Service Desk here: https://azupay.atlassian.net/servicedesk/customer/

When a bank is down, Azupay will advise our clients as soon as we are informed.
If you are expecting to receive a payment from a bank and they are down, then you will experience a delay in the settlement of your NPP fast payments. The total time that you will experience delays is likely to vary depending on the criteria for that specific outage. It is recommended that you let customer know of the outage so as to manage their expectations on when they are going to receive the cleared payment notification.

If you have made outbound payments to customers whose bank or other FI is down then Azupay will retry making these outbound payments until such time that the other bank or FI is back up and the payment is successful. It is not recommended for you the client to create another payment if the original payment is not successful as this could lead to multiple duplicate payments made out.

You can keep informed of Azupay feature releases and upcoming enhancements by referring to this page on the Azupay Developer portal:
Changelog

No, there are no chargebacks for NPP payments, as chargebacks relate to debit or credit card transactions. There is an NPP dispute process for payments that is similar to the current direct credit dispute process via Direct Entry (DE).