Definition
WeChat Pay is a commonly used payment channel on the IoT Cloud Platform, supporting Native QR code scanning, JSAPI (Official Account), H5, Mini Program, APP, and other scenarios. After the payment callback is successful, it triggers data plan issuance and device reactivation . It supports payment profit sharing , automatically distributing the payment proportionally to agents and distributors after the order is paid.
Access Scenarios
- Native Payment: Generate a payment QR code, and the user scans to complete payment. Suitable for PC and offline scenarios.
- JSAPI Payment: Invoke WeChat Pay within the Official Account. The user needs to follow the Official Account and complete authorization.
- H5 Payment: Redirect to the WeChat Pay page within the mobile browser, no APP installation required.
- Mini Program Payment: Embedded payment within WeChat Mini Programs, requiring binding to a WeChat merchant account.
Profit Sharing Capability
WeChat Pay supports the profit-sharing function, which requires enabling the profit-sharing permission. Add profit-sharing recipients (WeChat merchant accounts of agents and distributors or special merchants) as profit-sharing parties, configure the profit-sharing ratio , and after the user's successful payment, the amount is automatically distributed proportionally to each recipient without manual transfer, improving settlement efficiency.
Key points for integration implementation
The WeChat Pay merchant platform provides payment products such as Native, JSAPI, H5, Mini Program, and APP. Before integration, merchant authentication, product contract signing, and API key configuration must be completed. Payment callbacks need to verify the WeChat signature and implement idempotent handling. The sandbox environment can be used for joint debugging. Similar to Alipay, it is recommended to integrate both channels to cover user preferences. In IoT SIM card data-plan subscription scenarios, after the user successfully pays, the callback triggers data plan issuance and reactivation , ensuring the payment takes effect immediately. Profit sharing requires prior application, and the profit-sharing recipient must complete merchant relationship addition.
WeChat Pay and business closed loop
In the B2B2C model, C-end users subscribe to data plans through user self-service and choose WeChat Pay. After successful payment, the payment callback notifies the platform, and after the platform verification passes, data plan issuance and reactivation are executed. If payment profit sharing is enabled, the payment is automatically distributed to the profit-sharing recipient according to the profit-sharing ratio . Integrating both WeChat Pay and Alipay can cover different user preferences, improving the C-end payment experience and the reliability of "payment-triggered reactivation" on the IoT Cloud Platform .
Access Scenarios
WeChat Pay supports scenarios such as Native Scan, JSAPI (Official Account), H5, Mini Program, and APP. Before integration, merchant authentication, product signing, and API key configuration need to be completed. Payment callbacks require verification of WeChat signatures and implementation of idempotent processing. It is recommended to integrate with Alipay as a dual-channel approach. In IoT SIM card data-plan subscription scenarios, after a user successfully pays, the callback triggers data plan delivery and device activation , making the payment effective immediately.
Order parameters cannot be copied across payment scenes
In card business, WeChat Pay is one channel through which a user pays for a plan. The specific product has to be chosen for the environment the page is in. A computer or an in-person display uses a QR code. Inside an official account, use the web invocation for that account. A mobile browser uses a jump that does not depend on a client being installed. Inside a mini program, use mini program payment. The wrong product lets the user see the amount and then fails to open the checkout at the last step. Each product needs its own rule for the merchant order number. The order number corresponds to one card and one plan, the amount is in fen, and it matches the platform order. The description field should carry the last few digits of the card number, so the user can tell in the payment history which device was topped up.
Before the order is placed, the card must still be allowed to renew. Not yet real-name registered, suspended for a violation, or a plan already delisted should all be refused before payment is invoked. Paying first and then discovering that provisioning is impossible turns the transaction into a successful payment that must be refunded. The open-platform application identifier, the merchant number, and the callback address have to belong to one configuration set. A notification address from the test environment must not be left on the production merchant.
Success, close, and refund each have their own status
If the user cancels payment or it times out, the order stays unpaid and is closed. Quota or stock that was frozen has to be released. A cancellation is not a failed refund, because the money was never received. Payment success only moves the order to paid. Provisioning can still fail. A provisioning failure goes to refund, and the refund has its own states: requested, processing at the channel, and returned. Before the refund is complete, the card should not be provisioned again by the same order, and the user should not pay for the same plan again without being told that the previous payment is being refunded.
A split is an extra instruction on this successful payment. A delayed split does not affect the judgment that the order is paid. When SimtoLink connects WeChat and Alipay collection, it chooses the payment product for the page environment, binds the channel transaction back to the card order with the merchant order number, and then decides on delivery, reactivation, or refund.
A closed merchant order number cannot be paid again
After the user cancels or the payment times out, the original merchant order number is already closed on the channel side. Placing another order with the same number is refused by the channel, or the old closed status is synced back. If the platform treats that as a new payment and provisions, provisioning fails and there is no new transaction. Paying again must generate a new merchant order number, linked to the same card and the same plan intention. The old number is kept only as closed. If the amount changed because the plan was adjusted, the old number must not be reused either. In WeChat collection, SimtoLink starts the next checkout with a new order number. The channel transaction, the close record, and the refund each hang on their own order number, and they do not cross into the next payment. The amount is checked in fen. A difference of one fen from the platform order does not provision. If notice signature verification fails, keep the payload only. A page that jumps back is not treated as payment success.