Hello MTN MoMo team,
I'm reporting a sandbox issue that started around 7 July 2026 and that I've been unable to resolve through the usual troubleshooting. I'd be grateful for your guidance on the likely cause and the recommended next step.
Summary
My Collections product subscription shows Active in the portal, and its subscription keys are accepted by the API gateway — but every request that is passed through to the backend hangs and never returns, timing out after roughly 30 seconds. This affects token generation and API-user management alike, so I cannot obtain an access token or provision a new API user.
Behaviour observed (reproduced independently from two different networks using raw HTTP, so it is not specific to my application or hosting):
| Request | Result |
|---|---|
POST /collection/token/ — valid Collections key + existing API user | Times out (~37s), no response |
GET /v1_0/apiuser/{referenceId} — existing API user | Times out (~21s), no response |
POST /v1_0/apiuser — create a new API user | Times out (~27s), no response |
POST /collection/token/ — deliberately invalid key (control) | Immediate 401, "invalid subscription key" (~2s) |
| A Collection Widget key on a Collections endpoint (wrong product, expected) | Immediate 401 (~3s) |
The pattern is consistent: the gateway responds instantly whenever it rejects a request at the edge (invalid key, wrong product), but any request it accepts with my valid Collections key is forwarded to the backend and then receives no response at all. This points to the failure occurring on the backend behind the gateway rather than at the gateway or on my side.
Troubleshooting already completed
- I am using the Collections product's Primary key (not the Collection Widget key), consistent with previous guidance in this forum.
- Both the Primary and Secondary keys of the Collections subscription behave identically, so regenerating a key does not appear likely to help.
- Re-provisioning is not possible either —
POST /v1_0/apiuseralso times out, so I cannot create a fresh API user to replace the existing one. - This is not a payload/validation problem (e.g. invalid characters in
payerMessage); the failure occurs at the token step, before anyrequestToPaycall. - All of the above was reproduced with plain command-line HTTP clients, ruling out my application code, framework, and hosting environment.
Questions
- What could cause an Active subscription's backend to accept the subscription key but then fail to respond across both the token and API-user endpoints?
- Is there a known sandbox incident currently affecting the Collections product, or does this indicate that my subscription / API-user record is in a stuck state that requires a reset on your side?
- As a recommendation: would cancelling and re-subscribing to the Collections product be expected to clear this, or is that unlikely to help if the fault is server-side? Is there anything else you would advise trying first?
I'm happy to provide my account email, subscription name, and a sample reference ID privately to a moderator so you can inspect the affected records. Thank you for your time and assistance.