Alipay, China's leading third-party online payment solutionAlipay, China's leading third-party online payment solution

Pay with card payment methods

Alipay enables you to receive payments by using various payment methods. One of the most popular payment methods is the card payment method, which has a different integration from that of other payment methods. This guide describes how to integrate the card payment method.

Prerequisites

Before you begin, you must complete the following tasks:

  • Register on Alipay Developer Center.
  • Set your keys.
  • If you want to receive payments in Hong Kong or Singapore, contact Alipay Technical Support to configure your integration project.
  • Test in the sandbox environment.

For details, see Alipay integration guide.

Scenarios

The card payment follows the auth-capture mode, which means the card payment is completed in two steps: authorization and capture. When a user pays with a card, you must request the card payment to be authorized to freeze a certain amount of funds and then request to capture the fund. After the capture succeeds, the funds are transferred to your account. You must request to capture the funds seven days after the authorization succeeds, otherwise the authorized funds are unfrozen automatically.

The card payment method is used in the following three scenarios:

Pay with card payment methods

Figure 1. Card payment process

Payment

You must complete the following integration steps before you can receive a card payment:

  1. Obtain and display available payment methods.
  2. Request to authorize the payment.
  3. Obtain the authorization result.
  4. Request to capture the payment.
  5. Obtain the capture result.

The user experience for card payment on a shopping website is shown in the following figure:

image

Figure 2. User experience of card payments

  1. After a user confirms the order information, the user clicks or taps Place Order to go to the payment method page.
  2. On the payment method page, the user chooses a card payment method, enters information about payment elements, and clicks or taps Pay Now to continue the payment process.
  3. A redirection is performed according to the payment result:
    • SUCCESS: The user is redirected to the payment result page to be informed of a successful payment.
    • FAIL: The user is redirected to the payment result page to be informed of a failed payment.
    • PAYMENT_IN_PROCESS: The user is redirected to a mobile website provided by the card payment method. Then the user is required to enter information on this page to complete the payment.
      Note: You can redirect the user to the URL provided in normalUrl returned through the pay API. This URL varies by your business type and the payment verification type. For details, see User experience of a payment process.
  1. After the payment is completed, the user is redirected to the payment result page.

During the integration process, you need to focus efforts on developing the payment method page. This page serves the following purposes:

  • Display available payment methods: Payment methods are sorted according to payment information such as payment amount and the user's region.
  • Manage payment status: This page displays a payment countdown and monitors the payment status to determine whether to redirect the user.
  • Redirect the user to check out: Redirect the user to a checkout page by using a redirection URL that is obtained from Alipay.
  • Receive payment callback (optional): Receive the payment callback by monitoring the invocation of the checkout page or by using a lifecycle function. Then you can redirect the user to the payment result page according to the payment status.

Step 1: Obtain and display available payment methods

We recommend that you obtain available payment methods and their information by using the consult API and properly display the payment methods on the payment method page.

1. Obtain payment methods

You can call the consult API to obtain a list of payment methods. In your request, specify the following parameters:

Request parameter

Required or not

Description

merchantRegion

OPTIONAL

The region where you receive card payments. The value of this parameter is a two-letter ISO code. Specify this parameter if you would like to receive card payments in Singapore or Hong Kong. The allowed values are as follows:

  • SG
  • HK

allowedPaymentMethodRegion

OPTIONAL

The region in which the payment method is based. The value of this parameter is a two-letter ISO code or GLOBAL. The allowed values are as follows:

  • GLOBAL: indicates that the card is a global card.
  • KR: indicates the card is a South Korean card with the card issuing country being South Korea.
  • BR: indicates the card is a Brazilian card with the card issuing country being Brazil.

Specify this parameter if you want to obtain available payment methods in specific regions.

userRegion

OPTIONAL

The region in which the user is located. The value of this parameter is a two-letter ISO code. This parameter is used to sort the returned payment methods. Specifically, the payment methods preferred in the user's region are displayed at the top of the list.

Note: The card payment methods (if any) are always displayed above the other payment methods.

paymentAmount

REQUIRED

The transaction currency and amount.

env

REQUIRED

The client type that is used for the payment, such as a desktop browser, a mobile browser, or a mobile application.

