Process
After payment is successful, the acquiring institution will settle the funds to the merchant account on T+N days, with fees charged separately. Reconciliation involves comparing the channel statement with the platform order database to handle cases where payment was successful but delivery failed, duplicate notifications, and refund discrepancies. IoT device orders are large in quantity but small in amount, relying more on automated scripts and anomaly alerts.
File Format
The CSV/Excel fields vary by channel and require mapping and total verification. Transactions spanning multiple days are based on the channel's settlement date.
Risk Control
Long and short amounts exceeding the threshold require auditing; prevent internal tampering with order status.
Reconciliation strategy for massive small IoT orders
Scenarios like vending machines, shared devices, and charging stations have extremely high order volumes with low individual amounts, making manual reconciliation impractical. The system should load reconciliation files partitioned by channel, merchant, and settlement date, performing a total amount check first, then detailed matching; establish separate queues and SLAs for anomalies such as "payment successful but not delivered" and "delivery successful but not paid." For cross-day transactions, the channel settlement date is the reference; platform order timestamps may not align with local device clocks, requiring unified time zones and daylight savings rules. When IoT devices cache orders offline, late success callbacks and duplicate notifications must also be handled to avoid duplicate or missing entries in reconciliation.
Financial closure and audit requirements
Reconciliation results should generate exportable vouchers: channel transaction numbers, fees, net amounts, and merchant receivables, and link with ERP or financial platform voucher numbers. Long and short amounts should be distinguished by technical reasons, operational reasons, and suspected fraud, handled through automated adjustments or manual approval respectively. Internal and external audits commonly sample methods and exception handling ratios; logs must retain operator and reason explanations. When involving split accounts and multi-party settlements, receivables and invoiced amounts for each beneficiary must also be verified to prevent compounded tax and financial risks.
Engineering Practice Supplement
Integrate "settlement and reconciliation" with the full lifecycle of modules: EVT stage verifies reference design and antenna solutions; DVT stage conducts conduction/radiation surveys and thermal imaging; PVT stage finalizes calibration and test scripts. Before certification, verify target country regulations and operator import requirements to avoid missing frequency bands or SAR items. Production lines should retain golden sample comparisons and inspection rules; after-sales should be able to trace software versions, calibration parameters, and key component batches by serial number. If remote maintenance is requested by the customer, security upgrades, rollback, and emergency shutdown strategies must also be designed simultaneously.
Settlement Day-Cut and the Device's Local Day-Cut
Settlement is the transfer of funds among the channel, the institution, and the merchant on a settlement cycle. Reconciliation, before or at the same time as that transfer, uses the channel detail to find each platform order. What matches enters the net. What does not match becomes a long or a short. A long means the channel has the money and the platform has no corresponding order. A short means the platform believes success and the channel has no such transaction. IoT devices produce many orders of small amount. The end-of-day file must match total amount and count first, then the lines. Otherwise one parse error marks the whole day as a difference. The device clock, the platform receive time, and the channel settlement day are three times. A transaction that crosses the day follows the settlement day in the channel file, not the time the module reported.
The condition of use is a fixed field mapping for each channel, an order id that is unique when the terminal creates it, and refunds that can point at the forward payment. Orders a terminal uploads after it comes back online should be marked late and enter the next round or a named settlement day. They must not rewrite a day that has already been closed. Fees and net amount are separate columns. Matching only the amount the user paid is not enough.
Double Booking from a Late Callback
The most common error is a success callback that arrives twice. The first has already dispensed and been booked. The second is taken as a new order. If the idempotency key is the module's retry count rather than the channel transaction id, a catch-up upload is necessarily a duplicate. Another case is payment succeeded and dispense failed: the money is at the channel, the goods did not go out, and the reconciliation program looks only at payment status and calls it balanced. The short stays in the complaint queue. A third is a refund that reverses against today's orders while the original transaction sits on the previous settlement day. The reversal cannot find the original entry and becomes a permanent long. If an internal user can change order status with no reason and no operator record, the external file can balance and the books are still not trustworthy.
Multi-party shares are split after the match, not by a ratio the terminal computed in place of what the channel actually distributed; see payment split. When a code and a bank card share one result bit, the channel file does not match the local order. The acceptance difference is in QR code payment.
The end-of-day job should lock the settlement day before it accepts late data. A success callback that arrives after the lock enters the next day or a pending queue, and keeps the original channel transaction id. It must not rewrite a net that has already been issued. When the totals do not match, stop automatic line matching first, so a bad parse does not generate thousands of false differences. Payment succeeded and not dispensed, dispense succeeded with no channel record, and duplicate notifications should be three queues, with different time limits and owners. A refund must point at the original entry on the original settlement day. If the original entry cannot be found, treat it as an exception rather than forcing a negative revenue entry. When an operator changes order status, a reason is required. Otherwise the external file can balance while the inside has still been edited. Store the channel-file version, the parse-rule version, and the close time in one record. A review the next month can then tell whether a difference came from a rule change or from a device catch-up.