Definition
Acquiring System (Acquiring System) is an integrated platform provided by acquirers for merchants to handle transaction acceptance, fund clearing, reconciliation, settlement, and risk control; it interfaces with issuing banks and UnionPay/NetUnion to complete authorization, clearing, and fund transfer. POS, aggregated payment, self-service checkout, and other access solutions must comply with PCI DSS, MLPS (Multi-Level Protection Scheme), and other requirements to protect cardholder data.
Typical processes include submission, authorization, clearing files, reconciliation, settlement, and error handling; it needs to uniformly handle bank cards, QR codes, NFC, ETC, and other methods while maintaining consistent accounting.
Technical Features
The system is mostly distributed with high concurrency architecture, requiring low latency and high reliability for transaction paths. POS and self-service terminals in shopping malls, parking lots, charging stations, gas stations, and other scenarios often rely on cellular return; when there is no wired connection or the link is unstable, IoT SIM cards are used to ensure transaction and reconciliation messages are delivered.
Use Cases
Smart retail, catering, parking, charging, highway service areas, etc.; EV charging stations, ETC, and mobile POS deliver transactions to the acquiring side in real time via cellular. SimtoLink can provide these terminals with stable network connectivity, dedicated APN, and data plans to support timely clearing.
Key points for cooperation with IoT SIM cards
- Dedicated APN or directional tunnel to converge north-south traffic, aligning with merchant/institution security domain policies.
- Device-card binding, remote suspend/resume, and abnormal traffic alarms to reduce the risk of misuse and side-channel recording after terminal loss.
- Ledger binding of ICCID with terminal serial number, merchant number, and installation point, facilitating reconciliation discrepancies and fault closure.
- Assess concurrency and online rate during peak and promotional windows; weak signal locations are pre-covered and operator alternatives are prepared.
Authorization delay and reconciliation files cannot share one path
On an IoT SIM, an acquiring system means splitting one sale into messages with completely different time limits. Authorization has to be answered while the cardholder is still at the terminal. Clearing and exception handling can run in batches. The reconciliation file is usually built at day end and is far larger than a single authorization. When a POS, a scan terminal, a self-service fueling point, or a charger reaches the acquirer over cellular, the SIM is the bearer between the terminal and the acquiring front end. It does not replace the card-scheme or clearing-network rules. Cardholder data should stay minimal on the terminal: a full track or card verification value should not travel in the clear on the cellular path, and it should not be written into the device log.
The conditions depend on whether the terminal is fixed or mobile. A fixed checkout that uses cellular as its main path should pin the egress address or use restricted access, so the acquiring front end can control who connects. A mobile POS must allow a reasonable change of place, but turning off device-to-SIM binding is not a reason to stop checking the terminal serial number. Size the plan by authorization count, not by video volume, and leave a separate window for the day-end file and parameter download. Concurrency on a promotion or a holiday should queue and time out at the front end. If every terminal retries without limit, the retries themselves fill the cell. A lost terminal, a repair replacement, and a merchant withdrawal all need to be stopped by ICCID, with the merchant id and install point left on the ledger. Otherwise a reconciliation difference cannot be tied to a device.
The easy confusion is “the terminal is online” versus “the sale succeeded.” A dial icon only shows that the bearer exists. An expired certificate, a clock skew, or a front-end refusal is what the customer sees as a failure or a double charge. Another error is to send the day-end file and live authorization down the same crowded default bearer. The file stretches authorization delay, the cashier sends the sale again, and several unsettled transactions appear. A weak spot that was tested only on install day will lose coverage after shelves, a cold cabinet, or an underground garage are rearranged, and drops look random. Acceptance should look at authorization time, whether reversals close, and whether the reconciliation file arrived, not only at one day’s transaction count. The terminal form is described under POS. Exit charging without a stop follows a different sequence from checkout authorization; see contactless payment.
Unsettled transactions need their own close limit. When cellular jitters, the terminal may treat authorization as failed and send a reversal while the front end has already posted. If the two sides do not share a retrieval reference for that sale, day end leaves a shortage or an overage. Send the reconciliation file in the authorization trough, with a batch number, and resume from the break instead of resending the whole package and blocking the next live authorization. Parameter and key download should also stay off the busy hours. An interrupted download must not leave the terminal on a half-set of keys. When a merchant pulls a device, sends it for repair, or changes the SIM, close the old serial number on the same ledger. Otherwise a machine on the repair bench can still submit sales to the original merchant id. A spot check should follow one receipt to the card number, the terminal id, and the clearing batch. When those three match, the cellular path really entered acquiring, not only a test address.
Test and production access points must stay separate. If a repaired terminal still points at the test address, the receipt looks normal and the funds never reach merchant settlement. A reversal and the original authorization use the same retrieval reference, and that reference must not be reused after the terminal loses power. If the day-end file is missing, resend the file. Do not rebuild a clearing result locally from the transaction log and present it as settlement. When the terminal serial number changes, stop accepting on the old number immediately, so two machines under one merchant do not interleave the same sale.