I measured M-Pesa STK Push polling lag on a real device. The variance will ruin your UX.

Same code. Same device. Same network. Same shortcode. Test 1: 39 seconds from PIN entry to UI update. Test 2: 3 seconds. 13x variance. Not a bug. Not a fluke. Just the math of a fixed polling schedule colliding with a non-deterministic callback. When you fire an STK Push, Safaricom returns a CheckoutRequestID and ResponseCode: 0 almost immediately. Most developers celebrate this. It means nothing. It means Safaricom received your request. The customer hasn't seen a prompt yet. The actual payment outcome arrives later — via a POST to your CallBackURL . That callback takes 5 seconds or it takes 45. Safaricom doesn't tell you when it's coming. And if your server isn't reachable when it arrives, Safaricom does not retry. The delivery attempt is fire-and-forget. So the typical Flutter developer does what makes sense: they poll. Every 10 or 30 seconds, ask the server if anything happened. This works until it doesn't. My polling schedule fired at T+10s, T+30s, and T+70s. In Test 1, the callba