tencent cloud

All product documents
Tencent Cloud Super App as a Service
DocumentationTencent Cloud Super App as a ServicePractice TutorialPayment and Merchant Practical Tutorial
Payment and Merchant Practical Tutorial
Download PDF
Last updated: 2025-04-17 11:58:04
Payment and Merchant Practical Tutorial
Last updated: 2025-04-17 11:58:04
Download PDF

Introduction

In the superapp ecosystem, mini programs manage multi-merchant transactions like e-commerce and local services, while mini games handle virtual goods transactions, game currency top-ups, exchanges, and ad revenue. Therefore, the superapp needs a merchant management platform for revenue sharing and settlement, integrated with standardized payment APIs to quickly offer payment services for mini programs and mini games.
When the superapp users initiate payments within mini programs or mini games, they can directly call the superapp's payment API. The payment process is consistent with the superapp's payment experience, preserving the familiar interaction for the superapp users without requiring redirects or additional steps, thus enhancing smoothness. Additionally, we do not store any payment credentials or parse transaction messages, safeguarding transaction security and user data. We guarantee:
Absolute security of funds: The payment process is 100% completed within your system, with us only providing technical integration channels.
Zero infringement on data sovereignty: User payment information is encrypted and directly connected to your backend.
Based on the above, you can implement payment solutions for mini programs (or mini games) within the superapp using the "Superapp payment capabilities and payment API integration solution" below:

Prerequisites

Ensure your superapp meets the following conditions:
The superapp has implemented or integrated a third-party payment channel.
The payment channel supports merchant management.

Merchant management

What is a merchant?

A merchant is an entity that provides goods or services in commercial activities and receives consumer payments through a payment platform. In the context of mini programs or mini games, it refers to the developers or operators of the mini programs or mini games registered in the supperapp. Merchants that engage in transactions with the superapp users must have merchant qualifications to offer goods or services. The payment platform handles merchant certification and transaction management. We use a specific payment channel as an example to explain the relationship between mini programs or mini games and merchants provided by the payment channel.

Reference solution: Mini program (or mini game) and payment channel merchant

Assume the supper superapp integrates with payment channel A. Developers of mini programs or mini games need to first register a merchant account with payment channel A. When the mini program or mini game within the superapp needs to use superapp's payment capabilities, the developer must enter the merchant ID in the console under Mini program management - Bind merchant account in the console to bind the merchant ID to the mini program or mini game. The merchant ID entered here is the merchant ID registered by the mini program or mini game developer with payment channel A, which must be obtained from payment channel A's merchant system.

Supported merchant management payment platforms

If your superapp does not support payments or the payment channel does not support merchant management, you can refer to the payment platforms below to develop your own merchant management system or integrate with these platforms:
Payment platform
Key features
Applicable regions and scenarios
Stripe Connect
Supports platforms and connected accounts
Dynamic split payments, subscription profit sharing
Global coverage (135+ currencies supported)
Digital marketplace, SaaS, multi-merchant e-commerce
PayPal Commerce Platform
Adaptive payments
Chained payments and delayed settlement
Supports PayPal, Venmo, credit cards
Cross-border e-commerce, multi-supplier platform
Adyen for Platforms
Sub-merchant accounts
Aggregation of localized payment methods
Funds routing rule engine
Multinational enterprises, hybrid online-offline scenarios
Braintree Marketplace
Deep integration with PayPal ecosystem (supports Venmo split payments)
Merchant of record
Automated tax calculations (integrated with Avalara)
U.S. domestic market, social e-commerce
Rapyd Global Payments Platform
Aggregation of local payment methods
Wallet accounts
Multi-tier split payments (supports platform commission)
Emerging markets (Southeast Asia, Latin America, Africa)
2C2P Marketplace Solution
Full coverage of local payment methods in Southeast Asia (GrabPay, DANA, etc.)
Automatic generation of multi-merchant settlement reports
Anti-fraud rules engine
E-commerce and game platforms in Southeast Asia

Superapp payment capabilities and payment API integration solution

Technical implementation


