Payment aggregation vs. direct merchant contracts: what an ISP actually gains and loses
Sooner or later a growing ISP asks: should we stay on Netxol's aggregated payments or move to direct merchant contracts? Here is the honest trade-off analysis.
Netxol's payment collection layer lets a new ISP accept JazzCash, EasyPaisa, Mastercard and Visa on day one — as an aggregator. Every operator eventually asks the same question: at what point do we move to direct merchant contracts with each processor, and what do we gain or lose?
This is our honest trade-off framing. It is not a recommendation either way — the answer depends on the operator's scale and cash-management preferences.
What "aggregation" means, precisely
Netxol contracts with the payment processors (JazzCash, EasyPaisa, Mastercard, Visa acquiring banks) as the merchant of record. Subscribers pay Netxol; Netxol settles net to the operator on the licence-agreement schedule. See the specifics on the [Billing module page](/products/modules/billing) and the [JazzCash / EasyPaisa post](/blog/jazzcash-easypaisa-for-isps).
What "direct merchant contracts" means
The operator signs merchant agreements directly with each processor. Subscriber payments flow to the operator's own account. The operator is responsible for reconciliation, dispute handling, PCI compliance for card acceptance, and settlement to their own book. Netxol Billing continues to reconcile payments to invoices in either mode — the difference is the money flow and the contractual counterparty.
The trade-off, one row at a time
| Metric | Before | After | Δ |
|---|---|---|---|
| Time-to-first-payment | Direct · weeks–months | Aggregation · day one | — |
| Cost per transaction | Direct · slightly lower | Aggregation · slightly higher | — |
| Settlement latency | Direct · often faster | Aggregation · T+1 to T+2 | — |
| Reconciliation effort | Direct · reconcile per-processor | Aggregation · Netxol reconciles | — |
| Dispute handling | Direct · operator handles | Aggregation · Netxol handles | — |
| PCI DSS scope (cards) | Direct · full scope for the operator | Aggregation · Netxol carries scope | — |
| Regulatory reporting | Direct · operator to processor | Aggregation · Netxol consolidates | — |
| Contract volume | Direct · 4+ merchant contracts | Aggregation · 1 with Netxol | — |
When to consider direct
Direct usually becomes attractive at the point where per-transaction fee differential × monthly volume exceeds the cost of the operational overhead (reconciliation, dispute handling, PCI scope). For most Pakistani residential FTTH operators under 100K subscribers, that crossover is later than they expect — the operational overhead is real. Above 100K, direct starts to make sense for the highest-volume processors first (usually JazzCash + EasyPaisa in Pakistan).
A hybrid model that works
Many operators land on a hybrid: direct for the highest-volume processor, aggregation for the long tail. Netxol supports this — the platform is agnostic to whether a given method is aggregated or direct, and reconciliation to invoices continues either way.
On PCI DSS
If you take direct card acceptance, the operator inherits the PCI DSS SAQ D scope. This is not trivial. Under aggregation, Netxol carries the PCI scope and the operator inherits SAQ A (much narrower). Talk to your compliance advisor before switching.