Definition
A payment callback is the asynchronous notice a payment channel sends to the platform after a user completes WeChat Pay or Alipay. When the platform receives the callback, it updates the order status and triggers linked actions such as plan issuance and reactivation. Processing must be idempotent so the same notice is not executed twice.
Callback Process
After the user pays successfully, the WeChat or Alipay server sends a POST request to the callback URL configured on the platform. The request carries the order number, payment transaction number, payment amount, and payment status. The platform must: ① verify the signature so the request is known to come from the payment channel; ② look up the order by order number and check the amount; ③ handle idempotency (the same payment may produce several callbacks, so duplicates are removed by payment transaction number); ④ mark the order paid and trigger the next steps (plan issuance, reactivation, payment splitting, and so on).
Notes
- Asynchrony: A callback is an asynchronous notice and may be delayed by a few seconds. The front end must get the payment result by polling or WebSocket, and it cannot rely on the callback alone.
- Retry: If a callback gets no response, the payment channel retries it several times. The platform must return success quickly (for example, 200 OK) and run the business logic asynchronously.
- Security: The signature must be verified. A forged callback can create a funds risk.
Callback and Business Linkage
After a payment callback succeeds, the platform must run a chain of actions: mark the order paid, run plan issuance, run reactivation if the card is in arrears, and call the split API if payment splitting is connected. Each step has to complete reliably, because a failure at any point affects the user. A message queue is a sound way to process this asynchronously and retry failures. Callback handling must be idempotent: several callbacks for the same payment run the business logic only once. The payment callback is the core hub of the IoT SIM card data-plan subscription flow.
Payment Callback and Orders
A payment callback must match the order by order number and payment transaction number, and it must confirm that the amounts agree. The order must record sales attribution so settlement and profit sharing or payment splitting can use it. After a successful callback, plan issuance calls the operator API according to the operator mapping, and reactivation restores network access for a suspended card. Under the B2B2C model, the payment callback is the key step in “pay and the card reactivates,” and it must be reliable and idempotent.
Callback Processing
A payment callback must verify the signature so the request is known to come from WeChat Pay or Alipay. It must also be idempotent: several callbacks for the same payment run the business logic only once. A message queue is a sound way to process this asynchronously and retry failures. The handler should return success quickly (for example, 200 OK) while the business logic runs asynchronously. The payment callback is the core hub of the IoT SIM card data-plan subscription flow, and it stays tightly linked with plan issuance and reactivation.
Fields the notification must match
In card management, a payment callback is not permission to open service just because the payload contains the word success. An asynchronous notice from the channel has to line up on four points. The merchant order number must find the pending order on the platform. The priced amount must match the amount on that order, and when the unit is fen the conversion between yuan and fen must not be reversed. The trade status must be payment success, not in progress, closed, or already moved into a refund. The channel transaction number can be the idempotency key, so a repeated delivery of the same number is allowed to run plan issuance and reactivation only once. If the notice time is far from the time the order was created, query the channel first, confirm the money was actually received, and only then change the card status.
The gate is a single test: the signature passes, the order is still awaiting payment or has already been handled for this same transaction, the amount matches, and the status is success. All four must hold before provisioning starts. If the signature fails or the amount does not match, keep the original payload and the failure reason, and do not change whether the card can go online. Reactivating a card that was underpaid consumes data with no matching receipt. Refusing to provision an overpayment makes the user pay again, and reconciliation later shows more than one payment on one order.
Which arrives first: page polling or the async notice
After the user pays on the self-service page, the page usually polls the order first. The asynchronous notice may arrive seconds later, and if the channel never gets a clear response it retries on its own schedule. Connectivity management should keep “payment confirmed” separate from “plan delivered and the card is back online.” Until the notice arrives, the page can only say the payment result is being confirmed. It must not draw the card as already reactivated. If the notice arrives first and the carrier suspend-or-resume API times out, the order should still be recorded as paid, and provisioning should enter a retry queue, so the user does not assume failure and pay a second time.
If the processing thread blocks while waiting on the carrier API, it can miss the channel’s reply deadline, and the same payment is delivered over and over. A callback address pointed at an internal host, a wrong path, or a certificate hostname that does not match shows up as endless channel retries while the platform order stays unpaid. Verifying a production notice with a sandbox key marks every real payment as forged. If refund notices and payment notices share one entry point and are not branched by transaction type, an order that was already refunded can have its plan delivered again.
Where the payment notice lands in SimtoLink connectivity management
SimtoLink attaches the payment result to the card business loop. After the notice passes signature checks, the platform delivers the plan using the card identity and the plan on the order. If that card is suspended for nonpayment, reactivation follows. A split order can name receivers on the same payment, but a failed split call must not roll back a collection that already succeeded. It should go into a makeup split, so the user is not left having paid while the card is switched off. At day end, look up the notice by the transaction number on the channel bill, and check that the amount received, the amount split out, and the plan effective time close.
This sits on SimtoLink payment integration. Keep the original notice, the signature result, the order number, and the later provisioning result in separate records, so an investigation can tell “money received, card not opened” from “card opened, and the channel has no such collection.”