Introduction

Azupay's 1-Click Checkout App has been designed to optimise repeat payers' experiences using PayTo as the main payment method.

While PayTo based payments offer great benefits, an optimum UX is important to help your payers complete their journeys successfully. Based on our user research and understanding of payment behaviours, we have designed and tested the App to maximise conversion rate of payments and reduce the integration effort required by you.

The 1-Click Checkout App involves you sending Azupay a PaymentRequest API call, you specifying you would like to use the 1-Click Checkout App, and your system listening for updates from our webhooks. Our 1-Click Checkout App has the following features:

Is fully screen responsive
Allows users to provide their PayID so payment can be completed using PayTo, or fallback to PayID where users can make a push payment from their banking app or online banking
Available as an embedded iFrame
Surfaces minimal content to users to reduce cognitive overload that leads to dropouts during the payment experience
Guides the user to setup a PayTo agreement for future payments with your business
Automatically detects users who subsequently return for a faster checkout experience, using the existing authorised PayTo agreement.

How do I use it?

Call the PaymentRequest API
You can configure your client configuration to always use the 1-click Checkout App (please raise a help desk ticket) or specify in each API call via the POST variant field which App you would like your payer to use.
In the response body of the POST /v2/paymentRequest call, there will be a field called PaymentRequestStatus.checkoutUrl
Present this URL to your customer using any means appropriate, we have optimised for iFrame delivery:
1. Embed into an iframe element and include it in your website. To do this make sure the checkoutUrl has a query parameter type=iframe
2. Once the payment is completed the payer will see a confirmation in our iFrame and you can redirect to your own success screen
Return to the same page (refresh) and checkout again. The checkout process will now utilise the existing Payment Agreement to expedite the checkout process.

End User Payment Flow

Making payment with PayTo

User is presented with the 1-click Checkout app landing page and is prompted to provide their PayID
Azupay performs pre-requisite checks to ensure the user is eligible to continue with the payment
User is asked to authenticate with an OTP (one-time passcode)
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
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 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	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 during a 1 click Checkout experience) is now defaulted to: - $200 maximum amount - Ad-hoc frequency - Variable agreement - End date set to T+2 years
iFrame / Full Frame	URL type	iFrame embeds the App inside your page. If iFrame is not set the App will surface in a pop-up page with white label branding. The payment description is only shown to end customers underneath the QR code in the full frame version
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
Variant	UX app type	For merchants who want to serve different Azupay UX Apps for different brands or channels, they can choose to specify which App by using the Variant field in the Payment Request API (example: 'PayID' or '1Click') Note that a default variant value can be set with a merchants profile instead of selecting this at the API l

Example:
https://pay-stg.azupay.com.au/v3/checkout/QVpVUEFZRGVtb0NsaWVudC8xODBmNGE5ZGYwZGRmOTNiZTA0ZTQ0ODc5NTE3ZjczYi9BenVwYXkgRGVtbyBDbGllbnQvMUNsaWNrL2FIUjBjSE02THk5d1lYa3RjM1JuTG1GNmRYQmhlUzVqYjIwdVlYVXZZWE56WlhSekwyUTJaak5tTlRsaE9XTTVaamcxWkRZMk56SmhOMlEzTldZMVpEVm1Oekl6TG5CdVp3PT0=?token=fd511dd497a0e225bb0e45cca784838f9a38ee7d2426ee50abed7c3f4358b6960a2d24d0f&redirectURL=https%3A%2F%2Fwww.bing.com%3Fmyparam%3Dsomething&cancelRedirectURL=https%3A%2F%2Fwww.google.com

This URL is provded by the CheckoutURL response in the Payment Request API. 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 1-Click Checkout app 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.