Scenario
In vending machines, franchise stores, and shared devices, a single user payment needs to be split among the brand owner, venue owner, and service provider. Revenue sharing is completed at the clearing layer by a licensed payment institution according to the agreement to avoid illegal secondary clearing by the platform. The proportion, cycle, and refund reversal rules must be clearly specified in the contract.
System Integration
IoT terminals only generate order numbers and amounts; the revenue-sharing logic is handled in the cloud. Idempotent and reconciliation interfaces are needed to prevent duplicate revenue sharing.
Compliance
Funds must not be illegally pooled; merchant onboarding and KYC must be genuine.
Key points for IoT terminal-side design
Vending machines, charging stations, and shared devices usually only send order numbers, amounts, and merchant identifiers to the cloud and do not participate in profit-sharing calculations, in order to reduce firmware complexity and compliance risks. Terminals must ensure clock synchronization, anti-replay measures, and orderly uploading of offline queues to prevent the same transaction from being shared multiple times under weak network conditions. If a device supports multiple payment methods, it should locally record the payment channel and settlement number to facilitate reconciliation with licensed institutions in case of disputes. When module communication fails, successful deduction records should not be silently discarded but should be persisted and retransmitted once communication is restored; otherwise, accounting gaps such as "user has paid, profit-sharing missing" may occur.
Refunds, profit-sharing reversals, and taxation
When a user requests a full or partial refund, the payment institution must reverse amounts owed to each party according to the original profit-sharing path, and the platform must handle the red flush and financial vouchers for both invoiced and non-invoiced situations. Long-term profit-sharing agreements may involve tiered ratios and minimum guarantees, and the system must support recalculation and compensation on a periodic basis. Multi-entity profit-sharing affects the VAT, income tax, and invoicing cycles of all parties' legal entities. Legal and finance departments should specify invoice titles, tax responsibilities, and reconciliation cycles in contracts to prevent terminals from focusing solely on connectivity while neglecting the closed-loop of the financial chain.
Engineering Practice Supplement
Cross-team collaboration for "payment profit-sharing": Hardware provides impedance and power budgets, RF provides spurious emissions and sensitivity margins, embedded systems specify thread models and storage lifespan, and cloud specifies SLAs and rate limits. For scenarios like NB-IoT, the business model must match wake-up cycles, packet lengths, and downlink capacity; for vehicular and mobile scenarios, session persistence during handoffs and roaming must be considered. At project closure, perform a "red team" review: check whether weak networks, power loss, expired certificates, clock jumps, and full storage have defined behaviors.
Where Split Rules Run, and Where the Terminal Stops
A split means a payment that has already succeeded is divided, at the settlement layer, among the parties, ratios, or fixed amounts agreed in advance, and booked as receivables for the brand, the site, and the service party. The party that executes it is a licensed payment institution, or a clearing function that institution accepts. It is not the cellular module in the vending machine. The terminal has to provide a stable order id, amount, merchant id, and payment-channel id, plus a local record that can be uploaded after a disconnect. If ratios, tiers, and floors are written into firmware, every commercial change needs a reflash, and when the device's number disagrees with what the institution actually received there is no authoritative source.
The conditions of use are that every party has completed a real onboarding, the split agreement is in force on the institution side, and the refund rule exists as a pair with the forward rule. The terminal clock must be able to sync, and the offline queue must upload in the order the business happened, not in the order reconnects succeeded. When the module retransmits the same order on a weak network, the cloud must treat the order id as idempotent, and the institution must reject a second split request. Opening splits without those conditions leaves a gap: the user has paid, and one party's books have no record.
Refund Reversal Order and the Idempotency Key
The easiest error is to refund the user and not reverse, along the original path, the amounts already split to each party. A partial refund is harder. If the reversal uses the latest ratio instead of the ratio of the original transaction, a party who joined later is over- or under-debited. Another error is to treat the "payment succeeded" callback as the only trigger. If the callback is lost, the split never happens, and the recovery job does not share an idempotency key with the first request. The day the link returns, a batch of catch-up splits creates duplicates.
If the device keeps the channel transaction id, a dispute can be ticked off against the institution statement line by line. If it keeps only the amount, an order that crosses midnight collides with another terminal. The split result still has to enter the end-of-day match; the basis is in settlement and reconciliation. For a dynamic code, the order id must exist when the code is issued, not be invented after payment succeeds. Otherwise the callback in QR code payment cannot find the payment that is waiting to be split.
A split request should also carry the original payment's channel transaction id, not only a sequence the terminal generated. The channel id is the key the institution can use to locate that money uniquely. A terminal sequence can repeat after a factory reset or a clock step backward. A partial refund must say which forward split it reverses, and whether it uses the ratio at that time or the remaining unrefunded amount. Pick one and fix it in the agreement. An empty refund message lets the institution guess from a default policy. When a tiered ratio takes effect across a day boundary, orders not yet finished before the effective time still follow the old rule. Otherwise the same payment is recomputed at the new ratio on the day it is recovered. If the terminal's offline queue uploads the refund before the original payment, the cloud should hold the refund until the forward record appears. It must not book the refund as an independent negative split. Until the forward record arrives, the refund stays pending and is not posted.