# Integration and acceptance

In this section, you can find the answers to frequently asked questions about Alipay+ integration and acceptance.

-   FAQs about Cashier Payment

-   [Who provides the payment URL?](#ZcpBf)
-   [When is the **userInitiatedPay** API used？](#Pv9lm)

-   FAQs about Auto Debit

-   [How frequently does the MPP send OTPs to the user?](#bxkmV)
-   [What result code should the MPP return when an API is called by using the access token with insufficient scopes?](#Dj41D)
-   [What's the usage of the payment evaluation?](#VVdI2)
-   [What is the inquiry result for a payment evaluation?](#lkDTJ)
-   [Should the MPP verify the _referenceAgreementId_ parameter when performing an agreement payment?](#D0IDC)
-   [In the Auto Debit scenarios, what's the difference between the _authUrl_ and the _redirectUrl_ parameters?](#KWlZM)
-   [Is the integration of the prepare API mandatory?](#svj4h)
-   [How to associate the use of the **prepare**, **applyToken**, and **pay** APIs for Auto Debit?](#RlcRU)
-   [How does the MPP verify the corresponding _authClientId_ of an access token?](#i3KFk)
-   [How does the MPP register the merchant information before an Auto Debit payment?](#cAsdQ)

-   FAQs about Merchant-presented Mode Payment

-   [Can Alipay+ process the QR code issued by the MPP?](#sRA87)
-   [Will Alipay+ verify the format of the codes issued by the ACQP?](#syvUW)
-   [Should the MPP first identify whether the code is a local code after receiving the code value?](#aPW0l)
-   [Why should the MPP integrate the Alipay+ Server SDK?](#m7lpc)
-   [Why should the MPP redirect the user to the merchant payment result page after the user completes the payment?](#SzyrX)

-   FAQs about User-presented Mode Payment

-   [What's the validity period of a payment code?](#j8h4p)
-   [How to solve the issue of weak internet connectivity when MPPs display payment codes?](#RXNXx)
-   [For User-presented Mode Payment, can the user choose the payment method such as a credit card or the balance?](#p0LqS)
-   [How to prevent the payment code from being taken a screenshot?](#EW3pH)
-   [How to specify the terminal ID for User-presented Mode Payment?](#T2CAu)
-   [Who provides the payment code page for User-presented Mode Payment?](#XAP4x)
-   [Should the MPP display the reference rate on the payment code page?](#TqTXc)

-   FAQs about common issues for different payment scenarios

-   Payment

-   [How to understand the difference between the _orderAmount_, _paymentAmount_, and _payToAmount_ parameters in the **pay** API?](#q68Gr)
-   [For transactions within what duration should the MPP return the transaction status by using the **inquiryPayment** API?](#bAdED)
-   [How frequently can Alipay+ call the **inquiryPayment** API for the payment with an unknown result?](#CTxuu)
-   [What is the result of a canceled payment from the **inquiryPayment** API?](#JwloB)
-   [Should _payment.resultCode_ returned in the **inquiryPayment** API be consistent with the _resultCode_ returned in the **pay** API?](#vlVPZ)
-   [Will the _resultCode_ be `PROCESS_FAIL` if the _resultStatus_ is `F`?](#OYNW0)
-   [What scenarios require the integration of the **inquiryPayment** and the **notifyPayment** APIs?](#q2eEe)
-   [Is the _order_ parameter optional in the **pay** API request?](#HLq5X)

-   Reconcile

-   [Why are the _paymentId_ parameter and the _refundId_ parameter not included in the reconciliation reports?](#doY8k)
-   [When is the Settlement Report uploaded to the SFTP server?](#WFUMm)
-   [Can the settlement report contain no transaction records?](#mBZyK)
-   [What are the rules of the _seq_ field in the file name of the reconciliation reports?](#GFepn)
-   [Are the records of the dispute resolutions included in the Settlement Report?](#i0EjC)

-   Refund & cancellation

-   [How to understand the difference between the _refundAmount_ and _refundAmount_ parameters in the **Refund** API?](#mUGsf)
-   [When the user status is abnormal or the user does not exist for a refund, should the MPP return refund success?](#zYxin)
-   [Must the MPP support multiple refunds and partial refunds?](#OXHec)
-   [How is the refund performed asynchronously?](#DLvSh)
-   [When the transaction that is not refunded successfully and is settled in the settlement report, can the refund request be retried?](#Us5UU)
-   [What's the cancellable period and refundable period of a payment?](#VrRRN)

-   Message transmission

-   [For generating and verifying the signature, should the MPP install extra certificates in the MPP server?](#YkVsq)
-   [When Alipay+ signs the request that is sent to the MPP, who does the _client-Id_ parameter identify?](#h1W5r)
-   [Why does the signature validation fail and how to resolve the problem?](#kd6ai)
-   [Is the API endpoint identical for sandbox and production environments?](#eblNJ)

-   Other

-   [Is the information about service fees contained in the **refund** or **pay** APIs?](#h8EJl)
-   [Should all APIs follow the Alipay+ request URL format?](#Xp86P)
-   [Are the HTTP header names case-sensitive?](#eO6y5)
-   [What is _tracer-ID_ in the HTTP response header used for?](#inmVr)
-   [How does the MPP connect with Alipay+?](#nteXr)
-   [Can _resultStatus_ be `F` when the _resultCode_ is `REQUEST_TRAFFIC_EXCEED_LIMIT?`](#RJnDo)
-   [Does Alipay+ always retry the request when the returned _resultStatus_ is `F` or `U`?](#tK1A5)
-   [Do the date and time format in the requests from Alipay+ follow ISO 8601?](#rtXo7)
-   [What environment should the MPP use to perform the sandbox testing?](#FRbc7)
-   [Does Alipay+ verify the value of the _authCode_ parameter?](#gUrit)
-   [Does Alipay+ generate and verify the value of the _accessToken_ parameter?](#cZ8Jp)
-   [Why must the values of the _authCode_ and the _accessToken_ parameters follow the CGCP standard?](#Jm4rb)
-   [What are the length requirements for the values of the _authCode_ and the _accessToken_ parameters?](#P3hk0)
-   [Must the MPP support idempotency for the requests initiated with the same _paymentRequestId_ parameter?](#X0gKD)
-   [How do I know what parameters are required in the API response?](#IwgUZ)
-   [Why should the MPP integrate the **notifyPayment** API even if the **inquiryPayment** API is integrated?](#Z06Gr)
-   [What are the validity periods of the access token and the refresh token?](#B69UE)
-   [How to understand the currency code?](#avhBv)

## Cashier Payment

#### Who provides the payment URL?

The MPP provides the payment URL through the _paymentUrl_ parameter in the **pay** API response. Alipay+ doesn't validate this URL.

#### When is the userInitiatedPay API used?

The **userInitiatedPay** API is used when a user initiates a payment in one of the following scenarios:

-   **Merchant-Presented Mode**: The user scans a QR code displayed by the merchant.
-   **Cashier Payment**: The user is redirected from the merchant's app or website to complete the payment.

In both cases, the Mobile Payment Provider (MPP) calls this API to send the order code to Alipay+. Alipay+ then decodes the code and returns the necessary payment information.

## Auto Debit

#### How frequently does the MPP send OTPs to the user?

To address potential delivery issues due to unreliable mobile network services or weak signals, the MPP can send the OTP multiple times. Recommended intervals are 60 seconds for merchants and 30 to 60 seconds for MPPs.

#### What result code should the MPP return when an API is called by using the access token with insufficient scopes?

The MPP should return the `INVALID_TOKEN` result code and a detailed result message.

For example, if an Auto Debit payment request is initiated by calling the **pay** API and the corresponding scopes of the access token do not include `AGREEMENT_PAY`. In this case, the MPP should return the `INVALID_TOKEN` result code.

#### What's the usage of the payment evaluation?

The payment evaluation is used in the following scenarios:

-   Evaluate the user account to check whether the balance is enough to complete the payment.
-   The successful payment evaluation represents the successful payment, but no actual deduction occurs temporarily. After multiple payment evaluations, the merchant initiates one Auto Debit payment. 

#### What is the inquiry result for a payment evaluation?

A payment evaluation is a mocked payment and no payment data is stored. If the inquiry request for a payment evaluation is initiated, the `ORDER_NOT_EXIST` result code is returned.

#### Should the MPP verify the _referenceAgreementId_ parameter when performing an agreement payment?

No. The value of the _referenceAgreementId_ parameter is the unique ID that is assigned by the authorization client to identify an Auto Debit authorization, which matches an authorization code.

#### In the Auto Debit scenarios, what's the difference between the _authUrl_ and the _redirectUrl_ parameters?

The _authUrl_ is used by the merchant to redirect users to the MPP page and complete Auto Debit authorization. The _authUrl_ can be constructed in one of the following 2 ways:

-   The ACQP calls the **prepare** API to request the authorization URL. In the request, the ACQP specifies the required information such as _authClientId_, _scopes_, and so on. The MPP returns the _authUrl_ in the response.

Or,

-   The MPP provides the initial _authUrl_ to Alipay+, and Alipay+ constructs the _authUrl_ by appending the required parameters to the _authUrl._ Alipay+ then sends the complete _authUrl_ to the ACQP and the merchant redirects the user to the _authUrl_ for the agreement payment authorization.

The _authRedirectUrl_ is the URL for the MPP to redirect the user to the page that is provided by the merchant. After the user completes the Auto Debit authorization, the MPP redirects the user to the _authRedirectUr__l_, in which `authCode` is appended. The merchant uses the obtained `authCode` to apply for the access token.

#### Is the integration of the prepare API mandatory?

The **prepare** API is conditional for now. If _authUrl_ is dynamic, this API is required. If _authUrl_ is static, this API is not required.

#### How to associate the use of the prepare, applyToken, and pay APIs for Auto Debit?

For Auto Debit, the use of the 3 APIs are associated by the access token. After calling the **prepare** API, the MPP generates and returns the _authCode_ parameter. The ACQP uses the value of the _authCode_ parameter to apply for the access token by calling the **applyToken** API. Before the access token expires, the merchant uses the same access token to perform Auto Debit payments by calling the **pay** API. 

#### How does the MPP verify the corresponding authClientId of an access token?

When the ACQP calls the **applyToken** API, the _authClientId_ parameter must be specified in the request. The MPP can associate the access token with the corresponding _authClientId_ parameter.

#### How does the MPP register the merchant information before an Auto Debit payment?

The MPP can integrate the **registration** API. Alipay+ calls this API to provide the information about the merchant in the request, such as `authClientId`, `authClientName`, `scopes`, and `authRedirectUrl`. The MPP adds the merchant information to the internal system for future authorization.

## Merchant-presented Mode Payment

#### Can Alipay+ process the QR codes issued by the MPP?

No. For the QR codes issued by the MPP, the MPP processes the code value based on the MPP's own local logic.

#### Will Alipay+ verify the format of the codes issued by the ACQP?

Yes, Alipay+ will verify whether the codes follow the Alipay+ Code Scanning Payment Standards.

#### Should the MPP first identify whether the code is a local code after receiving the code value?

Yes, the MPP must first identify whether the code is a local code before calling Alipay+ Server SDK for code identification. 

#### Why should the MPP integrate the Alipay+ Server SDK?

The Alipay+ Server SDK helps the MPP process different logic based on the returned code identification results. Alipay+ Server SDK periodically pulls configurations from the Alipay+ server. When the MPP app calls the Alipay+ Server SDK to identify a code, the Alipay+ Server SDK returns the _isSupported_ parameter after the code identification. Based on the value of the _isSupported_ parameter, the MPP decides to take the corresponding action, such as rejecting the transaction, calling Alipay+ Client SDK to decode, or redirecting users to the merchant page.

#### Why should the MPP redirect the user to the merchant payment result page after the user completes the payment?

Because overseas merchants rely on this page to confirm the payment result.

## User-presented Mode Payment

#### What's the validity period of a payment code?

The validity period of the payment code is 60 seconds by default.

#### How to solve the issue of weak internet connectivity when MPPs display payment codes?

A caching strategy is employed. Alipay+ Client SDK applies for multiple payment codes from Alipay+ at a time. These codes are then made valid in succession, with a time gap between each. Although this caching process may cause a minor network delay of approximately 100 milliseconds, it ensures that payment codes are readily available for display even in situations with unreliable network signals.

#### For User-presented Mode Payment, can the user choose the payment method such as a credit card or the balance?

Alipay+ only routes the payment request to a specific MPP. The MPP can display the detailed payment methods, such as credit card and user balance, to be chosen by the user.

#### How to prevent the payment code from being taken a screenshot?

For iOS, if the screenshot is taken on the payment code page, the Alipay+ Client SDK intervenes by displaying a modal dialogue. The MPP can customize the content of this message.

For Android, taking screenshots must be forbidden when the MPP presents the payment code.

When a screenshot is attempted, The MPP app notifies the event to the Alipay+ Client SDK and the current payment code is invalid. To obtain a new payment code, the user must refresh the page and the MPP app must call the **getPaymentCode** API again.

#### How to specify the terminal ID for User-presented Mode Payment?

The terminal ID is specified by the _order_._env_._deviceTokenId_ parameter.

#### Who provides the payment code page for User-presented Mode Payment?

The MPP. However, the payment code is provided by Alipay+. The MPP applies the payment code from Alipay+ and displays the payment code page to the user.

#### Should the MPP display the reference rate on the payment code page?

For User-presented Mode Payment, the MPP displays the actual exchange rate on the payment result page. It's not suggested that MPP displays the reference rate on the payment code page. The reference rate might be different from the actual exchange rate, which might cause user complaints. 

## Common

### Payment

#### How to understand the difference between the _orderAmount_, _paymentAmount_, and _payToAmount_ parameters in the pay API?

The following list describes the _orderAmount_, _paymentAmount_, and _payToAmount_ parameters.

-   **_orderAmount_** is the original amount and currency when the merchant creates the order. 
-   **_paymentAmount_** is the amount collected from the user and is equal to **_orderAmount_** if no promotion tools are used.
-   **_payToAmount_** is the amount that the user pays eventually.

The MPP debits the user account according to **_payToAmount_**.

#### For transactions within what duration should the MPP return the transaction status by using the inquiryPayment API?

For transactions that occur within one year, MPP must return the transaction status when receiving the **inquiryPayment** API requests from Alipay+.

#### How frequently can Alipay+ call the inquiryPayment API for the payment with an unknown result?

For the payment with an unknown result, Alipay+ can call the **inquiryPayment** API to query the payment result. If Alipay+ does not receive the inquiry result in time, Alipay+ retries the inquiry request.

-   For Cashier Payment, Alipay+ retries 10 times totally with intervals of 10s, 10s, 30s, 60s, 60s, 120s, 120s, 120s, 120s, 120s.
-   For Auto Debit Payment, Alipay+ retries 6 times totally with intervals of 4s, 4s, 30s, 60s, 60s, 60s.
-   For User-presented Mode Payment, Alipay+ retries 6 times totally with intervals of 4s, 4s, 30s, 60s, 60s, 60s.
-   For Merchant-presented Mode Payment, Alipay+ retries 8 times totally with intervals of 10s, 10s, 30s, 60s, 60s, 60s, 60s, 60s.

#### What is the result of a canceled payment from the inquiryPayment API?

The result of a canceled payment from the **inquiryPayment** API is `ORDER_IS_CLOSED`, regardless of the original payment status. See the following list for details:

-   When both the payment and the payment cancelation results are successful, the value of the _result.resultCode_ parameter is `SUCCESS` and _paymentResult.resultCode_ is `ORDER_IS_CLOSED`.
-   When the payment is failed and the cancelation of the failed payment is successful, _result.resultCode_ is `SUCCESS` and _paymentResult.resultCode_ is `ORDER_IS_CLOSED`.
-   When the payment status is unknown and the cancelation of the unknown payment is successful, _result.resultCode_ is `SUCCESS` and _paymentResult.resultCode_ is `ORDER_IS_CLOSED`.
-   When the payment is closed because of timeout and the cancelation of the payment is successful, _result.resultCode_ is `SUCCESS` and _paymentResult.resultCode_ is `ORDER_IS_CLOSED`.

#### Should _payment.resultCode_ returned in the inquiryPayment API be consistent with the _resultCode_ returned in the pay API?

Yes, both _resultStatus_ and _resultCode_ returned in the **inquiryPayment** API and the **pay** API should be consistent.

#### Will the _resultCode_ be `PROCESS_FAIL` if the _resultStatus_ is `F`?

No. `PROCESS_FAIL` should only be used when the payment fails and no specific result code matches the situation. Otherwise, use the appropriate result code that is specified for the failure.

#### What scenarios require the integration of the inquiryPayment and the notifyPayment APIs?

All. To improve the user experience and system stability, the **inquiryPayment** API and the **notifyPayment** API must be integrated in all payment scenarios.

#### Is the _order_ parameter optional in the pay API request?

The _order_ parameter is mandatory. The order information must be sent to the MPP, which includes the buyer information, merchant information, goods information, and payment amount.

## Reconcile

#### Why are the _paymentId_ and the _refundId_ parameters not included in the reconciliation reports?

For MPPs that join Alipay+, transactions in the reconciliation reports are identified by the _transactionRequestId_ parameter, which is assigned by Alipay+. In the request processing, the MPP might not return _paymentId_ or _refundId_ in the response. For example, Alipay+ processes a refund request successfully but the MPP fails to process the refund request. In this case, MPP does not return _refundId_ in the response, but this refund is included in the clearing report and is identified by _transactionRequestId_. After obtaining the clearing report, the MPP deals with the refund manually.

#### When is the Settlement Report uploaded to the SFTP server?

The settlement report is uploaded to the SFTP server on the MPP's Local Business Day.

#### Can the settlement report contain no transaction records?

Yes. When no amount is to be settled, or the settlement amount is less than the settlement amount threshold as agreed in the contract, a settlement report is generated with an amount of zero and no transaction records are contained. The transaction amount and currency are empty.

#### What are the rules of the _seq_ field in the file name of the reconciliation reports?

A report file can contain a maximum of 100,000 records. If the report contains more than 100,000 records, the report is split into multiple files and the size of each file is around 20 MB. In the file name, the _seq_ field is the sequence number with a range of 000-999. The MPP and Alipay+ can determine the time when all records are available in SLA.

#### Are records of dispute resolutions included in the settlement report?

No. The settlement report only includes payment and refund transactions.

### Refund & cancelation

#### How to understand the difference between the _refundAmount_ and _refundFromAmount_ parameters in the Refund API?

The following list describes **_refundAmount_** and **_refundFromAmount_**:

-   **_refundAmount_** is the amount that's refunded to the user by MPP.
-   **_refundFromAmount_** is the refund amount that the user receives eventually.

The MPP refunds the amount to the user according to **_refundFromAmount_**.

#### When the user status is abnormal or the user does not exist for a refund, should the MPP return refund success?

Yes, even when the user status is abnormal or does not exist, the MPP returns refund success so Alipay+ can update the refund status to success accordingly. The refund is included in the clearing and settlement reports and the MPP can then deal with the refund manually.

#### Must the MPP support multiple refunds and partial refunds?

Yes, MPPs must support multiple refunds and partial refunds. If multiple refunds for one payment are initiated, MPP must return the unique refund ID and the actual refund time for each refund.

#### How is the refund performed asynchronously?

When the ACQP initiates the refund request, Alipay+ returns the refund success synchronously to the ACQP. After that, Alipay+ sends the refund request to the MPP asynchronously. If the MPP returns refund success, Alipay+ updates the refund status to refund success. If the MPP returns refund failure, Alipay+ retries the refund request until the refund succeeds. The fund flow of the refund is ACQP -> Alipay+ -> MPP.

#### When the transaction that is not refunded successfully and is settled in the settlement report, can the refund request be retried?

Yes. For the transaction that is not refunded successfully and is settled in the settlement report, Alipay+ keeps retrying the refund request. If the refund succeeds, the successful refund is included in the clearing reports and settled in the settlement report.

#### What's the cancellable period and refundable period of a payment?

The merchant can initiate a refund transaction within 1 year (365 days by default) of the original payment transaction date. The payment can be canceled within the agreed cancellable period, which is from the time when the transaction is initiated to 00:30 UTC+8 of T+1 day, regardless of the payment status.

### Message transmission

#### How do Alipay+ and the MPP exchange public keys?

For both the sandbox environment and the production environment, the MPP can upload the public key and view Alipay+ public key at Alipay+ Developer Center. For more information, see [Alipay+ Developer Center](../developer_center_mpp/develop_in_sandbox#YabQV).

#### For generating and verifying the signature, should the MPP install extra certificates in the MPP server?

Yes, the communication between the MPP and Alipay+ uses HTTPS, which means that the MPP domain requires the certificate.

#### When Alipay+ signs the request that is sent to the MPP, who does the _client-Id_ parameter identify?

In the request sent from Alipay+ to the MPP, the _client-Id_ parameter identifies the MPP. On the **Settings** page in the Alipay+ Developer Center, you can find the Client ID, which is assigned by Alipay+ after you create the application.

#### Why does the signature validation fail and how to resolve the problem?

The signature validation can fail because of various reasons. See the following list for details.

-   Inconsistent character encodings

Verify whether the failure is caused by inconsistent Chinese character encodings. Sign the request with and without Chinese characters respectively and validate the signatures. Find the reasons based on the verification results. 

-   Line breaks and spaces included in the request message

The request message must use a strict format and not contain line breaks or spaces. Otherwise, the request message might be inconsistent with the data in the content to be signed, which causes the failure of the signature validation. For more information about the content to be signed, see [Sign a request and validate the signature](../api_mpp/signature#vvkE6).

-   Unremoved beginning and ending words

This is because when the MPP uploads the public key, the beginning and ending words, which are **BEGIN PUBLIC KEY** and **END PUBLIC KEY**, are not removed. Remove line breaks and the beginning and ending words.

-   Unmatched private key and public key

Use the tools downloaded at the Alipay+ Developer Center to compare the private key and the public key. Ensure that you use the keys of the same key pair.

-   Inconsistent algorithms and processing logic

The algorithms and processing logic used in the request signing and signature validation must be consistent. Currently, the algorithm used by Alipay+ is RSA256. Check whether the value of `signature` in the request header is `algorithm=RSA256, keyVersion=0`.

-   Inconsistent processing rules of special characters

Use the same base64 algorithm to encode the data.

-   Unmatched keys and the environment

Check whether the correct public key is used in the corresponding environment. The development environment, production environment, and the system integration testing environment must use the correct public keys.

#### Is the API endpoint identical for sandbox and production environments?

Yes, the API endpoint is the same for both environments. However, users must use a different client ID for each environment. Client IDs for both sandbox and production environments are available in Alipay+ Developer Center. Use the appropriate client ID to ensure proper access and functionality within the respective environment.

### Other

#### Is the information about service fees contained in the refund or pay APIs?

The service fees are charged by Alipay+ after the transaction succeeds and the information is not contained in the API messages. To obtain the service fee information, see [Reconcile](../reconcile_mpp/reconcile_overview).

#### Should all APIs follow the Alipay+ request URL format?

Not so when Alipay+ calls the MPP. But when MPP calls an API to Alipay+, the API follows the format of `https://{host}/aps/api/v1/{restfulPath}`, in which **host** is the standard domain name assigned by Alipay and **restfulPath** is the path to the API. For example, `https://open-sea.alipayplus.com/aps/api/v1/payments/notifyPayment`.

#### Are the HTTP header names case-sensitive?

No, HTTP header names are not case-sensitive.

#### What is tracer-ID in the HTTP response header used for?

The tracer-ID is an internal identifier assigned by Alipay+, which is used for troubleshooting.

#### How does the MPP connect with Alipay+?

It's suggested that the MPP connects with Alipay+ through leased lines. However, the public network is also supported.

#### Can _resultStatus_ be `F` when the resultCode is `REQUEST_TRAFFIC_EXCEED_LIMIT`?

No. The MPP must follow the API document for the value of the _resultStatus_ parameter. When the value of the _resultCode_ parameter is `REQUEST_TRAFFIC_EXCEED_LIMIT`, the value of the _resultStatus_ parameter must be `U`.

#### Does Alipay+ always retry the request when the returned _resultStatus_ is `F` or `U`?

No. For the refund and cancelation requests, Alipay+ retries the request if the value of the _resultStatus_ parameter is `F` or `U`. However, for the payment request, Alipay+ only retries the request if the value of the _resultStatus_ parameter is `U`.

#### Do the date and time format in the requests from Alipay+ follow ISO 8601?

Yes. The MPP must be able to handle the UTC time normally. For example, 2004-05-03T17:30:08+08:00 describes a UTC+8 time and 2004-05-03T17:30:08Z describes a UTC time.

#### What environment should the MPP use to perform the sandbox testing?

The MPP should use the offline testing environment and can set endpoints on the **Sandbox** \> **Settings** page in the [Alipay+ Developer Center](../developer_center_mpp/develop_in_sandbox).

#### Does Alipay+ verify the value of the _authCode_ parameter?

No. The value of the _authCode_ parameter is used for routing the request. Alipay+ only verifies the format of the value of the _authCode_ parameter.

#### Does Alipay+ generate and verify the value of the _accessToken_ parameter?

No. The value of the _accessToken_ parameter is generated and verified by the MPP according to requirements.

#### Why must the values of the _authCode_ and the _accessToken_ parameters follow the CGCP standard?

When requesting user authorization or initiating an Auto Debit payment request, the merchant only provides the _authCode_ or _accessToken_ parameter in the request. Alipay+ must route the request to the corresponding MPP based on the value of the _authCode_ or _accessToken_ parameter.

#### What are the length requirements for the values of the _authCode_ and the _accessToken_ parameters?

The length requirement for the values of the _authCode_ parameter is 32 digits at most and for that of the _accessToken_/_refreshToken_ parameter, 128 digits at most. The business type identifier for the value of the _authCode_ parameter is `13`, while for the _accessToken/refreshToken_ parameter, it is `03`.

#### Must the MPP support idempotency for the requests initiated with the same _paymentRequestId_ parameter?

Yes. For the requests initiated with the same _paymentRequestId_, the MPP must return the results based on the following rules:

-   If Alipay+ initiates **pay** requests with the same _paymentRequestId_ twice, the MPP must avoid inconsistent results such as the following:

-   For the first payment request, MPP returns _resultStatus_ = `F`. For the second payment request, MPP returns _resultStatus_ = `S`.
-   For the first payment request, MPP returns _resultStatus_ = `S`. For the second payment request, MPP returns _resultStatus_ = `F`.

-   If Alipay+ initiates **inquiryPayment** requests with the same _paymentRequestId_ twice, the MPP must avoid inconsistent results such as the following:

-   For the first payment inquiry request, MPP returns _paymentResult_._resultStatus_ = `F`. For the second payment inquiry request, MPP returns _paymentResult_._resultStatus_ = `S`.
-   For the first payment inquiry request, MPP returns _paymentResult_._resultStatus_ = `S`. For the second payment inquiry request, MPP returns _paymentResult_._resultStatus_ = `F`. Cases where the successful payment is canceled before the second payment inquiry is excluded.

-   For the payment with the same _paymentRequestId_, the MPP returns the results via the **pay** API and the **inquiryPayment** API. The MPP must avoid the following situations:

-   In the **pay** API, _resultStatus_ = `F`, but in the **inquiryPayment** API, _paymentResult_._resultStatus_ = `S`.
-   In the **pay** API, resultStatus = `S`, and in the **inquiryPayment** API, _paymentResult_._resultStatus_ = `F`. Cases where the successful payment is canceled before the second payment inquiry is excluded.

If _resultStatus_ = `F` is returned by the **pay** API, or _paymentStatus_._resultStatus_ = `F` is returned by the **inquiryPayment** API, Alipay+ updates the payment status to failure and the MPP must ensure that the payment cannot be successful anymore. 

#### How do I know what parameters are required in the API response?

In the API response, the _result_ parameter is always mandatory. For other parameters, see the response section of the API for details.

#### Why should the MPP integrate the notifyPayment API even if the inquiryPayment API is integrated?

Integrating the **notifyPayment** API is needed because of the following reasons:

-   Too frequent payment inquiries increase the network pressure for the MPP. The merchant might not get the payment result in time, thus resulting in the cancelation of the payment. 
-   When the payment inquiry is unavailable because of network issues, using the **notifyPayment** API is the only method to notify the merchant of the payment result.

#### What are the validity periods of the access token and the refresh token?

Each access token corresponds to a specific scope. According to the scopes, the validity period of the access token differs. The following table lists the validity period requirements for different scopes:

| **Scope** | **Validity period** |
| --- | --- |
| AGREEMENT\_PAY | The validity period is at least one year for the access token and at least one and a half years for the refresh token. It's suggested that the validity period of the access token is more than two years and that of the refresh token is more than two and a half years. |
| SEND\_OTP | The validity period is at least one year for the access token and at least one and a half years for the refresh token. It's suggested that the validity period of the access token is more than two years and that of the refresh token is more than two and a half years. |
| BASE\_USER\_INFO | It's suggested that the validity period of the access token is 10 minutes. |
| USER\_LOGIN\_ID | It's suggested that the validity period of the access token is 10 minutes. |
| HASH\_LOGIN\_ID | It's suggested that the validity period of the access token is 10 minutes. |
| > **Note**: When multiple scopes are specified, the validity periods of the access token and the refresh token are defined based on the scope which requires a longer or the longest validity period. For example, if the values of _scopes_ parameter are `AGREEMENT_PAY` and `BASE_USER_INFO`, then the validity periods of the access token and the refresh token follow the requirements for the `AGREEMENT_PAY` scope. | > **Note**: When multiple scopes are specified, the validity periods of the access token and the refresh token are defined based on the scope which requires a longer or the longest validity period. For example, if the values of _scopes_ parameter are `AGREEMENT_PAY` and `BASE_USER_INFO`, then the validity periods of the access token and the refresh token follow the requirements for the `AGREEMENT_PAY` scope. |

#### How to understand the currency code?

The currency code used by Alipay+ follows the ISO 4217 standard. All amounts presented in the API sample codes are expressed in the smallest currency unit. See [Currency list](https://www.currency-iso.org/en/home/tables/table-a1.html) for details. In the list, the _Minor unit_ column defines the number of decimals, which determines the smallest unit of a currency. Most currencies have 2 decimals. Some currencies do not have decimals, such as JPY, and some have 3 decimals, such as BHD. For example, 10 CNY is submitted as 1000, whereas 10 JPY is submitted as 10.

###