We offer different UX Apps for different payment needs. Each UX App is integrated in different ways so it is important you choose the right App for your needs when you start your build.

Our UX Apps are:

• Payment Request App - 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
• Automated Payments App - 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

👍

Watch this space... there are more Apps to come

📘

Or custom build your own UX

If none of our Apps 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 App

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 vs. 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 this App 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 Variants of the Payment Request App.

PayID Checkout Variant

Choose this variant 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 PayID Checkout 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 Payment Request App - PayID checkout for more detailed information.

1-click Variant

Choose this variant 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 variant is that your regular customers can complete repeat payments with just one click (or less!) while you get the benefit of irrefutable funds that comes with payer bank authenticated payments.

🚧

In practice a literal 1 click payment with zero chargeback risk is perhaps an aspirational goal, in most cases we find clients (and payers) want extra steps to ensure strong authentication of the payer - but the goal remains and the technical feasibility is there

How 1-click works

When this variant is invoked the payer is invited to provide their own PayID and we send a PayTo Agreement to your payer. We concurrently setup an authentication method of our own 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 v2 Variant above) and enjoy a full control experience.

The benefit of 1-click comes in return payment journeys. 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 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 1-click Variant.

Review your Agreement with Azupay for more details.

See Payment Request App - 1-click checkout for more detailed information.

Automated Payments App

🚧

Coming soon...

If you're itching to be a market leader we're with you already - you can build your own PayTo-based payment experiences directly on our existing PayTo APIs already in market. See Guide to the Automatic Payment APIs

Use this when you want your customer to give you permission to collect payments from their bank account automatically in the background according to the terms of agreements you have with them.
This is what PayTo was designed for, but it can be used in many more scenarios than Direct Debit ever could be and offers a far better experience for you and your customers.

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

👍

Interested? Check back here or reach out to hear more...