Definition
Alipay is a payment channel the IoT Cloud Platform uses often. It covers the desktop site, the mobile site, the app, and the mini program. Paired with WeChat Pay, the two channels cover how most users prefer to pay. After a payment callback succeeds, the platform runs plan provisioning and resume. Alipay can also take a payment split.
Where the user pays
- Desktop website: The PC page redirects to the Alipay cashier. This fits the enterprise console and the agent portal.
- Mobile site or app: The page opens the Alipay app or the H5 cashier. This fits user self-service and payment inside a mini program.
- Mini program: Payment is embedded in an Alipay mini program. The mini program has to be opened and the merchant has to be verified first.
Why both Alipay and WeChat Pay
Connect both, so the user is not limited to one wallet. Both can run payment split, which is what a distributor needs when the share has to move at the moment of payment. Each channel needs its own merchant account, its own keys, and its own payment callback with signature checks.
What has to be in place before go-live
Alipay’s open platform sells desktop-website payment, mobile-website payment, app payment, and mini-program payment as separate products. Before connecting, the enterprise completes verification, signs the product, and obtains the application private key and the Alipay public key. The payment request is signed as the document specifies. The payment callback checks Alipay’s signature so a forged notice is rejected. The sandbox is for joint testing. Before production, security settings and the async notice address have to be in place. Like WeChat Pay, split is a separate product and needs its own application. On an IoT SIM plan order, a successful payment callback is what triggers plan provisioning and resume, so the plan is on the SIM only after the money is confirmed.
From the consumer payment back to the SIM
In B2B2C, a consumer orders a plan in user self-service and pays with Alipay. The payment callback tells the platform. After the check passes, the platform runs plan provisioning and resume. If payment split is connected, the payment is split to the distributor by the revenue-share rate. Offering Alipay next to WeChat Pay covers more of the wallets a consumer actually has, which is the consumer payment path on the IoT Cloud Platform.
Products to sign, and what the callback must do
Alipay can be the desktop site, the mobile site, the app, or a mini program. The enterprise still has to be verified, the product signed, and the keys configured. The payment callback must check the signature and treat a repeated notice as the same payment. Pair it with WeChat Pay rather than relying on one channel. For an IoT SIM plan order, the callback after a successful payment is what starts plan provisioning and resume. The plan should not be written before that notice is accepted.
A late async notice, and when the order counts as paid
In IoT SIM renewal, Alipay is not a cashier skin. It is an asynchronous result that says the user has paid. The browser returning to a success page is only a hint. It is not the booking. The order is booked when the notice arrives, the signature has been checked with Alipay’s public key, the merchant order number matches a local order that is awaiting payment, the amount and currency match, and the trade status is success. The notice may arrive minutes after the success page the user sees, and it may arrive more than once. The order should first sit as “payment processing,” and move to paid only after the signature check passes. The Alipay trade number is the idempotency key, so the same trade number cannot provision the plan twice. A difference of one cent should reject the whole order. The local order must not be rewritten to the amount in the notice. When SimtoLink connects WeChat and Alipay collections, website payment, mobile-website payment, and mini-program payment are different signed products. Mini-program payment cannot be called with the parameters of website payment. A merchant id that has not signed up for split payment should not send split parameters on the order, or the whole payment is rejected.
The split receiver has to be the channel on this order
In a distribution case, Alipay split payment moves funds to a bound receiver when payment succeeds. The receiver account, the binding, and the channel id on the order have to be the same master data. If the user renews a SIM under distributor A, but the notice splits the money to distributor B’s Alipay account, the funds are split wrong immediately. After the fact the only path is to reverse the split. Changing the local share rate cannot repair it. The split rate and the receiver list are frozen into the payment request at order time. They are not calculated when the notice comes back. If the receiver has not confirmed the relationship, or the rate exceeds what the channel is allowed, payment fails. The page should distinguish “the user did not pay” from “the split parameters were rejected.” An agent’s periodic settlement should not go through Alipay split payment, or the same renewal is split in real time and paid again at month end. A refund has to say whether it returns along the original split rates. Refunding only the user, and not the receiver, leaves the channel with share already taken on an order the user has cancelled.
Sandbox payment succeeds, but production never provisions the plan
A sandbox pass only shows that the message shape is roughly right. Production still has to confirm that the application is live, that the async notice address is a public formal domain that can be reached, and that the gateway allows Alipay’s notice source. If the notice address is an internal network, the user has already been charged and the platform never receives the result, so the SIM stays suspended. The user should not be asked to pay a second order. Look the order up at Alipay with the merchant order number, and if it is successful, catch up the provisioning and the resume. Lookup and the notice must go through the same booking code, so one path does not check the signature while the other skips it. Too much clock skew fails the timestamp inside the signature, so server time has to stay aligned with standard time. If payment succeeds but the SIM is already cancelled, or the plan is already off the shelf, provisioning should stop and the order should enter refund. A product code that no longer exists should not be written just to keep the idea that “payment means resume.”