Definition
Payment Gateway is the intermediary layer connecting merchants and payment channels. It is responsible for processing payment requests, routing to banks or card networks, and returning transaction results. In the context of the International IoT Cloud Platform (ICMP), the Payment Gateway integrates mainstream payment channels, supports credit cards, debit cards, bank transfers, LPM local payment methods, and complies with PCI DSS and 3D Secure security requirements.
Working Principle
As the hub for transaction processing, the Payment Gateway receives payment requests from the ICMP platform (such as SIM orders, data package purchases, or monthly fee settlements), encrypts sensitive information like card numbers and amounts, and forwards it to the acquiring bank or payment network. After authorization by the acquiring and issuing banks, the gateway returns the results to the platform and supports asynchronous callback notifications. In cross-border scenarios, the gateway also handles multi-currency conversion, cross-border billing, exchange rate locking, etc., and works with Multi-Currency Settlement to achieve global settlement.
Use Cases
In ICMP, the Payment Gateway supports multiple payment scenarios: SIM card and eSIM orders—customers purchase IoT SIM cards either one-time or in bulk; Data package and data plan renewals—subscribed monthly or by usage, supporting automatic deductions; Cross-border enterprise settlements—enterprises deploying devices in multiple countries need to pay in local or unified currency; Dealer and Reseller prepayments—distributors top up in bulk and then distribute to downstream customers. The platform can configure the availability of different payment methods in different regions, adapting to Data Localization and local regulatory requirements.
Practice in ICMP
SimtoLink ICMP's Payment Gateway connects with mainstream international payment service providers, supporting Visa, Mastercard, UnionPay, and local LPM. The platform uses tokenized storage; card information is tokenized by the gateway and no longer stored locally, reducing the PCI DSS compliance scope. High-value or cross-border transactions can trigger 3D Secure verification, balancing security and conversion rates. Combined with Unified Invoice and Usage Analytics, payment data can be traced and reconciled, meeting corporate financial and audit requirements.
Authorization and Business Posting Are Separate Steps
Inside connectivity management, a payment gateway receives an order, a renewal, or a settlement request, hands the necessary payment information to the acquirer, and returns authorization, refusal, or timeout to the platform. It does not decide which product a SIM should be provisioned with, and it does not calculate the traffic charge. The platform should keep the business order and the payment attempt as two records. The order says what is being bought. The payment attempt says whether this authorization succeeded, what the channel reference is, and what the amount and currency are. Only when payment reaches the agreed state does the order move on to provisioning or posting. If a conversion is involved, the rate should cite a timestamp already fixed in FX management. Display text on the gateway page does not decide it for one transaction.
Use a gateway when every business action has a unique order number, and a repeated notice for the same order does not provision twice. An asynchronous callback can arrive later than the result the user sees on the page, and it can arrive more than once. The platform should treat the order number plus the channel reference as idempotent, and write the final state into the audit trail. On timeout, do not both show the user a failure and quietly provision when the callback arrives. Refunds, chargebacks, and partial collection need their own states. They cannot all be folded into “payment failed.” Extra verification required for a high-risk transaction should finish before authorization completes, not be added after provisioning.
A Successful Receipt While the SIM Is Not Provisioned
A common error is to write the gateway’s “success” directly as the SIM already activated. A successful authorization only means the funds side accepted this request. Provisioning on the carrier side can still fail. The order should then enter compensation: either finish provisioning, or start a refund, and leave the order in a state that can be explained. Another error is to store only the result of the page redirect, and not check the asynchronous notice or the next day’s channel settlement file. After the user closes the page, a success notice can still arrive, while stock has not been reduced.
If a test-environment merchant ID is configured into the production callback address, a real order is recorded on the test ledger. A mismatched amount or currency, or a decimal precision that differs from the channel, also produces “the channel succeeded, the platform judged it a failure.” Acceptance of a payment-gateway integration should cover five paths: success, refusal, timeout, a repeated notice, and provisioning failure. Each path should be traceable from the order to the channel reference, and then show which step the SIM, the invoice, and the refund are each in.
Authorization and capture can be two steps. Authorization only holds or confirms that the payer accepts this amount. Capture is what moves the money. Provisioning a long-running service on authorization alone means the service has already been delivered if capture later fails. The product rule should say after which step provisioning is allowed: authorization only, authorization and capture, or funds cleared into the account. If a renewal uses a payment credential saved earlier, an expired credential must be found before capture, and the customer should have time to remedy it. Do not terminate every SIM immediately after a failed capture.
A repeated click, a page retry, and an asynchronous notice on the same order produce several channel records. The platform folds them, by order number, into one business result. Success follows the first confirmed capture. A later duplicate notice does not provision again. A notice whose amount or currency does not match the order goes to a manual difference. It is not automatically treated as success. If a timed-out order receives a late success notice after the SIM has already been released to someone else, do not provision the original SIM. Move it to a refund.
The reconciliation file arrives on the channel’s settlement day. Fees, chargebacks, and refunds in it should return to the original order. A channel reference that does not match is held on its own. Do not back into the difference from usage. Keep the notice address, the key, and the order prefix of the test merchant and the production merchant apart. If a production order fails signature verification with a test key, reject it and raise an alert. Do not skip verification and post it.