We offer different UX payment solutions for different payment needs. Our UX solutions may be integrated in different ways so it is important you choose the right approach for your needs when you start your build.

Our UX Apps use cases are:

• Payment Request solutions - Pay by Bank - you want your customers to send payment to you; this might be to buy a product, pay for a service, top up a wallet or other similar payment experience. One integration to our PaymentRequest API allows you to choose from multiple different Payment Request solutions to suit the experience you want for your customers.
• Subscriptions solution - you want your customers to set up an arrangement allowing you to automatically collect payments from them over time; this might be to pay for a subscription every month, to allow you to collect usage based fees every quarter or other similar recurring background payments. Simply integrate once to our PaymentAgreement and PaymentInitiation APIs and make use of our Automated Payments Apps coming soon.

📘

Or custom build your own UX

If none of our Payment UX solutions suit your needs you can build your own payment user experience using our APIs. Your user experience will need to pass our UX review before entering Production.

Payment Request solutions

Use this when your customer is interacting with you (e.g. on your e-commerce checkout, at your POS, reviewing and paying an invoice of yours, topping up a wallet) and your customer takes action to make a payment to you.

We are looking for your customers' payment experiences to be as frictionless as possible while giving them the mix of control and convenience that works for them. In the background configure the payments to automate your accounts receivable and obtain the most process efficiency benefits for yourself as well as reducing fraud risk and payment fees.

To use these Payment UX solutions integrate to our PaymentRequest API, embed the returned url in an iFrame or pop-out window and listen for webhook updates.

Currently we offer two Payment Request solutions and you choose which of these you want by default, or you can choose which solution you want for each transaction via an optional field in the API.

Pay by Bank (PayID only)

Choose this UX solution to give your customers full sense of control and ensure ubiquitous availability for anyone with an Australian bank account. Your customers can choose when they pay, how much they pay and which account they pay from. You configure whether or not you require perfectly matching payments, types of PayID that are created and other aspects of the experience.

How Pay by Bank (PayID only) works

We register a PayID for your customers to pay to and our UX guides your customer through sending payment, displays success or error messages, sends transaction status updates to you via webhooks and redirects back to you at the end of the experience.

See PayID - use cases & configurations for more detailed information.

Pay by Bank (with PayTo and PayID)

Choose this UX solution to give your customers choice on a scale between control and convenience. This variant allows your customer to use PayTo for a more streamlined experience or PayID for them to be in total control. Configurations you set fine tune payer experience in convenience and fraud risk controls and other aspects of the payment journey. The goal of this UX solution is that your regular customers can complete repeat payments with few clicks while you get the benefit of irrefutable funds that comes with payer bank authenticated payments.

How pay by Bank (with PayTo and PayID) works

When this UX solution is invoked the payer is invited to enter their own PayID and we send a PayTo Agreement to your payer. We concurrently setup an internal authentication method with that payer. On the first payment journey your payer will need to approve the PayTo Agreement in their banking app after which we will immediately collect the payment you requested. We will guide your payer through the experience, display success or error messages, send transaction status updates to you via webhooks and redirect back to you at the end of the experience.

If your payer is not yet able to use PayTo, or is uncomfortable entering into a PayTo Agreement with you they can choose to invoke our PayID payment experience (see PayID Checkout App above) and enjoy a full control experience.

The benefit of this UX solution is revealed in when returning users visit to make repeat payments. When a payer returns for a subsequent payment the payer authentication method set up on initial journey indicates that the person making this payment is the person who was previously able to approve the PayTo Agreement in their banking app. This authentication can give you extra comfort that the person making this payment is the person authorised to make payments out of the bank account without them leaving your checkout experience and entering their banking app every time.

🚧

It is important you understand that when initiating payments against an active PayTo Agreement you remain liable for ensuring the person instructing that payment is the person authorised to use the bank account. This does not change when using the Pay by Bank UX solution.

Review your Agreement with Azupay for more details.

See Pay by Bank with PayTo and PayID for more detailed information.

Subscriptions

Azupay’s PayTo Subscription Solution leverages real-time, account-to-account payments through the New Payments Platform (NPP), ensuring your customers enjoy a seamless, secure, and reliable payment experience.

This solution offers businesses a direct debit, card capture and card-on-file alternative via PayTo payment rails.

Setting up and managing PayTo Agreements is different (and better) for you and your customers than anything you've done before. So use The Azupay Subscriptions solution to reduce your new tech build, work with your existing platforms and keep it delightful and intuitive for your customers.