Repeat payments with passkeys

Use the Payment Request integration with our Pay by Bank UX solution (returning user payment journey) to give repeat payers a highly secure and low friction payment experience, with PayID and PayTo

End User Payment Flow

Initial journey for first time payers - passkey setup

  1. User is presented with the Pay by Bank UX landing page, where Pay by Bank with PayTo is the default option shown. The customer is prompted to provide their PayID (their PayID can be in the form of a mobile phone number or email address)
  2. Azupay performs pre-requisite checks to ensure the user is eligible to continue with the payment


  1. When the user clicks on 'Authorise payment' the user is prompted to set up a passkey on their device in order to authenticate themselves for authorisation of this payment and to authorise future payments
  2. User is prompted to set up a passkey for payments, and they will be able to use fingerprint, face biometrics or device PIN to make a payment next time
  3. The device browser will ask them to authenticate using fingerprint, face biometrics or PIN for that device and confirm that a passkey has been saved for making Pay by Bank payments with you the merchant


  1. Upon successful setup of passkey on the customer's chosen device, a confirm payment screen is shown to the user asking them to approve the PayTo agreement in their online banking or mobile banking app
  2. After user approves the PayTo agreement, they will see that the payment has been taken out of their account and transaction is complete


Returning users making repeat payments

  1. User is presented with the Pay by Bank UX landing page displaying "Pay faster with PayTo" message, customer should click on "Verify with passkey" button
  2. Customer will be asked to authenticate themselves on their personal device by entering PIN or using biometrics
  3. Once authenticated, the payment will be taken from linked account to the PayTo agreement
  4. Customer will see screen confirming payment taken and transaction complete


Making a payment with PayID

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

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

  3. Upon successful payment, user is shown success screen 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.

ExperienceConfigurationAmountComments
Duration allowed for paymentPayment agreement expiry timeOnce 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 amountClient configurationThe 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
RedirectredirectURLWhen the payer journey has completed (either following success or terminating at some unhappy path ending) the payer will be returned to this URL
CancelcancelRedirectURLIf 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

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 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)