The transaction succeeded and my internet got cut off
A renewal payment cleared at the bank, cleared at NCHL, and still could not be activated. What that episode taught me about digital payments reconciliation in Nepal.
2 min read
I renewed a CG NET internet subscription through connectIPS. The transaction succeeded, the amount left my account, and the plan was never activated.
When I reached out to support I got days of canned responses and no progress. I contacted my bank directly; they confirmed the payment and gave me the official transaction statement. I contacted NCHL; same thing. I handed that evidence back to the provider. They told me they hadn’t seen the payment and would check with finance tomorrow. Then they told me the same thing again. Then the internet got blocked anyway.
The technical shape of the failure
I have spent a decade inside banking systems, and this episode is recognisable. It is not really about support.
- 01
The payment clears at the source
Funds leave your account with a reference. That reference is the only thing connecting the two systems.
- 02
It lands in a settlement file somewhere
Usually overnight, usually batch, and usually reconciled against a reference the other side generates independently.
- 03
The two references do not match
Different formats, different truncation, different casing, a missing field. Nothing is wrong. The join simply fails.
- 04
Nothing is activated, and nothing errors
A failed join is silent. From the provider side, an unmatched transaction is indistinguishable from a customer who never paid.
Why “send us the bank statement” cannot fix it
This is the part that frustrates me most, because it is well-intentioned and useless. A bank statement proves the money left my account. It says nothing about whether the provider’s reconciliation matched it to a subscription row.
What would have helped, in order of usefulness:
- A searchable transaction status against the payment reference
- A statement showing whether the credit was matched, unmatched, or unmatched-then-reversed
- A named owner for the settlement exception queue
- An SLA on “we’ll check with finance tomorrow” that means something
The systemic point
Digital payments in Nepal have come a long way. What is left is the unglamorous half: real-time reconciliation with the clearing house, and a support team with the visibility to answer a question from evidence instead of a script.
Where the gap is
- Payment succeeds, activation does not
- The mismatch is discovered by the customer
- Provider asks the customer for bank evidence
- The customer chases two institutions to be believed
What good looks like
- Payment matches automatically, activation is instant
- Mismatches raise an internal exception immediately
- The provider already holds both sides of the reference
- The customer is told the status without making a call
The uncomfortable bit
Every part of this is a solved problem. There is no novel engineering involved. Batch matching, exception queues, reference normalisation — all of it has existed for twenty years and is routine in any bank with a decent operations team.
What it takes is not technical capability. It is the decision to own the reconciliation rather than leaving it as a step nobody has volunteered for, and a support team that is allowed to see the same data the operations team sees.
On this page
Related reading
I got paged for a DNS outage that was a laptop on hotel wifi
A short post about the incident that taught me to check the physical layer first, and the monitoring rule I added afterwards.
1 min readincident · dns
Runbooks nobody follows are just documents
Why my first six runbooks failed, and the rewrite that cut incident resolution time roughly in half.
2 min readincident · runbooks
Deploying a Cloudflare Worker for a Nepali SaaS, and what surprised me
Latency numbers, D1 versus Postgres from Kathmandu, and the three assumptions that turned out to be wrong when I moved a client onto Cloudflare Workers.
2 min readcloudflare · workers