Table 1. Request parameters of the consult API

After you send the request, Alipay returns the following parameters to notify you of the necessary information about the payment methods:

Response parameter

Description

paymentOptions.paymentMethodType

For card payment methods, the value of this parameter is fixed to CARD.

paymentOptions.paymentMethodCategory

For card payment methods, the value of this parameter is fixed to CARD.

paymentOptions.paymentMethodRegion

For card payment methods, this parameter indicates the card issuing country. The value of this parameter is a two-letter ISO code or GLOBAL. The possible values are as follows:

  • global: indicates the card is a global card.
  • KR: indicates the card is a South Korean card with the card issuing country being South Korea.
  • BR: indicates the card is a Brazilian card with the card issuing country being Brazil.

paymentOptions.enabled

Indicates whether the payment method is available.

paymentOptions.logo

The logo of the payment method.

paymentOptions.paymentOptionDetail.supportCardBrands.logo

The card brand logo of the card payment method. For details about the possible values, see Card brand list.

paymentOptions.paymentOptionDetail.supportCardBrands.cardBrand

The card brand supported by the card payment method. For details about the possible values, see Card brand list.

paymentOptions.paymentOptionDetail.funding

The card type. The possible values are as follows:

  • CREDIT: indicates that the card is a credit card.
  • DEBIT: indicates that the card is a debit card.

paymentOptions.installment.supportCardBrands

The information about a card brand that supports installment.

paymentOptions.installment.plans

The information about installment plans of a card brand that supports installment.

Table 2. Response parameters of the consult API

2. Display payment methods

We recommend you display the payment methods in the following ways:

  • You can display the name and the logo of each available payment method that are indicated by paymentOptions.logo.logoName and paymentOptions.logo.logoUrl in the payment method list. You can also display the card brands supported by each card payment method for users to choose from.
  • To avoid displaying a long list of payment methods, we recommend you use a multi-level menu to deliver a better experience. Specifically, you can fold the payment methods in a menu of payment method types. After a payment method type is clicked or tapped, the corresponding payment methods are displayed. Meanwhile, to improve the payment success rate, you can also sort the payment methods by payment success rate, promotion events, and user preference.

image

Figure 2. Display of card payment methods

Step 2: Request to authorize the payment

When a user pays with a card, you must request to authorize the payment by using the pay API.

Necessary information about the payment needs to be collected before the payment can be authorized. The information can be collected in the following two ways that provide different authorization processes:

  • Merchants (you) collect the card information
  • Tokenization

Authorization process:

  1. A user chooses a payment card and an installment plan (optional) as needed, and clicks or taps Place Order.
  2. You must provide a page to collect information about payment elements and a checkbox to ask the user whether to allow the payment card to be saved (that is, to allow the card binding). For some cards that require additional information for identity verification (for example, the Brazilian cards require a CPF code), we recommend that you also collect the information on this page.
  3. The user enters the required information and confirms whether to bind the payment card.
  4. If the user binds the card, you must properly keep the information about the payment elements and the correspondence between the user and the card.
  5. You initiate the authorization process by using the pay API.
  6. Alipay returns the URL of an intermediate page according to your request:
  • If you have provided all the required information, the URL of an empty intermediate page is returned.
  • If you have not provided all the required information, the URL of an intermediate page that is used to collect the required information is returned.
  1. You must open the URL returned by Alipay. If an intermediate page that requires information about the payment elements is displayed, the user needs to enter the information as required.
  2. Alipay verifies the information again:
  • If the verification fails, the user is prompted to re-enter the information and the Submit Payment button is greyed out.
  • If the verification succeeds, the user can click or tap the Submit Payment button to submit the payment.
  1. If the payment card supports 3D Secure, a further verification process must be performed:
  1. A 3D Secure verification page is opened on the Alipay intermediate page.
  2. The user enters information to pass the 3D Secure verification.
  3. After the verification succeeds, an authorized payment is initiated.
  1. Alipay returns the authorization result to you.
  2. You can call the inquiryPayment API to inquire about the payment result.
  3. After you obtain the payment result, you can display a payment result page.

During the payment authorization phase, proceed with the following steps:

1. Collect information about the payment

