Adding Open Banking (Redirect mode) as a payment option to your Payment Page requires a little configuration as outlined below. In Redirect mode you will use the Nuapay user interface for Bank Selection and Confirmation screens, with the screens being launched in a new browser window. Alternatively, you can use this mode if you would like to implement a setup where PSUs are emailed a link to the Bank Selection page or scan a QR code, for example.
Overview
Note: Redirect is one of four Open Banking implementation approaches available. See Implementation Options for more on this.
Note that the approach and sequence of API calls varies for Merchants (who are accessing the services for themselves) and Partners who are accessing the service on behalf of their merchants.
Tip: Select the appropriate tab below to view the endpoints required and the sequence of calls:
A detailed overview of the various steps involved in the REDIRECT flow is provided in the image below for Merchant users.
Tip: Click Extend from the top menu to enlarge or click the image itself to open it in a new browser tab/window
REDIRECT Flow - Merchant
In Redirect mode you will:
(Optionally) Use your API key to retrieve a merchant access token. (For more on this, see retrieving tokens).
Call the /payments endpoint (see Create Payment), using the OAuth token retrieved in the previous step (or else use your API Key).
Set the integrationType to REDIRECT. You must also provide the merchantPostAuthUrl - this is mandatory for the Redirect flow.
The Nuapay TPP creates the payment object and returns the userInterfacePaymentId.
The PSU then needs to be redirected to the URI with the userInterfacePaymentId. You must build a URI that can be used on a web page or sent by an e-mail to the end user. The URL will be similar to the following (on the Production environment):
The end user clicks the URI, and the Nuapay TPP (with the Bank selection window) is displayed in a new browser window.
When the user selects a bank, he/she is redirected to the selected ASPSP to authorize the payment.
The ASPSP redirects the PSU back to the TPP UI, which processes that callback.
The TPP then redirects the PSU to the merchantPostAuthUrl with the parameters userInterfacePaymentId.
Use Retrieve Payment to determine the final payment status, if required. (This integration also supports webhooks so you can be informed when the payment is completed).
A detailed overview of the various steps involved in the REDIRECT flow is provided in the image below for Partner users.
Tip: Click Extend from the top menu to enlarge or click the image itself to open it in a new browser tab/window
REDIRECT Flow - Partner
Use your partner-level API key to retrieve a token representing the required merchant. (For more on this, see list organisations and retrieving tokens).
Call the /payments endpoint (see Create Payment), on behalf of the merchant, using the OAuth token retrieved in the previous step.
Set the integrationType to REDIRECT. You must also provide the merchantPostAuthUrl - this is mandatory for the Redirect flow.
The TPP creates the payment object and returns the userInterfacePaymentId.
The PSU then needs to be redirected to the URL with the userInterfacePaymentId. You must build a URI that can be used on a web page or sent by an email to the end user. The URL will be similar to the following (on the Production environment):
The end user clicks the link, and the Nuapay TPP (with the Bank selection window) is displayed in a new browser window.
When the user selects a bank, he/she is redirected to the selected ASPSP to authorize the payment.
The ASPSP redirects the PSU back to the TPP UI, which processes that callback.
The TPP UI then redirects the PSU to the merchantPostAuthUrl with the parameter paymentId.
Use Retrieve Payment to determine the final payment status. (This integration also supports webhooks so you can be informed when the payment is completed).
Merchant Post-Auth URL Handling
The merchant merchantPostAuthUrl is sent as follows:
The payload of this request that you need to process includes:
Headers e.g. Content-Type: application/x-www-form-urlencoded Body e.g. paymentId=4m6vjed32a&userInterfacePaymentId=95125314-5161-4769-926f-143ff6cbdd82
Please note that the ‘paymentId’ allows you to look up the payment associated with this callback.
Authorisation
An API Key or an OAuth token uniquely identifies you on Nuapay and is required to allow you to use our API services.
For more on API Keys and OAuth, see the API Basics section.
Calling the Payment Endpoint
The Open Banking payment endpoint returns a payment identifier on a successful invocation.
To generate a payment ID:
Generate a server-to-server call to /payments.
Ensure that you have referenced your API Key or OAuth token in the request.
This button will open the Select Banks on a new browser tab or window for the userInterfacePaymentId (the uiid).
Reusing the Link
If you have decided to email the link to the PSU or have provided a QR code, that user may begin the payment, drop out of the flow and retry accessing the link later. In that case:
The TPP will check the existing payment status in the TPP database.
If the payment’s current status means that the payment cannot proceed (e.g. if the payment is in SETTLEMENT_REJECTED) an alert is displayed to the user on the TPP and he/she cannot continue.
If the payment is in status PENDING then the user will be able to proceed and complete the payment. Note that PENDING is the only status that will allow the PSU to proceed.
Note: If the PSU goes to the ASPSP and cancels, the Payment Declined Webhook is triggered. However if the PSU reuses that payment link later, the payment status will revert to PENDING, allowing the user to complete the payment, if required.
