1-click Checkout App

Use the Payment Request integration with our 1-click Checkout App to give repeat payers a highly secure and low friction experience

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?

  1. Call the PaymentRequest API
  2. 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.
  3. In the response body of the POST /v2/paymentRequest call, there will be a field called PaymentRequestStatus.checkoutUrl
  4. 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
  5. 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

  1. User is presented with the 1-click Checkout App and is prompted to provide their PayID
  2. Azupay performs pre-requisite checks to ensure the user is eligible to continue with the payment
  3. If the user is eligible, a PayTo agreement is generated and the details are sent to the user's online banking platform
  4. User reviews these details and approves the agreement
  5. Authentication method is created to confirm user when they return
  6. Payment is initiated and the transaction is completed

When the payer returns to pay again the end user flow is easier:

  1. 1-click Checkout App recognises a returning payer and suggests the payment details used previously
  2. User completes authentication created on first successful payment
  3. Payment is initiated and transaction is completed

Key Configurations / Variants

  1. Merchant Configuration - choosing a default App

    1. A merchant can raise a tech support ticket to select which default App is presented to payers. This configuration means all Payment Request across all channels will use the same App (Azupay offers multiple UX Apps) unless over-ridden during individual API calls.
    2. Merchants already using the PayID Checkout App can switch and upgrade to the 1-Click Checkout App through a configuration change on Azupay's side.
  2. Payment Request API - Specifying a Variant in each API call

    1. 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.

      Note that a default variant value can be set with a merchants profile instead of selecting this at the API level.

      VariantDescription
      PayIDUses the PayID Checkout App - generates a PayID for the merchant and allows an end user to send payment from their bank account to complete the transaction.
      1ClickUses the 1-Click Checkout App - allows an end user to input their PayID and create a single use PayTo agreement. End users will need to approve the purchase each time in their banking application.
  3. Query string parameters

ExperienceConfigurationComments
URL Typetype=iFrameiFrame embeds the App inside your page.

If iFrame is not set the App will surface in a pop-up page with white label branding.
RedirectredirectURL=When the payer journey has completed successfully, the payer will be returned to this URL. Must be URL encoded.
CancelcancelRedirectURL=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. Must be URL encoded.

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.

Exception scenarios handled within the App:

Incorrect OTP

Ineligible PayID

Payment cannot be processed

Agreement not approved in time

Insufficient funds