The information about the user's card needs to be collected for the payment. Specifically, the user needs to enter the information about the payment elements on an intermediate page and decides whether to bind the card. Card binding frees the user from entering information about the payment elements for follow-up payments. The payment information can be collected in the following two ways:

  • Merchants collect the card information
  • Tokenization

If you are PCI-qualified, you can provide a page to collect information about a user's card and whether the user agrees to bind the card.

  • If the user does not agree to bind the card, the card information is used for a one-time payment only.
  • If the user agrees to bind the card, you must properly keep the card information for follow-up payments.

You can collect the following information:

  • Payment elements.
  • Installment plan (some card payment methods do not support installments).
  • Additional information for identity verification required by some cards (for example, the Brazilian cards require a CPF code).

Note: Pass the collected information to Alipay through the pay API to prevent Alipay from repeatedly collecting the information.

Benefits:

This mode enables you to collect the card information before you call the pay API, hence its name, the collection-in-advance mode. The benefit of this mode is that you can pass the payment information through the pay API for some payment method providers to obtain the payment result directly through the API. This reduces redirections and thus enhances the payment efficiency and payment success rate.

The user experience in the collection-in-advance mode is shown in the following figure:

Pay with card payment methods

Pay with card payment methods

Pay with card payment methods

Pay with card payment methods

Provide fields for the following information:

  • Card number (cardNo)
  • Credit Verification Value (CVV), which is required by card payment methods excluding the South Korean cards.
  • Card expiry (expiryYear and expiryMonth)
  • Cardholder's name (cardholderName), which is required by the Brazilian cards, Chillian cards, Peruvian cards, and Mexican cards.
  • Cardholder's date of birth (dateOfBirth), which is required by South Korean individual cards.
  • Corporate business number (businessNo), which is required by South Korean corporate cards.
  • The first two digits of a payment password (cardPasswordDigest), which is required by the South Korean cards.
  • Cardholder's email (payerEmail), which is required by the Brazilian cards, Chillian cards, Peruvian cards, and Mexican cards.

Provide a list of installment plans for users to choose from.

Provide fields for additional information required by some cards (for example, the Brazilian cards require a CPF code).

Table 3. User experience in the collection-in-advance mode

2. Intercept an invalid payment

To avoid a repeated payment or an expired payment, we recommend that you verify the status and validity period of the payment after the user clicks or taps Pay.

Pay with card payment methods

Figure 3. Payment status verification for Web

To intercept an expired payment, you can set the payment expiry time by specifying the paymentExpiryTime parameter in the payment request. If a user pays after the payment expiry time, an error is reported or the payment is refunded. Setting the payment expiry time also avoids repeated payments which might occur when the user pays long after they are redirected to the payment method page.

The time offset of a server can also lead to a repeated payment. We recommend that you determine the payment status of the order after the user pays. If the order is paid before, you can call the cancel API to cancel the payment or call the refund API to initiate a full refund to the user, and prompt the user accordingly.

3. Send a payment request

After the user clicks or taps Confirm payment, your server calls the pay API to obtain a redirection URL from Alipay and return it to your client. Perform this step according to the following instructions:

  • Before the redirection URL is obtained after the request is sent, grey out the Confirm payment button in case of repeated operations triggered by the user.
  • To deliver a smooth payment process, remember to pass the card information when sending a payment request.
  • Set the expiry time of the request to prevent users from waiting.
  • Specify parameters in the request properly according to the verification type (2D or 3D secure).

Send the request

The information that you must pass to Alipay varies by the collection mode of the card information. The following table shows the child parameters of paymentMethod that you must specify in your payment request in different collection modes:

Child parameter

Instruction

Merchants collect the card information

Tokenization

paymentMethodType

The value of this parameter is fixed to CARD.

✔️

✔️

paymentMethodId

Indicates the payment method ID. This parameter is required for a follow-up payment with a saved card and is not required for a first-time payment. The value of this parameter is the same with the value of cardToken obtained through the notifyPayment notification or inquiryPayment API.

✔️

paymentMethodMetaData.is3DSAuthentication