The merchant ID is the unique identifier for merchants on the superapp. All API calls must include this parameter to confirm the merchant's identity at the time of payment. The merchant ID is generated by the superapp and recorded in the Super App as a Service (SAS) console database.
The superapp admins can provide mini program developers with various methods to apply for a merchant ID, including email, console, and customer service. Mini program developers need to submit information including but not limited to bank account details, identification documents, and business qualifications to the superapp. After the request is approved, authorized personnel of the superapp will provide the mini program developer with a merchant ID in the form of a string.
After obtaining the merchant ID, the mini program developer should log in to Super App as a Service (SAS) console and submit a binding request on the "Mini program management - Bind merchant account" page (https://your-domain/superapp/miniapp/merchant-bind).

Super App as a Service (SAS) administrators should review on the “App management - Merchant payment” page (https://your-domain/superapp/app-management/merchant).

At this point, the application process for the merchant ID is complete.

Payment process within a mini program

Basic principles: Super App as a Service (SAS) is not involved in the encryption, decryption and signature verification process. The mini program and the superapp must independently complete the key exchange. Super App as a Service (SAS) acts as an isolation layer, separating the mini program from the superapp, with both parties adhering to the standard protocol defined by Super App as a Service (SAS) for integration. Therefore, mini program developers do not need to modify the protocol when the mini programs are launched in different superapps, but they must update the key information of the superapps.
Main process
The superapp must have payment capabilities and needs to integrate with the order placement and delivery notification APIs provided by Super App as a Service (SAS). It should also provide a method for the mini program to obtain keys.
The mini program requests keys from the superapp, which are required for data encryption, decryption, and signature verification.
Mini program developers need to integrate with the APIs of Super App as a Service (SAS) for order placement, initiating payments, and receiving delivery notifications to complete the payment process.

Key and public/private key application

The sequence diagram below illustrates the process of obtaining encrypted and decrypted keys.

After completing the request process, you will obtain the following three keys:
Super App as a Service (SAS) public key: Used by merchants to verify the reliability of data from Super App as a Service (SAS).
Merchant key pair: Used by Super App as a Service (SAS) to verify the reliability of data from merchants.
AES key: Used to encrypt sensitive data in delivery notifications. Since delivery notifications may contain sensitive customer information, encryption ensures that Super App as a Service (SAS) itself cannot access any such information.

Payment use case flowchart



The mini program payment process is divided into four stages:

1. Order generation: The user places an order and obtains a payment transaction session identifier. This involves the following API calls:
The mini program frontend sends a purchase request to the mini program backend.
Typically, this request should include the product amount, currency, product details, and quantity. This information is passed to Super App as a Service (SAS) backend through the order API and then forwarded to the superapp backend.
The mini program backend requests Super App as a Service (SAS) backend to initiate the prepayment order API.
After receiving the frontend request, the mini program backend needs to validate the parameters for reasonableness, including inventory, discount coupons, currency, and other business logic information. Once validated, it initiates an order request to Super App as a Service (SAS) backend (openserver). It is crucial to ensure the accuracy of the parameters in the order API, including order information, unit price, amount, quantity, the URL where the merchant receives payment success callback notifications. and user's OpenID. For detailed parameters, please see API list.
Below is a reference for the API message.
POST /v3/pay/transactions/jsapi \\
-H "Authorization: ******* " \\
-H "Content-Type:application/json" \\
-d '{
    "appid": "wxd678efh567hg6787",
    "description": "image Shop - Shenzhen Tengda - qq doll",
    "out_trade_no": "1217752501201407033233368018",
    "time_expire": "2018-06-08T10:34:56+08:00",
    "attach": "custom args",
    "notify_url","https://xxx.xxx.xxx/payBackx",
    "amount": {
        "total": 100,
        "currency": "USD"
    },
    "payer": {
        "openid": "XXXXXXXX"
    },
    "detail": {
        "cost_price": 608800,
        "goods_detail": [
            {
                "merchant_goods_id": "1246464644",
                "wechatpay_goods_id": "1001",
                "goods_name": "iPhoneX 256G",
                "quantity": 1,
                "unit_price": 528800
            }
        ]
    }
}'
Super App as a Service (SAS) backend forwards this request (including signature and request body) to the superapp backend. The superapp backend needs to implement the /v3/pay/transactions/jsapi API and return the order ID.
The superapp returns the generated order ID, which is routed back to the mini program backend.
{
    "prepay_id": "pid_xsxssx12w3123fefe"
}
After the mini program backend gets the prepay_id parameter, it also needs to generate the parameter paySign, and then return the required parameters to the mini program frontend for order placement: timeStamp, nonceStr, package, signType, paySign
Field
Type
Description
timestamp
String
Time (in seconds)
nonceStr
String
Random string with a length of 10 characters
package
String
Fixed format: prepay_id=${prepay_id}
signType
String
Fixed type: RSA
paySign
String
Calculated using the mini program ID, timeStamp, nonceStr, prepayId, and privateKey. Refer to the algorithm below.
// how to create paySign
const generatePaySign = function (appId, timestamp, nonceStr, prepayId, privateKey) {
  const string2sign = `${appId}\\n${timestamp}\\n${nonceStr}\\n${prepayId}`;
  const sign = crypto.createSign('RSA-SHA256');
  sign.update(string2sign);
  const sBytes = sign.sign(privateKey, 'base64');
  const paySign = Buffer.from(sBytes, 'base64').toString('base64');
  return paySign;
}
The final format of the parameters returned to the mini program frontend is as follows:
const response = {
    "timeStamp": "XXXXXX",
    "nonceStr": "XXXXXXXX",
    "package": "prepay_id=askdlfkadlsfkalsdjflakjsdf",
    "signType": "RSA",
    "paySign": "XXXXX",
}
2. Payment: The mini program initiates the payment, and the user completes the payment authorization.
The mini program frontend calls the wx.requestPayment API and provides the order ID and signature information. The code of the mini program frontend is as follows:
wx.requestPayment({
    timeStamp,
    nonceStr,
    package,
    signType: "RSA",
    paySign,
    success: function(res){
      // Pay success
    },
    fail: function(err){
      // cancel or pay has error
    }
});
The SDK forwards the request to the superapp.
The superapp provides the requestPayment API and verifies the order ID and signature.
After the verification, the superapp displays the payment and identity confirmation page, and the user completes the payment.
3. Delivery: After the payment is confirmed, the mini program is notified to proceed to the next process.
After the user completes the payment, the superapp backend calls the payment notification API PaymentNotify provided by Super App as a Service (SAS).
The entire request is signed with the private key of Super App as a Service (SAS) and included in the request header. The request body consists of the payment result enumeration and specific details, with the details part encrypted using the AES key.
Super App as a Service (SAS) backend will log this request and retry notifying the mini program backend within the next 24 hours. The mini program backend should correctly implement the notify_url interface callback until a correct response is returned. An example implementation of the mini program backend API is as follows:
Assuming the URL for the mini program backend payment callback is /notify_payBack2, the request message format is:
POST /notify_callback

Content-Type: application/json; charset=utf-8
Content-Length: 52
Connection: keep-alive
Keep-Alive: timeout=8
Cache-Control: no-cache, must-revalidate
X-Content-Type-Options: nosniff
Request-ID: 08F5B8C2B506102C18FDDFEEA30620BE821E28EDC405-0
Content-Language: zh-CN
Wechatpay-Nonce: d824f2e086d3c1df967785d13fcd22ef
Wechatpay-Signature: mfI1CPqvBrgcXfgXMFjdNIhBf27ACE2YyeWsWV9ZI7T7RU0vHvbQpu9Z32ogzc+k8ZC5n3kz7h70eWKjgqNdKQF0eRp8mVKlmfzMLBVHbssB9jEZEDXThOX1XFqX7s7ymia1hoHQxQagPGzkdWxtlZPZ4ZPvr1RiqkgAu6Is8MZgXXrRoBKqjmSdrP1N7uxzJ/cjfSiis9FiLjuADoqmQ1P7p2N876YPAol7Rn0+GswwAwxldbdLrmVSjfytfSBJFqTMHn4itojgxSWWN1byuckQt8hSTEv/Lg97QoeGniYP17T80pJeQyL3b+295FPHSO2AtvCgyIbKMZ0BALilAA==
Wechatpay-Timestamp: 1722850421
Wechatpay-Serial: PUB_KEY_ID_0000000000000024101100397200000006
Wechatpay-Signature-Type: WECHATPAY2-SHA256-RSA2048

{
    "id": "EV-2018022511223320873",
    "create_time": "2015-05-20T13:29:35+08:00",
    "resource_type": "encrypt-resource",
    "event_type": "TRANSACTION.SUCCESS",
    "summary": "pay success",
    "resource": {
        "original_type": "transaction",
        "algorithm": "AEAD_AES_256_GCM",
        "ciphertext": "*************",
        "associated_data": "",
        "nonce": ""
    }
}

HTTP Header Wechatpay-Timestamp: The response timestamp.
HTTP Header Wechatpay-Nonce: The response nonce.
The response signature from the supperapp's payment is transmitted via the HTTP header Wechatpay-Signature.
Response body: Use the original response body for verification. Ensure that any framework used does not alter the response body, as any modification will result in verification failure.
Construct the response signature string according to the following rules. The signature string consists of three lines, each ending with a newline character (\\n, ASCII value 0x0A). If the response body is empty (e.g., HTTP status code 204 No Content), the last line will be just a newline character.
Response timestamp\\nResponse random string\\nResponse body\\n
  1722850421\\n2d824f2e086d3c1df967785d13fcd22ef\\nbodyContent\\n
Next, proceed with signature verification. Many programming languages provide functions to verify signatures. It is strongly recommended to use these functions to perform SHA256 with RSA signature verification using the payment public key.
(1) Below is a demonstration of how to perform signature verification using the command line. Assuming you have obtained the payment public key and saved it as pay_pub.pem. See the details below:
  $ cat pay_pub.pem2
  -----BEGIN PUBLIC KEY-----
  3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4zej1cqugGQtVSY2Ah8RMCKcr2UpZ8Npo+5Ja9xpFPYkWHaF1Gjrn3d5kcwAFuHHcfdc3yxDYx6+9grvJnCA2zQzWjzVRa3BJ5LTMj6yqvhEmtvjO9D1xbFTA2m3kyjxlaIar/RYHZSslT4VmjIatW9KJCDKkwpM6x/RIWL8wwfFwgz2q3Zcrff1y72nB8p8P12ndH7GSLoY6d2Tv0OB2+We2Kyy2+QzfGXOmLp7UK/pFQjJjzhSf9jxaWJXYKIBxpGlddbRZj9PqvFPTiep8rvfKGNZF9Q6QaMYTpTp/uKQ3YvpDlyeQlYe4rRFauH3mOE6j56QlYQWivknDX9VrwIDAQAB4
  -----END PUBLIC KEY-----
(2) Use Base64 to decode the response signature and save it as a file signature.txt. (The following command lines are all in a single line.)
  $openssl base64 -d -A <<< \\ 'CtcbzwtQjN8rnOXItEBJ5aQFSnIXESeV28Pr2YEmf9wsDQ8Nx25ytW6FXBCAFdrr0mgqngX3AD9gNzjnNHzSGTPBSsaEkIfhPF4b8YRRTpny88tNLyprXA0GU5ID3DkZHpjFkX1hAp/D0fva2GKjGRLtvYbtUk/OLYqFuzbjt3yOBzJSKQqJsvbXILffgAmX4pKql+Ln+6UPvSCeKwznvtPaEx+9nMBmKu7Wpbqm/+2ksc0XwjD+xlvlECkCxfD/OJ4gN3IurE0fpjxIkvHDiinQmk51BI7zQD8k1znU7r/spPqB+vZjc5ep6DC5wZUpFu5vJ8MoNKjCu8wnzyCFdA==' > signature.txt
(3) Finally, verify the signature and get the verification result. Make sure that your result matches the document. If the verification result is Verification Failure, check whether the correct payment public key was obtained or if the signature string strictly follows the line break requirements.
$ openssl dgst -sha256 -verify pay_pub.pem -signature signature.txt << EOF
1554209980
c5ac7061fccab6bf3e254dcf98995b8c
{"data":[{"serial_no":"5157F09EFDC096DE15EBE81A47057A7232F1B8E1","effective_time":"2018-03-26T11:39:50+08:00","expire_time":"2023-03-25T11:39:50+08:00","encrypt_certificate":{"algorithm":"AEAD_AES_256_GCM","nonce":"d215b0511e9c","associated_data":"certificate","ciphertext":"..."}}]}
EOF
If the result is verified ok, it means the signature verification is successful.
If the mini program needs to access the encrypted content in the callback notification, it must decrypt the resource content.

Decryption example code:
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import base64
def decrypt(nonce, ciphertext, associated_data):
    key = "Your32Apiv3Key"
    key_bytes = str.encode(key)
    nonce_bytes = str.encode(nonce)
    ad_bytes = str.encode(associated_data)
    data = base64.b64decode(ciphertext)
    aesgcm = AESGCM(key_bytes)
    return aesgcm.decrypt(nonce_bytes, data, ad_bytes)

After completing the above steps, the mini program backend can return the following response to inform Super App as a Service (SAS) that the payment callback has been received and processed correctly:
{code : 200}
4. Payment confirmation: The mini program frontend can perform an additional confirmation to ensure that the payment completion request has not been forged.
Recommended practice: After the mini program frontend receives a payment success callback, it should call the mini program backend API to verify that the payment was indeed executed correctly, ensuring the authenticity of the data.

Application integration

For iOS and Android, a payment proxy API needs to be implemented on the application side.
iOS
You need to implement the requestPayment proxy API. The application should use the data returned from the backend API to return the success or failure result to the SDK via the completionHandler, which then passes it to the mini program. Example:

- (void)requestPayment:(TMFMiniAppInfo *)app params:(NSDictionary *)params completionHandler:(MACommonCallback)completionHandler {
[TUITool makeToast:@"Prepare to pay..."];
// Request the App backend based on the params parameters passed in by the mini program
[[TCMPPDemoPayManager sharedInstance] checkPreOrder:params completionHandler:^(NSError * _Nullable err, PayResponseData * _Nullable result) {
[TUITool hideToastActivity];
if (!err) {
// The request succeeded，and the payment native page pops up
dispatch_async(dispatch_get_main_queue(), ^{
TCMPPPaymentMethodsController *payMethodVC = [[TCMPPPaymentMethodsController alloc]init];
payMethodVC.payResponseData = result;
payMethodVC.app = app;
[[[TCMPPShareMiniAppModule sharedInstance] topViewController].navigationController pushViewController:payMethodVC animated:NO];
payMethodVC.completeHandle = ^(NSDictionary * _Nullable result, NSError * _Nullable error) {
// Complete payment and call back to the mini program
completionHandler(result,error);
};
});
} else {
// The request failed, payment was not completed, and the callback was sent to the mini program
NSDictionary *retDic = @{@"retmsg":err.localizedDescription};
if (result.returnCode && result.returnMessage) {
retDic = @{@"returnCode":result.returnCode,@"returnMessage":result.returnMessage};
}
completionHandler(retDic,err);
}
}];
}
Android
The superapp developers need to implement the MiniOpenApiProxyV2 proxy and the requestPayment method within the proxy class. Use AsyncResult to return the payment result to the mini program.
Here’s how to implement it:
@ProxyService(proxy = MiniOpenApiProxyV2.class)
public class MiniOpenApiProxyV2Impl extends MiniOpenApiProxyDefault {
private static final String TAG = "MiniOpenApiProxyV2";

@Override
public void requestPayment(IMiniAppContext miniAppContext, JSONObject params, AsyncResult result) {
PaymentManagerV2.g().startPayment(miniAppContext, params, result);
}
}

public class PaymentManagerV2 {
private static final String TAG = "PaymentManager";
private static PaymentManagerV2 instance;
private final PayApiV2 payApi = new PayApiV2();
private PaymentRequest paymentRequest;

public static PaymentManagerV2 g() {
if (instance == null) {
instance = new PaymentManagerV2();
}
return instance;
}

public void startPayment(IMiniAppContext miniAppContext, JSONObject params, AsyncResult result) {
//do params check
if (params.has("prepayId")) {
checkOrder(miniAppContext, params, result);
} else {
JSONObject failRet = new JSONObject();
try {
failRet.put("success", false);
} catch (JSONException e) {
}
result.onReceiveResult(false, failRet);
}
}

/**
* STEP 1: check order status
*
* @param miniAppContext
* @param params
* @param result
*/
private void checkOrder(IMiniAppContext miniAppContext, JSONObject params, AsyncResult result) {
String appId = miniAppContext.getMiniAppInfo().appId;
Activity activity = miniAppContext.getAttachedActivity();
payApi.checkOrder(appId, params, new PayApiV2.PayCallBack() {
@Override
public void onSuccess(JSONObject checkRet) {
String fee = checkRet.optString("actualAmount");
double paymentValue = Double.parseDouble(fee) / 10000;
showPayTypeList(activity, paymentValue, checkRet.toString());
paymentRequest = new PaymentRequest(miniAppContext, checkRet, result, paymentValue);
Log.e("TAG", "payment request " + this.hashCode());
}

@Override
public void onFailed(String errCode, String msg) {
Log.e(TAG, "pay failed " + msg);
activity.runOnUiThread(new Runnable() {
@Override
public void run() {
Toast.makeText(miniAppContext.getContext(), "failed", Toast.LENGTH_SHORT).show();
}
});
result.onReceiveResult(false, new JSONObject());
}
});
}

/**
* STEP 2: show pwd dialog
*
* @param activity
* @param money
*/
private void showPwdDialog(Activity activity, double money, ICustomPayCallback payCallback, int iconSrc, String desc) {
CustomPayDemo.CustomPayDialog customPayDialog = new CustomPayDemo.CustomPayDialog(activity, money, R.style.MyAlertDialog, iconSrc, desc);
customPayDialog.addPayResultListen(payCallback);
customPayDialog.show();
}

/**
* STEP 3: confirm pwd input and check pwd
*
* @param activity
* @param pwd
* @param data
* @param result
*/
private void checkPwdAndPay(Activity activity, String pwd, JSONObject data, AsyncResult result, String payModel, String payModelId) {
if (checkPassWord(pwd)) {
requestPayment(activity, data, result, payModel, payModelId);
} else {
JSONObject ret = new JSONObject();
try {
ret.put("errMsg", "bad pwd ");
} catch (JSONException e) {
}
result.onReceiveResult(false, ret);
activity.finish();
}
}

private boolean checkPassWord(String pwd) {
return "666666".equals(pwd);
}


/**
* STEP 4: request payment
*
* @param activity
* @param data
* @param asyncResult
*/
private void requestPayment(Activity activity, JSONObject data, AsyncResult asyncResult, String payModel, String paymdelId) {
payApi.payOrder(data, new PayApiV2.PayCallBack() {
@Override
public void onSuccess(JSONObject result) {wei
String totalFee = result.optString("paymentAmount");
showPayResult(true, activity, totalFee);
JSONObject resultToJs = result.optJSONObject("data");
asyncResult.onReceiveResult(true, resultToJs);
}

@Override
public void onFailed(String errCode, String msg) {
JSONObject ret = new JSONObject();
try {
ret.put("errMsg", msg);
ret.put("errCode", errCode);
} catch (JSONException e) {
}
asyncResult.onReceiveResult(false, ret);
activity.finish();
}
}, payModel, paymdelId);
}

private void showPayResult(boolean success, Activity activity, String total) {
Intent intent = new Intent(activity, PaymentResultActivity.class);
intent.putExtra("success", success);
intent.putExtra("total", total);
intent.putExtra("isV2", true);
activity.startActivity(intent);
activity.finish();
}

private void showPayTypeList(Activity activity, double total, String rawData) {
Intent intent = new Intent(activity, PaymentMethodActivity.class);
intent.putExtra("totalFee", total);
intent.putExtra("rawData", rawData);
activity.startActivity(intent);
}


public void showPwdConfirm(Activity activity, int iconSrc, String desc, String model, String modelId) {
if (null != paymentRequest) {
AsyncResult result = paymentRequest.result;
JSONObject checkRet = paymentRequest.params;
try {
checkRet.put("appId", paymentRequest.miniAppContext.getMiniAppInfo().appId);
} catch (JSONException | NullPointerException e) {
}
showPwdDialog(activity, paymentRequest.payValue, (retCode, msg, dialogInterface) -> {
if (retCode == 1) {
String pwd = ((CustomPayDemo.CustomPayDialog) dialogInterface).getInputText();
Log.e(TAG, "onDismiss isComplete=" + pwd);
if (!TextUtils.isEmpty(pwd)) {
checkPwdAndPay(activity, pwd, checkRet, result, model, modelId);
} else {
Log.e(TAG, "empty pwd ~");
JSONObject ret = new JSONObject();
try {
ret.put("errMsg", "empty pws");
} catch (JSONException e) {
}
result.onReceiveResult(false, ret);
activity.finish();
}
paymentRequest = null;
}
}, iconSrc, desc);
}
}

public void notifyPaymentCancel() {
if (null != paymentRequest) {
JSONObject ret = new JSONObject();
try {
ret.put("errMsg", "cancel");
} catch (JSONException e) {
}
paymentRequest.result.onReceiveResult(false, ret);
paymentRequest = null;
}
}

private static class PaymentRequest {
public IMiniAppContext miniAppContext;
public JSONObject params;
public AsyncResult result;
public double payValue = 0f;

public PaymentRequest(IMiniAppContext miniAppContext, JSONObject params, AsyncResult result, double payValue) {
this.miniAppContext = miniAppContext;
this.params = params;
this.result = result;
this.payValue = payValue;

}
}
}

Operation process in the console

After completing the steps mentioned above, when a mini program or mini game joins the superapp, both the superapp and the mini program/mini game need to complete the merchant ID binding application and approval process in the console

For details on how to enable the payment feature in the superapp, see:
For details on how to request to bind a merchant account in a mini program, see:






Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No

Feedback

Contact Us

Contact our sales team or business advisors to help your business.

Contact Us
Technical Support

Open a ticket if you're looking for further assistance. Our Ticket is 7x24 available.

Submit a Ticket
7x24 Phone Support