Once-off payment journey
Use the Payment Request integration with our Pay by Bank UX solution (once-off payment journey) to give payers who want to make a once-off, single use payment utilising a highly secure account-to account payment experience with PayID and PayTo
End User Payment Flow
Making a payment with PayTo
-
User is presented with the Pay by Bank landing page and is prompted to provide their PayID (their PayID can be in the form of a mobile phone number or email address)
-
Azupay performs pre-requisite checks to ensure the user is eligible to continue with the payment
-
If the user is eligible, a PayTo agreement is generated and the details are sent to the user's online banking platform
-
User reviews these details and approves the agreement in their mobile banking app or online banking
-
Payment is initiated and the transaction is completed
-
User is shown success screen (in iFrame) or redirected back to merchant success confirmation page (full frame version)
Making a payment with PayID
- If user clicks on button 'Pay to our PayID', then they will be shown the PayID fallback option screen to make a payment to the merchant's generated PayID unique to the specific payment request
- User clicks on copy button to copy PayID or scans QR code to transfer PayID details to a mobile device to make payment through mobile banking or online banking
- Upon successful payment, user is shown success screen (in iFrame) or redirected back to merchant success confirmation page (full frame version)
Key Configurations / Variants
The payment experience can be configured to suit the needs of your use case. In the table below configurations may be set by URL parameters, values in the API calls or set in your specific client configuration.
Experience | Configuration | Amount | Comments |
---|---|---|---|
Duration allowed for payment | Payment agreement expiry time | Once a payment agreement has expired the payer is unable to approve the agreement in order for a payment to be taken from the account. Use a short expiry time if payment must be confirmed quickly, e.g. a travel booking must be paid before reserved tickets are released or repriced. If no Expiry Time is set the payment agreement can continue to receive payment initiations against the agreement indefinitely. | |
Maximum agreement amount | Client configuration | The default configurations of the PayTo agreement (created when using the Pay by Bank UX solution) is now defaulted to: - $200 maximum amount - Ad-hoc frequency - Variable agreement - End date set to T+2 years | |
Redirect | redirectURL | When the payer journey has completed (either following success or terminating at some unhappy path ending) the payer will be returned to this URL | |
Cancel | cancelRedirectURL | If a cancelRedirectURL is provided the payer sees a cancel button. Hitting the cancel button will send the payer to the specified URL and will deregister the PayID preventing anyone accidentally paying to this PayID |
This URL is provided by the CheckoutURL response in the Payment Request API. In this example, a redirectURL has been added to take you to bing.com upon successful payment or to google.com upon cancellation by customer.
Exception Handling
The Pay by Bank UX solution includes exception handling so that merchants do not need to manage these complexities.
Should merchants want to simulate exception scenarios, they are detailed here for the UAT environment. There are particular PayIDs which trigger exception scenarios such as insufficient funds.
Exception scenarios handled within the App:
Ineligible PayID

Payment cannot be processed

Agreement not approved in time

Insufficient funds

Incorrect amount paid (PayID fallback option)

How do I use it?
- Call the PaymentRequest API using the
variant
field that corresponds to the UX you want to create. - In the response body of the
POST /v1/paymentRequest
call, there will be a field calledPaymentRequestStatus.checkoutUrl
- Present this URL to your customer using any means appropriate, you could:
- Surface in a new pop-out window
- Send the link via an email
- Send the link via an SMS
- Embed it into a QR code
- Once the payment is completed the payer will see a confirmation