Specify the value to indicate whether to use 3D secure verification. Alipay determines the verification type based on the assigned value, risk control policies, and payment method capabilities (whether a payment method supports 3D secure verification).

  • is3DSAuthentication=true: indicates that you want to use 3D secure verification. However, the verification type also depends on Alipay's risk control policies.
  • is3DSAuthentication=false: indicates that you want to use 2D secure verification. However, the verification type also depends on Alipay's risk control policies.
  • is3DSAuthentication is not specified: Alipay determines the verification type.

✔️

✔️

paymentMethodMetaData.cardNo

Indicates a card number.

✔️

paymentMethodMetaData.cvv

Indicates a CVV number.

✔️

paymentMethodMetaData.expiryYear

Indicates the expiry year of a card.

✔️

paymentMethodMetaData.expiryMonth

Indicates the expiry month of a card.

✔️

paymentMethodMetaData.cardholderName

Indicates a cardholder's name.

✔️

paymentMethodMetaData.billingAddress

Indicates the billing address of a cardholder.

✔️

paymentMethodMetaData.cpf

Indicates a CPF number. It is required for Brazilian cards.

✔️

paymentMethodMetaData.dateOfBirth

Indicates the date of birth of a cardholder

✔️

paymentMethodMetaData.businessNo

Indicates the business number of a corporate card.

✔️

paymentMethodMetaData.cardPasswordDigest

Indicates the first two digits of a payment password.

✔️

paymentMethodMetaData.payerEmail

Indicates the email address of a cardholder.

✔️

paymentMethodMetaData.paymentMethodRegion

Indicates the region where a payment method is located. The value of this parameter is a two-letter ISO code. Pass in this parameter if you want to determine the supported regions of the payment method. Otherwise, Alipay determines the supported regions of the payment method.

✔️

✔️

Table 4. Description of child parameters of paymentMethod

Alipay handles the payment process based on the completeness of the information in the payment request:

  • If the card information is complete, Alipay continues the payment process.
  • If the card information is incomplete, Alipay provides an intermediate page to collect the card information.

Note:

For online payments with cards, identity verification generally falls into two types: 2D secure verification and 3D secure verification.

2D secure verification: When a cardholder pays online, the cardholder needs to enter the card information and then undergo the verification process on the mobile phone. Some payment methods even omit the verification process on the mobile phone. 2D secure verification can hardly identify fraudulent charges and thus put the cardholder's account at risk.

3D secure verification: When a cardholder pays online, the cardholder needs to enter the card information and then undergo the verification process on a 3D secure verification page. Information required for the verification varies by country. 3D secure verification features complicated verification steps but boasts higher security.

Other key request parameters in the pay API are shown in the following table:

Parameter

Description

merchantRegion

Indicates the region where you receive card payments. The value of this parameter is a two-letter ISO code. Specify this parameter if you want to receive card payments in Singapore or Hong Kong. The allowed values are as follows:

  • SG
  • HK

paymentRequestId

The unique identifier that you assign to a payment.

paymentAmount.value

The payment amount.

env.terminalType

If the payment is made in a desktop browser, the value is WEB. If the payment is made in a mobile browser, the value is WAB. If the payment is made in a mobile application, the value is APP.

referenceOrderId/paymentRequestId

referenceOrderId generally refers to an order ID, and paymentRequestId generally refers to a transaction ID. Alipay allows one order ID corresponding to multiple transaction IDs. You can also establish a one-to-one correspondence between them.

paymentRedirectUrl

Pass in a mobile URL.

paymentNotifyUrl

Pass in an HTTPS URL.

paymentFactor.isAuthorization

The value is fixed to true.

creditPayPlan.installmentNum

The number of installments. Allowed value: 2-12. If you do not specify this parameter, an installment plan is not used.

creditPayPlan.feePercentage

The commission fee of an installment plan. Allowed value: 0-100. For example, when the value is 5, the commission fee is 5% of the payment amount.

Some payment methods do not support installments. The payment methods that support installments do not charge users for the commission. Specify this parameter if you would like to charge for an installment plan.

creditPayPlan.creditPayFeeType

The value of this parameter is PERCENTAGE. Specify this parameter to express the figure of the commission fee as a percentage.

Table 5. Key request parameters in the pay API

Handle the request

