Safaricom messages we could not place

Delivery is confirmed by SMS, and the matcher only recognises wordings it has been taught. When Safaricom changes the phrasing, a real confirmation stops matching and the order sits waiting — which is how order #3316 ended up re-dispatched before anyone noticed. Marketing blasts are separated out; what is left is worth a look.

Stuck more than 10 minutes. If one of these lines up in time with a message above, they probably belong together.

Config vs what actually happened

Every completed order records its screen-by-screen walk, so the menu path each bundle really takes is already on file — hundreds of paid-for samples, free to read. Walks that hit an error screen are excluded: an order can complete off its SMS after the USSD wandered somewhere else entirely, and that path proves nothing. Single-string bundles cannot be checked this way — their log holds one generic acknowledgement that never names the bundle, which is exactly why the verification below exists.

Bundle verification

A verification dials a bundle's real Safaricom menu and stops on the confirmation screen — the one naming the bundle and price — without ever sending the keypress that buys it. That screen is compared against the catalog, so a moved menu option is caught before a customer pays for the wrong bundle. Menu navigation is free; only Accept spends money, and it is never sent.

A run is picked up by whichever gateway is free — a customer's order always goes first. Single-string bundles are switched off until the truncated dial has been tested by hand.

Learned USSD Steps

Every successful order teaches the system what each USSD screen looks like for that bundle. Once a step has been seen consistently it locks automatically and is then checked on every future order — so if Safaricom changes a bundle's value or moves a menu option, it is flagged instead of silently selling the wrong bundle.

Per-Gateway Breakdown

Possible Double Deliveries