Payments

confirm

Customer confirms receipt of goods to release escrow funds to merchant.

Overview

POST /v1/payments/confirm is used to capture the total authorized payment amount from a user's account, and then transfer the total amount of the payment to a merchant's account after the user confirms receipt. The confirm can only be initiated once and in full.

Note: The merchant may call the confirm API to notify A+ that the order has been confirmed only after the customer has actually completed the order confirmation.

All monetary amounts in requests and responses must be expressed in the smallest currency unit (IQD fils). For example, 100 IQD equals 100000.

  • Only payments with escrow product code (51051000101000100008) can use this API.
  • The merchant must have already accepted the payment using merchantAccept before the customer can confirm.
  • Once confirmed, funds are immediately released to the merchant and cannot be reversed.
  • Customers should only confirm after verifying the goods are satisfactory.

  1. The Mini Program calls this my.getAuthCode JSAPI with specific scopes(USER_ID) to request an authorization code.
  2. The E-wallet App service calls authorization service to processes the authorization information.
  3. The E-wallet backend verifies the authorization information, generates the authCode and returns.
  4. The E-wallet App service returns the authCode to the Mini Program.
  5. The Mini Program sends the authCode to the merchant backend.
  6. The merchant backend calls the applyToken API with authCode to apply the accessToken.
  7. The E-Wallet backend returns accessToken information to the merchant backend, such as customerId, accessToken, refreshToken, etc.
  8. The merchant backend returns customerId to mini program.
  9. The Mini Program creates an order with customerId.
  10. The merchant backend calls the payment API to initiate payment flow, including customerId as referenceBuyerId, paymentNotifyUrl(optional), etc.
  11. The E-Wallet backend returns payment detail information the merchant backend, such as redirectionUrl.
  12. The merchant backend passes the payment detail information to the Mini Program.
  13. The Mini Program calls the my.tradePay JSAPI with redirectionUrl to conduct the payment.
  14. The E-Wallet App Service displays the cashier page with order information, such as amount, order details, etc.
  15. The user confirms the payment in the cashier page.
  16. The E-Wallet App Service calls payment service and execute the payment process.
  17. When the payment reaches the final status, the E-wallet backend returns the payment result to the Mini Program (Step 19).
  18. The E-Wallet App Service returns the payment result to mini program.
  19. Also the E-wallet backend notifies the merchant backend of the payment result with paymentNotifyUrl provided in Step 10.
  20. Finally, E-wallet backend notifies the user of the payment result via SMS/Email/Inbox message.
  21. Merchant backend calls the merchantAccept API to accept this order.
  22. The E-Wallet backend returns the merchantAccept result to the merchant backend.
  23. The Mini Program sends the confirm request to merchant backend, and the merchant backend calls the confirm API to capture the money(Step 25).
  24. (This step is internal - see step 25)
  25. Send confirm request via /v1/payments/confirm.
  26. The E-Wallet backend returns the confirm result to the merchant backend.
  27. The merchant backend returns confirm result.
  28. And the Mini Program displays the confirm result to the user(Step 28).

Alternative flow: When the E-Wallet backend returns the resultCode as CONFIRM_IN_PROCESS, the merchant can call inquiryPayment API to query confirm result (Step 29).

Endpoint

MethodPath
POST/v1/payments/confirm

API Structure

A message consists of a header and body. The following sections are focused on the body structure. For the header structure, see: OpenAPIs Overview.

Request

FieldTypeRequiredDescriptionExample
paymentIdstringYesThe unique ID that is assigned by the wallet to identify a payment. Max. length: 64 characters."202312061112128001016"
confirmRequestIdstringYesThe unique ID is assigned by a merchant to identify a confirm request. Max. length: 64 characters."1022188000000000001xxxx"
extendInfostringNoThe extension information that wallets and merchants want to describe. The format should be JSON format. Max. length: 2048 characters.-

Sample Request

{
  "paymentId": "202312061112128001001660090000xxxx",
  "confirmRequestId": "1022188000000000001xxxx"
}

The confirmRequestId is used for idempotence—repeat submissions with the same ID will yield the same final result.

Response

FieldTypeRequiredDescriptionExample
resultobjectYesThe request result, which contains information such as result status and error codes.{ "resultCode": "SUCCESS", "resultStatus": "S", "resultMessage": "Success." }
confirmIdstringNoThe unique ID for a confirm request generated by the wallet. Max. length: 64 characters."202312061112128001016x"
confirmTimestringNoThe processing time for a confirm request. The format of the value follows the ISO 8601 standard."2025-07-08T12:12:12+08:00"

Sample Response

{
  "result": {
    "resultCode": "SUCCESS",
    "resultStatus": "S",
    "resultMessage": "Success."
  },
  "confirmId": "202312061112128001016x",
  "confirmTime": "2025-07-08T12:12:12+08:00"
}

Result Process Logic

In the response, the result.resultStatus field indicates the result of processing a request. The following table describes each result status:

resultStatusDescription
SIt means that the confirm is successful. The corresponding result.resultCode is "SUCCESS", and the result.resultMessage is "Success.".
UIt means that the status of the confirm result is unknown. The corresponding result.resultCode is UNKNOWN_EXCEPTION, and result.resultMessage is "An API calling is failed, which is caused by unknown reasons". For details, see the Common error codes section.
FIt means that the confirm fails. The corresponding result.resultCode and result.resultMessage may vary based on different situations. For details, see the Error codes section.

Error Codes

Error codes are usually classified into the following categories:

  • Common error codes are common across all mini program's APIs.
  • API-specific error codes are listed in the following table.
resultStatusresultCoderesultMessage
FORDER_UNSUPPORTED_OPERATIONThe order is not support capture.
FORDER_STATUS_INVALIDThe order status is invalid.
FORDER_NOT_EXISTThe order does not exist.
UCONFIRM_IN_PROCESSThe confirm is processing.
FCURRENCY_NOT_SUPPORTThe currency of a user's payment is not supported by the merchant.
FUSER_NOT_EXISTThe user does not exist.
FUSER_STATUS_ABNORMALThe user status is abnormal.
FREPEAT_REQ_INCONSISTENTThe submitted request is not consistent with the repeated one.
FMUTEX_OPERATION_IN_PROCESSINGThere is another payment void, confirm, or capture in processing.
FPARTNER_NOT_EXISTThe partner does not exist.
FPARTNER_STATUS_ABNORMALThe partner status is abnormal.