This topic provides complete information on the user experience of initiating the authorization, completing the authorization, and receiving the authorization result. Experiences for each possible redirection process between the merchant and payment method are also provided.

Users can initiate the authorization on three merchant terminal types: WEB, WAP, or APP. After the user initiates the authorization, the user will be redirected to the payment method client to complete the authorization. As the payment method supports the WEB, WAP, or APP client type, multiple redirection experiences (from the merchant to payment method) exist. In addition, for each merchant terminal type, the subsequent redirection mode and the supported redirection page type are different depending on each payment method's capability.

The user experiences from different types of merchant and payment method clients are presented in these sections:

• Merchant terminal type: WEB
• Merchant terminal type: WAP
• Merchant terminal type: APP

The authorization results for different cases are presented in these sections:

• Authorization success
• Authorization failed

User experience

This section provides a complete user experience of initiating the authorization, completing the authorization, and receiving the authorization result.

Merchant terminal type: WEB

If the user initiates the authorization on a WEB merchant terminal, the user will be redirected to a WEB payment method client. The payment method's website page provides one of the following possible methods for users to complete the authorization:

The following table shows which kind of experiences are provided by each payment method when the merchant terminal type is WEB:

Table 1. Supported website page types for each payment method when the payment method client type is WEB

Merchant terminal type: WAP

If the user initiates the authorization on a WAP merchant client, the user will be redirected to a WAP payment method client: a log-in-to-authorize WAP page.

Login-to-authorize WAP page

The user is redirected from a WAP merchant page to a WAP payment method page where an account and password are required to complete the authorization.

Figure 3. Redirection from a merchant WAP page to a login-to-authorize WAP page

Notes:

• After completing the authorization on the payment method part, the user is redirected back to the merchant page with a value of authCode by the default browser.
• The payment method authorization page must be a WAP page. If the payment method does not provide a WAP authorization page, redirection from the WAP merchant client to the payment method is not supported.

The following table shows the experience provided by each payment method when the merchant terminal type is WAP:

Table 2. Supported redirection experience for each payment method when the merchant terminal type is WAP

Merchant terminal type: APP

If the user initiates the authorization on a terminal page with an APP terminal type, the user will be redirected to one of the following possible terminals:

Notes:

• If the user has the payment method app installed, the payment method app is opened in one of the following ways：

• Via a universal link or an app link

• Universal Link: Allow users to intelligently follow links to content in your app or to your website in the iOS system. For more information, see iOS Universal Links.
• App Link: A deep link that when tapped, takes the user directly to a page within a specific app. For more information, see Android App Links.

• Via an intermediate page
• Via a dynamic link (Only for GCash)

• Which type of payment method client the user is redirected to is determined by the target payment method's capability and the merchant's integration method. There are three types of URLs returned by the value of authUrl in the consult response. Each type of URL leads to a different payment method redirection experience:

• If the authUrl value is an ordinary WAP address, the user is redirected to a log-in-to-authorize WAP page.
• If the authUrl value is a URL scheme (WAP-scheme), the user is redirected to open the browser first and then open the payment method app.
• If the authUrl value is a universal link or app link, the user is redirected to open the payment method app directly.

The following table shows which kind of experiences are provided by each payment method when the merchant terminal type is APP:

Table 3. Supported redirection experiences for each payment method when the merchant client type is APP

Authorization result

The authorization results for different cases are presented in these sections:

Authorization success

If the user completes the authorization successfully, the presented authorization result pages for different client types are shown below:

Table 4. Successful authorization result pages for different client types

Authorization failed

Usually, the user fails to complete the authorization because of authorization timeout or an active exit. The authorization result pages for different payment methods are shown below based on the following failure reasons:

Note: There are various transaction-related amounts and currencies you might use during different integration tasks for each payment method. For details, see Usage rules of the Amount object.

More information

Redirect from merchant to payment method

Redirect from payment method to merchant