The payment process might fail when you call the pay API. In this case, your server can call the pay API to reinitiate the payment request with a new paymentRequestId. However, the retried request can still fail due to network issues. We recommend that you set the expiry time of the request to prevent the user from waiting and allow the user to pay again after your server fails to obtain the redirection URL. Follow the workflow shown in the following figure:

image

Figure 4. Request handling logic

Receive the response

The response to a payment request varies by the following factors:

  • Collection mode of the card information
  • Verification type (whether 3D secure verification is used. If not, 2D secure verification is used)

The following table describes the return results of the response and provides the ways of handling the result:

Collection mode of the card information

Verification type

Return result

Handling

Merchants collect the card information

2D (payment is successful)

result.resultCode: SUCCESS

Redirect the user to the payment result page.

2D (payment is failed)

result.resultCode: FAIL

2D (payment is being processed)

  • result.resultCode: PAYMENT_IN_PROCESS
  • normalUrl

Redirect the user to the returned URL.

3D

  • result.resultCode: PAYMENT_IN_PROCESS
  • normalUrl

Tokenization

Regardless of 2D or 3D

  • result.resultCode: PAYMENT_IN_PROCESS
  • normalUrl

Table 6. Handling of the response in different scenarios

2D secure verification:

Merchants collect the card information: If a result code of SUCCESS or FAIL is obtained, Alipay returns the payment result in the response. If a result code of PAYMENT_IN_PROCESS is obtained, Alipay returns normalUrl for further payment handling. After you receive normalUrl, you need to redirect the user to it to continue the payment process.

Tokenization: Regardless of the result code, Alipay returns normalUrl for further payment handling. After you receive normalUrl, you need to redirect the user to it or open it in a new tab to continue the payment process.

3D secure verification:

Regardless of the result code, Alipay returns normalUrl for further payment handling. After you receive normalUrl, you need to redirect the user to it or open it in a new tab for the user to complete a 3D secure verification process and continue the payment process.

4. Obtain an authorization result

You can obtain an authorization result by using one of the following three ways:

  • Receive a synchronous return result.
  • Receive an asynchronous notification.
  • Inquire about the authorization result.

Receive a synchronous return result

In the response parameters of the pay API, if the value of resultStatus is S, the authorization is successful. If the value of resultStatus is F, the authorization is failed. If the value of resultStatus is U, you need to receive an asynchronous notification or inquire about the authorization result.

Receive an asynchronous notification

You can obtain the authorization result by receiving an asynchronous notification sent by Alipay.

You must set a notification address by specifying paymentNotifyUrl in the pay API before you can receive the asynchronous notification. When a final authorization status is achieved (that is, when the authorization is successful or failed), Alipay sends you the asynchronous notification through the notifyPayment notification. When you receive the notification, you must return a response as instructed in Requirements. Otherwise, Alipay resends the notification until a correct response is received. The key parameters contained in the asynchronous notification are shown in the following table:

Parameter

Description

notifyType

The value is PAYMENT_RESULT.

paymentId

A unique identifier that Alipay assigns to an order.

result

An authorization result.

acquirerReferenceNo

If you have integrated the capabilities of receiving card payments in Singapore or Hong Kong, the acquirer number is provided in the notification.

cardInfo

When the card information is collected by Alipay, if a user agrees to bind a card, the card information of the user is provided in the notification. The card information includes the following:

  • Desensitized card number (cardNo)
  • Card brand (cardBrand)
  • Card token (cardToken)
  • If a 3D secure verification is used, an Electronic Commerce Indicator (ECI) is returned.
  • Card issuing country (issuingCountry)
  • Card type (funding)
  • The region where a payment method is located (paymentMethodRegion)

Table 7. Key parameters of the notifyPayment notification

You can configure the notification address in the following two ways:

  • Specify paymentNotifyUrl in the pay API.
  • Edit Notification URL in the Integration Settings tab of Alipay Developer Center.

Inquire about the authorization status

The asynchronous notification and the synchronous redirection can both fail to be received or implemented. The causes are described in the following table:

Cause

Handling

Asynchronous notification

The notification cannot be received due to network issues.

Alipay automatically resends the notification.

Synchronous redirection

  • The redirection fails due to network issues.
  • A user manually closes the browser after the user completes a payment.

