M-Pesa STK Push Failed During a Bitcoin Purchase: What to Check
A missing payment prompt, a recorded M-Pesa debit and a pending Bitcoin order are different stages. Check the existing attempt before approving another request.
On this page
Flutterwave's published M-Pesa example returns success for charge initiation while the payment itself remains pending. Those two statuses describe different stages. They do not describe two completed payments.
Its completed-payment example changes the payment status to successful. The distinction matters when a Bitcoin checkout appears to be moving forward but the M-Pesa prompt has not arrived.
When an M-Pesa STK push is not received during a Bitcoin purchase, establish the payment status first. Check whether money left your account before requesting another prompt.
The examples in the provider documentation explain a payment flow. They do not establish that Finlazo uses Flutterwave or that every Bitcoin checkout follows the same interface.
First separate the request, the payment and the Bitcoin delivery
An STK push is a payment-approval prompt. Receiving it is one stage of the order. Approving the payment and receiving Bitcoin are later stages.
The merchant needs to confirm the payment against the correct order. A debit can therefore require reconciliation even when a checkout screen has not updated.
| What you can observe | What it establishes | What to check next |
|---|---|---|
| Checkout says the request was sent | The site reports initiating a request | Correct number, phone availability and request status |
| A prompt arrives | There is a payment request to review | Business name, amount and whether it matches your order |
| M-Pesa shows a completed debit | Money left the account for the recorded recipient | Order reference and provider payment confirmation |
| Bitcoin appears in the stated destination | The delivery stage has been recorded there | Asset, amount and any separate withdrawal status |
A receipt and an order status answer different questions. Read both. A slow website update does not justify approving an unexpected second payment.
Check the payment safely in this order
Start with the existing payment record. Work through these checks before approving another request.
Check a missing or failed M-Pesa payment prompt
Establish the existing payment status, review the phone and order, and ask for reconciliation before authorising another request.
Check whether M-Pesa recorded a debit
Read the transaction confirmation and account activity. Match any completed debit with the recipient, amount and order. Keep the receipt. If money left the account, ask for reconciliation before approving another payment.
Confirm the number and active line
If no prompt arrived, compare the checkout number with your M-Pesa line. Check that the relevant SIM is enabled and has service. Use the number format accepted by the provider.
Match a received prompt to the order
Review the business name and amount before approving. Check that the request belongs to the order you intend to pay. Stop if the details differ. Keep your PIN private.
Check funds and applicable limits
Review the balance needed for the actual debit, including any customer-paid charge. Check the remaining payment allowance and provider order limit. Read the specific failure message.
Establish the previous request's final status
Use the provider's order page or official support. Confirm that the earlier payment did not complete before requesting a new prompt. Review any refreshed quote, amount and reference.
Ask for reconciliation if already charged
Give official support the order number, M-Pesa transaction reference, amount, time and error message. Ask whether the order is awaiting payment matching, execution or Bitcoin delivery. Do not send security secrets.
If no prompt arrived, check the number and phone
Compare the number entered at checkout with your active M-Pesa line. A number typed incorrectly can direct the request to another device or prevent the expected prompt.
Check that the relevant SIM is enabled and has service. On a dual-SIM phone, make sure you are checking the line associated with the order.
A working browser connection does not establish that the mobile line is reachable. Keep the phone available while the request is active.
Use the number format the provider accepts. Do not change prefixes by guesswork or substitute another person's account to make a request go through.
If the correct line remains unreachable, use Safaricom's official support. A provider can check the request it sent; the mobile operator can investigate the line's service.
If a prompt arrived, review it before entering a PIN
Match the business name and amount against the order. If the details differ, stop and ask the provider through its official channel.
Approve only the payment you intend to make. Enter an M-Pesa PIN through the genuine Safaricom payment interaction. A support agent does not need you to send the PIN in chat.
If the request expired or was cancelled, the provider may require a fresh request. First check for a debit and establish the previous attempt's status.
Avoid using an unexpected old prompt for a new order. The amount, reference or quote may no longer match the purchase you intend to make.
If M-Pesa was debited but the order remains pending
Keep the transaction receipt. Match its recipient, amount and time with the order you opened.
Flutterwave's verification documentation illustrates why a merchant checks the transaction's final status, currency, amount and reference before giving value. That is separate from merely creating a charge.
The provider should investigate whether payment reached the expected collection account and matched the order. Ask for a status check before paying again.
Payment reconciliation and Bitcoin delivery can be separate stages. If the provider confirms receipt, ask whether the order is awaiting execution, an account credit or an external-wallet transfer.
Do not assume a debit guarantees an immediate refund or Bitcoin delivery. The actual order record and provider process determine the next action.
Read the failure message rather than guessing the cause
Different systems can display different messages and identifiers. A generic failed-payment screen may conceal several possible stages.
| Observed problem | Practical check | Sensible next action |
|---|---|---|
| No prompt and no recorded debit | Number, active line and request status | Ask whether the request expired before creating another |
| Prompt rejected or cancelled | What the phone and checkout actually report | Confirm no completed payment, then follow retry instructions |
| Insufficient funds or a limit message | Balance including charges and applicable allowance | Review the order and payment limits |
| Recorded debit with no order update | Receipt, recipient, amount and order reference | Request reconciliation through official support |
| Payment confirmed but BTC absent | Stated delivery destination and order stage | Ask the provider to trace execution or delivery |
For the payment ceilings, read M-Pesa transaction limits when buying Bitcoin. A rail limit and a provider's order maximum are different.
This checklist does not assign a universal meaning to every error code. Share the exact message with official support rather than applying an unrelated code table.
Why repeated requests can complicate a small order
Consider a hypothetical KSh 5,000 payment request. Assume each repeated request is separately approved and produces a completed debit.
| Separately approved and completed requests | Assumed total principal debited |
|---|---|
| One | KSh 5,000 |
| Two | KSh 10,000 |
| Three | KSh 15,000 |
| Category | Value (KES) |
|---|---|
| One completed payment | 5000 |
| Two completed payments | 10000 |
| Three completed payments | 15000 |
All requests are assumed to be separately approved and completed. This is not an observed duplicate-payment rate, a failure statistic or a Finlazo checkout rule. Fees are excluded.
Source: Finlazo calculations; each assumed payment is KSh 5,000
Three completed debits would total KSh 15,000. That is KSh 10,000 above the intended single payment, before any charges.
The example does not claim that clicking retry automatically takes money. It explains why every new approval needs to be matched to a deliberate order.
What to send support, and what to keep private
Give the official provider the order number, transaction reference, amount, time and the error message. Explain whether the phone received a prompt and whether M-Pesa recorded a debit.
Provide receipts through the provider's secure support process. Avoid posting a full transaction record in a public comment or sending it to an unsolicited contact.
Keep your PIN, one-time security codes and wallet recovery phrase private. Those secrets are different from a transaction reference used for reconciliation.
If you paid a P2P merchant, use the platform's order and appeal process. A seller's WhatsApp promise is not the platform's final payment record.
Our M-Pesa versus P2P comparison explains why the payment recipient and verification process differ by purchase route.
Check the quote before making a fresh attempt
A replacement request may belong to a new or refreshed quote. Review the total KSh charged, asset, BTC amount and destination again.
Finlazo's Bitcoin with M-Pesa in Kenya page provides a reference for the route. The provider's current executable order establishes the actual payment and delivery terms.
A missing prompt is a reason to diagnose the payment stage. A recorded debit is a reason to reconcile the order. Both call for checking the existing attempt before authorising another.
Sources and methodology
- Flutterwave — M-Pesa payments. Published examples distinguish charge initiation, pending payment and completed payment.
- Flutterwave — Transaction verification. Merchant checks for final status, amount, currency and reference.
- Safaricom — M-Pesa transactions. Customer payment confirmation, balance checks and transaction records.
- Safaricom Daraja — M-Pesa Express. Official documentation entry for payment-request integration.
Sources were checked on 13 October 2026. No live Bitcoin order or STK request was executed. No nationwide failure rate, universal retry deadline or guaranteed refund time is claimed.
The chart multiplies an assumed KSh 5,000 payment by one, two or three separately completed requests. It is an illustration of repeated approvals, not evidence of how often duplicate payments occur.