Key Configurations
The payment experience can be configured to suit the needs of your use case. In the table below configurations may be set by URL parameters, values in the API calls or set in your specific client configuration.
Experience | Configuration | Amount | Comments |
---|---|---|---|
Duration allowed for payment | Expiry Time | Once a PayID has expired the payer is unable to initiate payment. Use a short expiry time if payment must be confirmed quickly, e.g. a travel booking must be paid before reserved tickets are released or repriced. If no expiry is provided a default expiry configured for you client will be used instead. | |
Exact Match | Multipayment default to FALSE | Set Amount | Exact Match allows a single payment exactly matching a set target amount only. Use this to ensure perfect instant reconciliation for every payment to your transaction. With this setting you will have zero manual reconciliation, zero unallocated funds and zero underpaid invoices. Multipayment is not set to TRUE and an Amount must be set. |
Refund Overpayments | Multipayment = TRUE | Set Amount | Refund Overpayments will receive any amounts but if the total of all payments made to this PayID exceeds the total target amount the surplus will be instantly returned to the payer. |
Any Amount | Multipayment = TRUE | No Set Amount | Any accepts all payment amounts |
Redirect | redirectURL | When the payer journey has completed (either following success or terminating at some unhappy path ending) the payer will be returned to this URL | |
Cancel | cancelRedirectURL | If a cancelRedirectURL is provided the payer sees a cancel button. Hitting the cancel button will send the payer to the specified URL and will deregister the PayID preventing anyone accidentally paying to this PayID | |
Custom messaging | Client configuration | You can request custom messaging to be displayed at the top of the payment landing page by raising a help desk ticket. The custom message will be displayed underneath the progress stepper at the top of the payment page. |
There are other Configurations explained elsewhere in these Guides and the API Reference. The list above is the subset having the most impact on overall experience and should be considered before you start your implementation journey.
Example Configurations
Dynamic PayID
This is a short-lived PayID that only accepts a single payment and is uniquely generated in real time as required. Once a payment for the exact amount of the PayID is made by a payer, the PayID is deregistered and no further payments to the PayID can be made.
This PayID setup is most suited to your customers making a one-off payment for goods or services and you want perfect instant match of payment to the purchase.
Sounds technical but its the easiest configuration
This was the original Azupay product so just set your amount and off you go...
Configure like this:
- Set amount for each transaction in the API call
- Multipayment=FALSE and do NOT enter a value for PayID string
- Other configurations (e.g. expiry time) can be varied as suits your specific needs
Open Static PayID
This is an enduring PayID that accepts multiple payments of any amount at any time.
This PayID setup is most suited to account based payments where you want to know which of your customers have sent you money but you don't need specific amounts at specific times. Simply create a single Open Static PayID for each of your customers. Examples include topping up digital wallets or adding credit to a customer account.
Hint: Encourage your customers to save their PayID in their banking app
For faster repeat payments they can use the same PayID each time
Configure like this:
- Multipayment = TRUE
- Expiry Time either empty or a far future date (e.g. 1 year away)
- Optional: set PayID string to something short but meaningful to your customer, e.g. their initials plus 4 random digits @ your domain.
- Other configurations (e.g. URL Type) can be varied as suits your specific needs
Static Recycled PayID
This is a recurring PayID that accepts specified amounts periodically. When the specified amount is received the PayID is deregistered (preventing further payments to it), until you make another Payment Request using the same PayID at which point it becomes available again to be paid to with a new target amount.
This PayID setup is most suited to customers with periodic or usage-based recurring billing. Simply make a Payment Request with Amount and PayID string specified, ensure you use the same PayID string for each customer every time. Your customer will pay to the same PayID every time they receive a bill and each time they do so they will get a description of the amount owing for that specific bill and there will be controls to ensure they don't overpay or accidentally pay it twice. Improve customer satisfaction and reduce contact centre calls!
Hint: Encourage your customers to save their PayID in their banking app
For faster repeat payments they can use the same PayID each time
Configure like this:
- Multipayment = TRUE
- Expiry Time either empty or a far future date (e.g. 1 year away)
- Set Amount
- Set a PayID string for each of your customers and keep a record of it
- Optional: set PayID string to something short but meaningful to your customer, e.g. their initials plus 4 random digits @ your domain
- Important: every time you call the Payment Request for a specific customer you must always use the same PayID string for that customer
Example match type experiences
There are various scenarios managed by the Pay by Bank UX solution.
Specific amount requested
This happens when the PaymentRequest
is NOT a multiPayment
and amount value set when creating the payment request

Any amount accepted
This happens when the PaymentRequest
is a multiPayment
and there is no amount value set when creating the payment request

Incorrect amount paid
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 widget will indicate that there is a remaining balance to be paid.

Overpayment
This 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 Pay by Bank UX solution polls 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
.
Redirect 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. For example:
https://pay.azupay.com.au/v3/checkout/ZDk2YzkxYTUyYjYzYTIwMzk3?redirectURL=https%3A%2F%2Fwww.mywebsite.com%3Fmyparam%3Dsomething
The payer will be redirected to https://www.mywebsite.com?myparam=something
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. Keep reading for more information about how to use the events generated by the iFrame.
Cancel redirect
The 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 Cancel.
The cancelRedirectURL must be url encoded. For example:
When the user clicks the Cancel button, then we will redirect your user to this URL (i.e. https://www.mywebsite.com?page=home
Updated 13 days ago