Table 8. The causes of failing to obtain the authorization result

We recommend that you inquire about the payment status by calling the inquiryPayment API. You can use the API in the following scenarios:

Before the payment result page is invoked: When the payment is initiated on the payment method page, you can automatically trigger calling the inquiryPayment API for subsequent redirection.

When the user inquires about the payment result: When the user clicks or taps I have paid or a button with the same meaning on your page, you can call the inquiryPayment API to check the payment status.

When the payment times out: When the payment reaches the expiry time, you can call the inquiryPayment API to check the payment status.

In the response returned through the inquiryPayment API, paymentStatus indicates the payment status. See the following table for details:

paymentStatus

Type

Description

Handling

SUCCESS

Final status

The payment is successful.

You can display a payment success page.

PROCESSING

Intermediate status

The payment is being processed.

You can allow the user to continue to pay.

FAIL

Final status

The user has not paid or the payment fails.

You can allow the user to continue to pay or close the payment order.

CANCELLED

Final status

The payment is canceled by you.

You can allow the user to continue to pay or close the payment order.

Table 9. Details of paymentStatus

We recommend that you maintain the payment status in your server and your client proceeds with the payment process based on the information provided by your server. For details about the payment status, see Payment status description.

When the card information is collected by Alipay, if a user agrees to bind a card, the card information of the user is provided in the response. The card information includes the following:

  • Desensitized card number (cardNo)
  • Card brand (cardBrand)
  • Card token (cardToken)
  • If a 3D secure verification is used, an Electronic Commerce Indicator (ECI) is returned.
  • Card issuing country (issuingCountry)
  • Card type (funding)
  • The region where a payment method is located (paymentMethodRegion)

5. Handle a follow-up payment with a saved card

When a user agrees to bind a card for the first-time payment, the user does not need to enter the stored card information for follow-up payments.

Handle the payment

You must handle a follow-up payment according to the collection mode of the card information. This is because the collection mode determines the information you must maintain and the APIs you must call.

image

Figure 5. Payment processing logic according to the collection mode of the card information

In this mode, when a user agrees to bind a card, you need to store the user ID and the corresponding card information. When the user pays with a saved card after the first payment, proceed according to the following instructions:

  1. Automatically display a desensitized card number on the checkout page according to the user ID.
  2. Send a payment request that is the same as the first payment request through the pay API. That is, you must pass in the complete card information of the user, paymentMethodId (specify it as cardToken), and additional information for identity verification (for example, the Brazilian cards require a CPF code).

Manage a saved card

A user with a saved card can update the information of the card or delete the card. To this end, see the following instructions to help users manage their cards according to the collection mode of the card information:

  • A user can update the information about a card, such as the validity period of the card, because you store and manage the user's card information.
  • A user can add or delete a card on the checkout page. You can delete the corresponding card information when a user deletes a card.

6. (Optional) Cancel an authorization

You can cancel an authorization by calling the cancel API. You need to cancel an authorization in the following scenarios:

  • When the user initiates a refund while the payment is authorized but not captured, you need to cancel the authorization of the payment.
  • When the risk control system detects a risk in a payment, you need to cancel the authorization of the payment.

If an authorization is canceled, the value of result.resultStatus in the response parameters of the cancel API is S.

Step 3: Request to capture the payment

You must request to capture the payment by calling the capture API within seven days after the authorization succeeds, otherwise Alipay automatically unfreezes the authorized funds. Some card payment methods support multiple captures of an authorized fund. The total capture amount must be no greater than the total authorized amount.

The key request parameters in the capture API is shown in the following table:

Parameter

Description

captureRequestId

A unique identifier that you assign to a request.

paymentId

A unique identifier that Alipay assigns to an order.

captureAmount

The capture amount, which must be no greater than the total authorized amount.

Table 10. Description of key parameters in the capture API

Step 4: Obtain a capture result

You can obtain a capture result by using one of the following three ways:

  • Receive a synchronous return result.
  • Receive an asynchronous notification.
  • Inquire about the capture result.

Receive a synchronous return result

In the response parameters of the capture API, if the value of resultStatus is S, the capture is successful. If the value of resultStatus is F, the capture is failed. If the value of resultStatus is U, you need to receive an asynchronous notification or inquire about the capture result.

Receive an asynchronous notification

You can obtain the authorization result by receiving an asynchronous notification sent by Alipay.

You must set a notification address before you can receive the asynchronous notification. When a final capture status is achieved (that is, when the capture is successful or failed), Alipay sends you the asynchronous notification through the notifyCapture notification. When you receive the notification, you must return a response as instructed in Requirements. Otherwise, Alipay resends the notification until a correct response is received. The key parameters contained in the asynchronous notification are shown in the following table:

Parameter

Description

notifyType

The value is CAPTURE_RESULT.

paymentId

A unique identifier that Alipay assigns to an order.

result

A capture result.

acquirerReferenceNo

If you have integrated the capabilities of receiving card payments in Singapore or Hong Kong, the acquirer number is provided in the notification.

Table 7. Key parameters of the notifyCapture notification

You can configure the notification address in the following two ways:

  • Specify paymentNotifyUrl in the pay API.
  • Edit Notification URL in the Integration Settings tab of Alipay Developer Center.

Inquire about the authorization status

The asynchronous notification and the synchronous redirection can both fail to be received or implemented. We recommend that you inquire about the capture status by calling the inquiryPayment API. In the response returned through the inquiryPayment API, transactions indicates the capture status. See the following table for details:

Parameter

Description

transactions.transationType

The value is CAPTURE. It indicates the capture status.

transactions.transactionResult

A capture result.

Table 12. Child parameters of transactions

The value of transactions varies by the capture status. See the following code samples for details:

copy
{ "transactions": [ { "transactionType": "CAPTURE", "transactionStatus": "SUCCESS", "transactionRequestId": "test_test_test_XXXX", "transactionAmount": { "currency": "BRL", "value": "110" }, "transactionTime": "2022-09-29T07:13:50-07:00", "transactionId": "2022XXXXXXXX", "transactionResult": { "resultStatus": "S", "resultCode": "SUCCESS", "resultMessage": "success" } } ] }

Chargeback

For card payments, when a chargeback occurs, Alipay provides you with the following services:

  • Alipay notifies you of necessary information and freezes the funds related to the chargeback.
  • Alipay provides a card association with dispute materials.
  • Alipay notifies you of the liability judgment of the chargeback.

You can obtain the information about a chargeback by email or by receiving a notification sent by Alipay through the notifyDispute notification.

Receive a notification by email

After you receive a notification of the chargeback information by email, you need to respond to whether you accept the chargeback within a specific period. If you do not respond to the notification within the period, the chargeback is accepted by default. For the response periods required by payment methods, see the following table for details:

Payment method

Response period

Brazilian cards

7 days

South Korean cards

2 days

Table 13. Response periods required by payment methods

(Optional) Receive a notification through the API

You can receive a notification of the chargeback information by integrating the notifyDispute notification. Before you can receive the notification, you must configure a notification address in Alipay Developer Center.

Configure a notification address

You must edit Notification URL in the Integration Settings tab of Alipay Developer Center before you can receive the notification.

When a chargeback occurs or when the liability of the chargeback is judged, Alipay sends you the asynchronous notification through the notifyPayment notification. When you receive the notification, you must return a response as instructed in Requirements. Otherwise, Alipay resends the notification until a correct response is received.

  • When a chargeback occurs, you receive a notification of the chargeback information. The value of disputeNotificationType in the notification is DISPUTE_CREATED.
  • If you have a query about the chargeback, you can put in a demurrer. When the liability of the chargeback is judged, you receive a notification of the judgment information. The value of disputeNotificationType in the notification is DISPUTE_JUDGED. The liability judgment is indicated by the value of disputeJudgedResult:
    • ACCEPT_BY_CUSTOMER: The user assumes the liability. You can request to capture the payment.
    • ACCEPT_BY_MERCHANT: You assume the liability. You need to refund the user the payment amount.

Refund

When a user requests a refund, you need to confirm whether the refund can be issued. If the refund is allowed, you can issue the refund by calling the refund API. For the refund periods required by payment methods, see Refund.

For a payment where a chargeback occurs and the liability is not judged, a refund is not allowed.