Kenya Payments Guide

Safaricom Bolsters M-Pesa Security with New Sender Verification Feature | Streamline

Payments in Kenya: M-PESA, Merchant Collections, and Mobile-First Commerce A customer reaches a gaming checkout, chooses M-PESA, and enters a mobile number. The payment prompt arrives late. The customer approves it and sees a debit confirmation, but the merchant’s system does not receive the expected callback. The order remains unpaid. Customer support asks the customer to try again. A second prompt appears, and the customer pays twice. The first callback then arrives after the second order has already been fulfilled. This looks like a single technical error. In practice, several small failures have compounded: * The checkout did not explain how the prompt would appear. * The merchant treated the callback as the only source of payment status. * The order system had no durable pending state. * The retry created a second payment request rather than recovering the first. * The fulfilment system was not idempotent. * Support could not independently query the original transaction. * The refund operation had not been designed before launch. That is the operational reality of accepting payments in Kenya. M-PESA makes it possible for a vast number of customers to authorize payments from a mobile account. It does not remove the merchant’s responsibility to coordinate initiation, authentication, confirmation, fulfilment, refunds, settlement, and reconciliation.

In March 2026, Safaricom reported that M-PESA had reached 40 million monthly active customers in Kenya. At the end of December 2025, the Communications Authority reported approximately 51.4 million mobile-money subscriptions, with Safaricom accounting for about 89% of that category. The Central Bank of Kenya separately reported 94.2 million registered mobile-money accounts in June 2026. These figures use different definitions: active customers, subscriptions, and registered accounts are not interchangeable and may include people with multiple accounts or SIMs. (Safaricom) The commercial conclusion is more important than any single total: In Kenya, mobile money is not simply another logo to add beside cards. It is a general-purpose commerce rail embedded in how customers receive money, move it, store it, pay businesses, settle bills, and manage everyday financial activity. Kenya generated approximately $135.9 billion in nominal GDP in 2025, with real output growing by 4.6%. Its population was estimated at 54.2 million by the Kenya National Bureau of Statistics for mid-2026, while the World Bank’s separate demographic series estimated 57.5 million for 2025. These measures use different methodologies and should not be blended without explanation. (World Bank Open Data)

For merchants, Kenya’s scale is amplified by unusually broad formal financial access. The 2024 FinAccess survey estimated that 84.8% of adults were formally financially included, with mobile money identified as a central driver. At the same time, purchasing power, connectivity, device capability, and digital skills remain uneven. A payment method can be nationally familiar without every customer using it in the same way. (Central Bank of Kenya) The appropriate market-entry position is therefore clear: Merchants pursuing mass-market digital commerce in Kenya should build a mobile-money-first checkout, place M-PESA prominently, preserve cards and bank rails for relevant segments, and design the complete operating journey before purchasing significant traffic.

Kenya payment snapshot Category Kenya market profile Region East Africa Population Approximately 54.2 million in the KNBS mid-2026 projection; the World Bank’s separate 2025 series estimates 57.5 million Currency Kenyan shilling, code KES, commonly displayed as KSh Nominal GDP Approximately $135.9 billion in 2025 Global economic position Around the mid-60s globally by 2025 nominal GDP, depending on dataset coverage and treatment of territories GDP per capita Approximately $2,363 in the World Bank’s 2025 series Real economic growth 4.6% during 2025 Financial inclusion 84.8% of adults were formally included in the 2024 FinAccess survey Mobile-money scale 51.4 million mobile-money subscriptions at December 2025; 94.2 million registered accounts and 572,104 active agents in the separate CBK series at June 2026 M-PESA scale 40 million monthly active customers reported in March 2026; approximately 89% of mobile-money subscriptions at December 2025 Mobile infrastructure Approximately 78.4 million SIM subscriptions, 51.5 million mobile-broadband subscriptions, and 48.7 million smartphones connected to networks at December 2025 Dominant payment categories Mobile-money merchant collections, account and bank transfers, cards, cash, and selected card-backed wallets Defining local method M-PESA Important collection flows PayBill, Buy Goods or Till, M-PESA Express or STK Push, dynamic QR, and structured business disbursements Card market

Approximately 13.3 million cards in June 2026, including 10.7 million debit cards, 340,778 credit cards, and 2.2 million prepaid cards Mobile-commerce relevance Essential for mass-market consumer reach Recurring-payment readiness More complex than one-time M-PESA authorization; customer-managed standing orders, cards, bank arrangements, and provider-specific mandates require separate assessment Local-settlement relevance High for M-PESA and domestic collection models Regulatory complexity Material because payment licensing, KYC, consumer protection, data protection, tax, cross-border contracting, and settlement interact Priority merchant verticals Gaming, digital goods, marketplaces, travel and mobility, education, SaaS, and subscription media Primary merchant takeaway Treat M-PESA confirmation, reconciliation, refunds, and repeat purchase as core product functions—not back-office additions Economic and connectivity figures in this snapshot come from KNBS, the World Bank, the Communications Authority, CBK, and the FinAccess survey. The Communications Authority’s device and subscription figures are supply-side indicators and do not represent unique individuals. (World Bank Open Data)

The mobile-money-first customer journey A Kenya payment strategy becomes easier to evaluate when it is treated as a sequence of operating decisions rather than a list of methods. The journey has seven stages: 1. Method discovery 2. Merchant and payment identification 3. Customer authorization 4. Payment confirmation 5. Order fulfilment 6. Refund or dispute 7. Settlement, reconciliation, and repeat purchase A failure at any stage can erase the accessibility advantage that M-PESA provides.

Stage 1: Can the customer find the method? A merchant can technically support M-PESA while making it commercially invisible. Common problems include: * Hiding it under “alternative payments” * Showing cards first to every customer * Using an unfamiliar generic wallet icon * Requiring the customer to begin a card form before local methods appear * Describing it simply as “mobile payment” * Displaying it only to customers with a perfectly resolved IP location * Removing it from lower-value transactions where it may be especially relevant For a domestic mass-market audience, M-PESA should generally appear among the first methods displayed. Cards may deserve equal or greater prominence for: * Foreign visitors * Internationally oriented SaaS buyers * Customers paying with corporate cards * Travel bookings * Automatic subscriptions * Higher-value cross-border purchases * Customers without an eligible M-PESA account The right arrangement is not M-PESA instead of cards. It is an eligible-customer checkout in which the method order reflects the customer and transaction. Recommended initial ordering For a domestic mobile customer: 1. M-PESA 2. Cards 3. Bank or account transfer 4. Other mobile-money methods 5. Relevant segment-specific options For a visitor-heavy travel merchant: 1. Cards and card-backed wallets 2. M-PESA 3. Bank payment for selected bookings 4. Pay-on-arrival or other approved options For a B2B platform: 1. Structured bank transfer or PesaLink 2. M-PESA PayBill 3. Cards 4. Invoice payment

Method ordering should ultimately be determined by eligibility, selection, completion, retained revenue, and support demand—not by a static country template.

Stage 2: What kind of M-PESA payment is this? “M-PESA payment” can describe several substantially different customer and merchant flows. Mobile-money transfer versus merchant collection A person-to-person transfer sends value to another mobile-money user. A merchant collection is structured around a business identifier, merchant account, Till, PayBill number, API integration, or approved business product. Merchants should not use personal person-to-person numbers as a substitute for a supported merchant-collection model. A proper business flow can provide: * Merchant identification * Transaction references * Business reporting * Reconciliation data * Staff permissions * Refund or reversal processes * Provider support * Appropriate contracting * Separation of personal and business funds Main M-PESA collection models Collection model How it begins Best suited to Main merchant issue M-PESA Express or STK Push Merchant sends a payment prompt to the customer’s registered mobile number Ecommerce, gaming, digital goods, travel, on-demand services Callback delays, duplicate prompts, phone-number accuracy, pending status PayBill Customer selects PayBill and enters a business number, account reference, amount, and PIN Education, utilities, SaaS renewals, invoices, marketplaces, institutional collection Correct account reference, manual-entry errors, order matching Buy Goods or Business Till Customer selects Buy Goods and enters the merchant Till and amount

Retail, restaurants, travel desks, mobility, physical and omnichannel merchants Correct Till identity, amount verification, store-level reconciliation Dynamic QR Merchant creates a scannable payment object containing relevant merchant and transaction information Physical retail, events, delivery, mobility, omnichannel commerce Same-device usability, QR expiration, payment confirmation Pochi la Biashara Small or informal merchant receives business funds through a separated merchant balance Microbusiness and informal commerce May not provide the integration, permissions, settlement, or reporting required by a larger platform Customer bank-to-wallet funding Customer moves money from a linked banking channel into mobile money before paying Customers with insufficient wallet balance Extra journey and possible checkout abandonment Business disbursement or B2C Merchant or organization sends money from a business shortcode to a customer Refunds, seller payouts, earnings, incentives Beneficiary verification, transaction linkage, treasury control Safaricom describes PayBill as a customer-initiated collection service in which an account number can identify the payer or obligation. Business Till is designed for merchant collection and subsequent business use of the collected balance. Daraja provides APIs connecting M-PESA to web and mobile applications, including payment initiation, transaction-status retrieval, transaction pulling, QR generation, and business payment functions. (Safaricom)

Choosing between PayBill and Till Use PayBill when the payment needs an identifying reference such as: * Student number * Invoice number * Loan or account number * Subscription account * Marketplace order * Booking reference * Customer ID Use Till or Buy Goods when the customer is paying a merchant for a purchase and a separate account identifier is not central to the journey. Use STK Push when the merchant wants to initiate a digital checkout request, prepopulate relevant information, and reduce the amount the customer must type. Use dynamic QR where scanning is natural, especially in physical or cross-device environments. A merchant can use more than one model. An education provider might use STK Push for immediate online enrolment and PayBill for later tuition instalments. A travel company might use STK Push for online booking and Till or QR for purchases at a physical location.

Stage 3: Can the customer recognize and authorize the payment safely? An M-PESA payment prompt is both an authentication step and a trust decision. Before entering a PIN, the customer should be able to verify: * Merchant identity * Amount * Payment purpose * Account or order reference * Whether the request was expected * Whether the request is still valid Checkout practices that reduce uncertainty The page before the prompt should state: * “You will receive an M-PESA payment request on the number entered.” * The exact amount in KSh * The merchant name likely to appear in the prompt * The expected order or account reference * That the merchant will never request the customer’s M-PESA PIN * What to do if the prompt does not arrive * What to do if the customer approves payment but the page does not update Phone-number entry Merchants should: * Accept familiar local formats. * Normalize the number internally to the format required by the provider. * Detect obvious formatting errors before initiating payment. * Mask the number on the confirmation page. * Allow correction before sending the prompt. * Avoid silently changing the number associated with the customer’s account. * Rate-limit repeated payment prompts. The customer may use a different phone number from the one stored on the merchant account. The checkout should make it clear whether the number is being used for payment, communication, account recovery, or all three. Same-device considerations

The customer may receive and approve an STK prompt on the same device being used for checkout. The merchant must account for: * The banking or SIM interface covering the browser * The browser being suspended * The customer returning to an earlier tab * Delayed page refresh * Multiple prompts arriving out of order * Weak connectivity after authorization * A successful payment completing even though the browser never returns The server-side payment state should be authoritative. The browser should display that state rather than inventing it.

Stage 4: Has the merchant actually confirmed payment? This is the most important operational distinction in the Kenyan mobile-money journey. A customer can see a successful debit while the merchant has not yet matched that transaction to an order. A merchant can also receive a callback after the customer has left the page, after a timeout, or after support has initiated another attempt. A callback is an event, not an entire payment system A production implementation should combine: * Initial API response * Asynchronous callback * Transaction-status query * Pull or reconciliation functionality where supported * Durable payment records * Idempotency * Retry handling * Exception monitoring Safaricom’s Daraja platform exposes transaction-status and pull-transaction capabilities in addition to its payment APIs. These tools allow a merchant to recover and verify payment state rather than depending solely on the original browser session. (Safaricom Developer) Recommended payment states Do not reduce every attempt to “paid” or “failed.” Use states such as: * Created * Prompt requested * Prompt delivered or awaiting customer action * Customer canceled * Timed out * Pending provider confirmation * Confirmed successful * Confirmed failed * Unmatched payment * Duplicate payment * Reversal requested * Reversed * Refund requested * Refunded * Manual review required Idempotency Every payment attempt should have: * A unique merchant attempt ID * A stable order ID * Provider request ID * Provider transaction ID when available

* Customer mobile number in protected form * Amount * currency * creation time * final status * fulfilment status * refund status If the same callback arrives more than once, the order should not be fulfilled twice. If the customer presses “pay” more than once, the system should determine whether an active attempt already exists before generating another prompt. Pending-payment recovery When no final status has arrived: 1. Keep the order pending. 2. Tell the customer not to pay again immediately. 3. Query the original transaction. 4. Allow a retry only after the first attempt is resolved or safely expired. 5. Match any late success to the original order. 6. Escalate unresolved debits to operations. The page should not claim that payment failed merely because a callback was delayed.

Stage 5: When should the merchant fulfil the order? A successful wallet debit and a fulfilled order are related but distinct events. Fulfilment should generally begin only when: * The provider reports a confirmed successful transaction. * The amount and currency match. * The merchant reference matches. * The transaction has not already been used. * The order remains valid. * Risk controls do not require review. Digital goods and gaming For instant delivery: * Use server-side confirmation. * Make fulfilment idempotent. * Record which account received the digital value. * Retain consumption and delivery evidence. * Prevent the same transaction ID from funding multiple accounts. * Apply velocity controls. * Separate payment success from account-entitlement updates. Travel and mobility The merchant may need to distinguish: * Reservation request * Deposit paid * Balance paid * Ride or service completed * Cancellation * No-show * Post-service adjustment * Partial refund Education The payment must be associated with: * Student * Course * institution * term * invoice * payer * access date A parent or employer may pay from a mobile number unrelated to the student account. Marketplaces A successful customer payment should not automatically trigger irreversible seller payout. The marketplace may need to wait for: * Seller acceptance * delivery * buyer confirmation * complaint window * fraud review * regulatory or tax checks

Stage 6: Can the merchant return value through a familiar path? Customers commonly expect the refund to return through the same financial environment used to pay. The merchant’s treasury operation may be more complicated. A customer may have paid through: * STK Push * PayBill * Till * QR * card * bank transfer * another mobile-money provider The merchant may hold funds in: * An M-PESA business balance * A provider settlement account * A local bank account * An international provider balance * A reserve account * A marketplace escrow or controlled account Reversal versus refund A reversal usually attempts to undo or return a particular transaction through a supported provider process. A refund is the broader commercial obligation to return customer value. Depending on the operating model, it may be executed through: * Provider reversal * Business-to-customer M-PESA payment * Bank transfer * Card refund * Original-method refund through a PSP * Manually controlled payout Safaricom supports transaction-reversal and business-to-customer capabilities in its business ecosystem. The exact availability of merchant-initiated reversals, partial refunds, time limits, maker-checker approval, and automated API support depends on the product and provider arrangement. (Safaricom) Questions to answer before launch For every method, confirm: * Is an original-method refund available? * Can the merchant issue a partial refund? * Can several partial refunds be issued? * Is there a refund time limit?

* Does the refund require sufficient business balance? * What happens if the recipient number is inactive? * Is the customer notified? * Is a new transaction ID created? * How is the refund linked to the order? * Who approves it? * What provider fees apply? * How are failed refunds reported? * What evidence is available to support teams? Customer communication A refund confirmation should show: * Refund amount * Original order * destination method * date initiated * expected processing period * merchant reference * support contact The merchant should not say “refunded” merely because an internal support ticket was approved.

Stage 7: Can finance reconcile payment, settlement, and usable funds? A customer confirmation is not a settlement report. The full finance chain can include: 1. Customer authorization 2. Mobile-money debit 3. Merchant collection account credit 4. Provider confirmation 5. Provider or operator fees 6. Tax or withholding adjustment where applicable 7. Transfer to a business balance or settlement account 8. Bank payout 9. Currency conversion 10. International merchant payout 11. Refund or reversal 12. Finance reconciliation Reconciliation data Each transaction record should include: * Merchant order ID * Payment-attempt ID * Customer account reference where applicable * Provider transaction ID * M-PESA receipt number where available * PayBill or Till * gross amount * fee * net amount * creation time * confirmation time * settlement batch * payout date * reversal or refund ID * final finance status Do not reconcile by total alone Two systems can show the same daily total while containing different transactions. Finance should reconcile: * Transaction to order * Order to fulfilment * Transaction to provider report * Provider report to settlement * Settlement to bank payout * Refund to original transaction * Fees to contract terms * Exceptions to an assigned owner M-PESA business channels provide statements and business-account visibility, but merchants with significant volume should ingest structured transaction and settlement data into their own finance systems rather than treating a portal as the sole record. (Safaricom)

Kenya’s economic and digital-commerce position Economic relevance Kenya’s approximately $135.9 billion economy is one of the largest in East Africa. Real GDP expanded by 4.6% in 2025. Agriculture still represents more than one-fifth of output, while financial services, communications, trade, construction, tourism-related services, transport, and other service sectors create varied consumer and business-payment demand. (World Bank Open Data) The national total should not be interpreted as uniform consumer spending power. Merchants should account for: * Large differences between customer income groups * Price sensitivity * High importance of low-value transactions * Urban and rural access differences * Device and connectivity differences * Transaction costs relative to order value * Domestic versus international customer segments * Informal and small-business activity The market can support large transaction volumes without producing the average order values seen in higher-income economies. This favors businesses able to offer: * Affordable digital products * Flexible purchase sizes * Daily, weekly, or term-based payment * Strong mobile usability * Clear KSh pricing * Low-cost collection * Customer-initiated renewal where automatic recurring access is limited

No single digital-economy percentage tells the full story A current, authoritative, consistently defined estimate for the whole Kenyan digital economy as a share of GDP was not identified for this guide. That absence should not be filled with a commercial forecast presented as an official national statistic. Different measures describe different concepts: * ICT-sector output * Telecommunications revenue * Ecommerce sales * Mobile-money value * Digitally delivered services * Internet use * Digital financial access * Technology-enabled activity in traditional businesses Kenya’s digital maturity is better assessed through a group of indicators. Mobile infrastructure At December 2025, the Communications Authority reported: * 78.4 million SIM subscriptions * 51.4 million mobile-money subscriptions * 62.0 million mobile-data subscriptions * 51.5 million mobile-broadband subscriptions * 48.7 million smartphones connected to mobile networks * 29.6 million feature phones connected to mobile networks These are supply-side subscription and device indicators. They can include multiple subscriptions or devices per customer and should not be treated as unique-user counts. The World Bank’s separate demand-side indicator estimated that 35% of the population used the internet in 2024. The apparent gap between internet users and mobile-broadband subscriptions illustrates why subscriptions, devices, coverage, and individual usage must be kept distinct. (World Bank Open Data) Financial access

The 2024 FinAccess survey found formal financial inclusion of 84.8%, up from 26.7% in 2006. The survey also identified affordability, relevance, identity access, device access, literacy, and consumer protection as continuing constraints. (Central Bank of Kenya) This is an unusually important distinction for merchants: * A customer may have financial access without owning a credit card. * A customer may have mobile money without regularly shopping online. * A customer may have a smartphone but rely on USSD for payments. * A customer may be connected but unable to afford a large upfront purchase. * A customer may trust M-PESA but not an unfamiliar merchant. Kenya’s payment opportunity is not created by connectivity alone. It is created where connectivity, trusted financial access, suitable pricing, and a reliable checkout overlap.

How customers pay in Kenya M-PESA M-PESA is the defining mass-market payment rail. Its importance extends beyond checkout into: * Person-to-person transfer * Merchant payment * Bill collection * Business disbursement * Cash-in and cash-out * Bank-to-wallet movement * Wallet-to-bank movement * Savings and investment products * Credit * Cross-border services * Government and institutional collection * Everyday small-business operations Safaricom reported 40 million monthly active Kenyan customers in March 2026. It also reported that 17.1 billion low-value “Kadogo” transactions were free during its 2025/26 financial year, representing 58% of all M-PESA activity under that company measure. The latter is operator reporting and should not be interpreted as a national transaction-market share. (Safaricom) Other mobile-money services M-PESA is dominant but not the only mobile-money service. The Communications Authority reported that M-PESA represented approximately 89% of mobile-money subscriptions at December 2025. Merchants should assess whether additional mobile-money coverage contributes enough incremental customers to justify: * Separate integration * Additional contracts * More refund processes * Different settlement files * Extra support training * Added reconciliation complexity

Interoperability can allow customers on other mobile-money networks to pay selected PayBills and Tills, but the merchant must confirm actual production support, customer experience, status reporting, refunds, and settlement with its provider. Bank and account-to-account payments PesaLink provides instant account-to-account transfers across participating banks and other connected institutions, supporting transfers of up to KSh 999,999 through channels such as banking applications, internet banking, and USSD. It can be useful for higher-value consumer purchases, B2B payments, tuition, travel bookings, supplier payments, and marketplace settlements. (Pesalink) Bank payment is most useful when the merchant can provide: * A unique payment reference * A virtual or dedicated account * Automated confirmation * Expiration logic * Transaction-to-order matching * Refund instructions * Reconciliation data An unstructured bank transfer followed by a screenshot should not trigger fulfilment. Cards As of June 2026, CBK reported approximately: * 10.7 million debit cards * 340,778 credit cards * 2.2 million prepaid cards * 13.3 million cards in total * 55,117 POS machines These are cards issued, not unique cardholders, active ecommerce cards, or cards enabled for international transactions. (Central Bank of Kenya) Cards are especially important for: * Visitors * Travel * internationally oriented customers * corporate buyers * SaaS * automatic subscriptions * higher-income customer segments

* customers paying through card-backed wallets * cross-border purchases They should supplement—not define—the mass-market domestic checkout. Card-backed international wallets Wallets backed by international cards can reduce credential entry and improve mobile checkout for customers with eligible cards. Their reach remains bounded by: * Card ownership * issuer support * device support * network eligibility * ecommerce enablement * recurring-payment rules * authentication * merchant acquiring A card-backed wallet should be measured as a card-funded customer experience, not combined indiscriminately with mobile money. Cash and cash on delivery Cash remains relevant to the wider economy and selected physical-goods journeys. Cash on delivery may help a retail merchant reach customers unwilling or unable to prepay. It also creates: * Failed deliveries * order refusal * cash handling * courier reconciliation * delayed settlement * inventory reservation * return risk * support contacts It is generally unsuitable for instant digital goods, SaaS, gaming credits, streaming, and most online education access.

Payment-method priority matrix Payment method Gaming and digital goods Marketplaces Travel and mobility Education SaaS Subscription media Priority M-PESA Express or STK Push Launch essential Launch essential Launch essential for domestic customers Launch essential High-value addition Launch essential for one-time access Core mass-market method M-PESA PayBill Segment-specific Launch essential for referenced collection High-value addition Launch essential High-value addition for invoices and manual renewal Useful for manual renewal Essential where account references matter M-PESA Till or Buy Goods Useful for physical distribution and events Important for local sellers Launch essential for physical mobility and travel locations Segment-specific Usually unnecessary Segment-specific Strong merchant-present method Dynamic M-PESA QR Useful for events Useful for sellers High-value addition Useful on campus Usually optional Useful at physical venues Omnichannel addition Cards High-value addition High-value addition Launch essential High-value addition Launch essential for many automatic subscriptions Launch essential for automatic renewal Essential for international and recurring segments PesaLink or structured bank payment Optional Important for sellers and higher values Useful for larger bookings High-value addition Important for annual and business plans Segment-specific Strong B2B and high-value addition Other mobile money Useful after measured demand Useful for broader seller or buyer reach Segment-specific Segment-specific Usually optional

Optional Add where incremental reach is proven Cash on delivery Unsuitable Segment-specific for physical goods Usually unnecessary Usually unnecessary Unnecessary Unnecessary Operationally expensive niche Customer-managed standing order Segment-specific Optional Optional Useful for scheduled fees Useful for customer-controlled renewal Useful for subscriptions Not equivalent to merchant-initiated billing Card-backed wallets High-value addition Useful Launch essential for visitor-heavy businesses Useful High-value addition High-value addition Important for card-capable mobile customers The matrix should be adapted to the merchant’s transaction values, customer origin, product, refund profile, and recurring model.

Merchant vertical opportunities Gaming and digital goods: strong immediate fit Kenya’s mobile-money infrastructure aligns with: * Low- and medium-value purchases * Virtual currency * downloadable content * passes * one-time upgrades * creator payments * event and esports purchases * mobile-first entertainment M-PESA should usually be the primary domestic one-time payment method. Cards remain useful for: * Automatic membership * international customers * higher-value purchases * stored credentials * cross-border products Main operating issues * Instant fulfilment * account takeover * spending by minors or family members * payment to the wrong game account * duplicate prompts * refund abuse * consumption evidence * high support volume at low transaction values * merchant-category eligibility A low-value purchase can become unprofitable if the payment generates a manual support case.

Marketplaces and gig platforms: high opportunity, high complexity Kenya’s mobile-money ecosystem supports: * Buyer collection * seller payments * driver or worker earnings * commissions * refunds * incentives * delivery payments * service-provider settlement A marketplace must not treat these as one payment flow. It should separately design: 1. Customer collection 2. Platform fee 3. Seller ledger 4. payout eligibility 5. seller disbursement 6. refund allocation 7. chargeback or fraud loss 8. tax reporting 9. reconciliation M-PESA can make both collection and disbursement accessible, but the marketplace must determine who legally receives, holds, and releases customer funds.

Travel and mobility: strong immediate fit Kenya’s accommodation and food-services sector expanded by 14.7% in the first quarter of 2026, while international arrivals through the country’s two major airports reached 506,622 during the quarter, 13.1% above the corresponding period a year earlier. These are quarterly activity indicators, not a full tourism-market forecast. (Kenya National Bureau of Statistics) Travel and mobility merchants may serve: * Kenyan residents using M-PESA * regional travelers using mobile money or cards * international visitors using cards * corporate customers using bank payments * drivers, hosts, and local suppliers needing payouts Recommended portfolio: * M-PESA for domestic customers * Cards and card-backed wallets for visitors * Structured bank payment for groups and corporate booking * Till or QR for on-location purchases * Controlled disbursement for drivers, hosts, or suppliers

Education: strong immediate fit Education payments commonly require more than a payment amount. The merchant may need: * Student ID * course code * term * invoice * payer identity * institution * instalment * access date PayBill is particularly useful where the account field can carry a student or invoice reference. STK Push can support immediate course enrolment. Cards may support: * International education providers * automatic subscription * higher-income customer segments * cross-border certification Bank payments may suit larger tuition amounts.

SaaS: attractive but recurring-sensitive Potential customer groups include: * Small and medium-sized businesses * agencies * freelancers * professional services * exporters * schools * hospitality businesses * retailers * marketplaces A SaaS merchant should not force every customer into automatic card billing. A localized portfolio may include: * Cards for automatic subscription * M-PESA for monthly or annual customer-initiated payment * PayBill with an account reference * customer-controlled standing order * PesaLink or bank transfer for annual B2B contracts * invoicing for larger accounts The product should clearly distinguish automatic renewal from payment reminders requiring customer action.

Subscription media: attractive with a hybrid billing model Streaming, news, music, creator content, and other media can offer: * One-time access * day or week passes * monthly customer-initiated renewal * automatic card subscription * customer-managed M-PESA standing order * annual bank payment The best structure may not be one recurring method for every customer. A merchant can provide: * Automatic card plan * M-PESA monthly renewal plan * customer-controlled standing order where supported * prepaid access pass * grace period after failed renewal

Card-market characteristics Kenya’s card market is predominantly debit-led. CBK’s June 2026 figures show more than 10.7 million debit cards but only about 341,000 credit cards. That difference affects recurring commerce, available credit, average transaction value, and the likely reach of card-only checkouts. (Central Bank of Kenya) Merchants should distinguish: * Debit from credit * Domestic from foreign-issued * Physical from virtual * Prepaid from bank-account-linked * Ecommerce-enabled from ATM-focused * Internationally enabled from domestic-only * One-time from recurring-capable * Manually entered from tokenized Local acquiring Local or regionally optimized acquiring may: * Improve domestic routing * Support KES settlement * reduce selected cross-border costs * improve issuer recognition * simplify local reporting * provide access to domestic payment relationships It does not guarantee higher authorization. Performance depends on: * Issuer * acquirer * card product * merchant category * customer segment * authentication * fraud controls * transaction value * technical configuration Compare local and cross-border arrangements using merchant-specific evidence.

Currency and pricing Kenya’s official currency is the Kenyan shilling, code KES. Consumer prices are commonly displayed with KSh, Ksh, or KES. Local-currency pricing KES pricing is generally the clearest approach for domestic customers because it: * Matches mobile-money balances * avoids mental conversion * clarifies affordability * simplifies payment prompts * reduces support questions * makes refunds understandable Local-currency presentment does not prove that the provider can settle or pay the merchant in KES. Distinguish every currency layer 1. Presentment currency: What the customer sees. 2. Processing currency: What the provider receives. 3. Funding currency: The balance or account used by the customer. 4. Settlement currency: The currency used to calculate merchant settlement. 5. Payout currency: What reaches the merchant’s bank. 6. Reporting currency: What appears in finance systems. 7. Conversion currency: Any intermediary FX step. An international merchant may display KES, collect through a local provider, settle to a Kenyan account, and later convert the proceeds. Another may receive a provider payout outside Kenya after conversion. These arrangements have different: * FX costs * payout timing * tax consequences * refund economics * liquidity requirements * reconciliation data Pricing design * Show the final KES amount before sending the prompt. * Avoid adding fees after M-PESA selection. * Keep the amount consistent across checkout and prompt.

* Use familiar whole-number pricing where commercially suitable. * Explain tax, delivery, booking, or platform fees before authorization. * Preserve the quoted amount while the customer completes payment. * Display the order reference consistently.

Local settlement and cross-border processing The following capabilities are separate: * M-PESA acceptance * Daraja connectivity * Merchant PayBill or Till * Domestic card acquiring * KES processing * KES settlement * Kenyan bank payout * International merchant contracting * Foreign-currency payout * Cross-border repatriation A provider may offer some but not all. Potential operating requirements Depending on the provider and merchant model, access may require: * Kenyan entity * local bank account * KRA registration * business documentation * beneficial-owner information * sector licensing * expected-volume review * merchant-category approval * local settlement * reserves * a local contracting party These requirements must be confirmed with the chosen institution. Cross-border launch alternatives An international merchant may consider: Global PSP Useful for: * International cards * centralized contracting * multi-market integration * recurring billing * consolidated reporting Potential gap: * Limited or indirect M-PESA access * less control over local settlement * provider-specific merchant eligibility Local or regional PSP Useful for: * M-PESA * additional mobile money * local cards * KES settlement * domestic support Potential gap: * additional contracting * separate reporting * international-payout constraints * local-account requirements Merchant of Record Useful where the merchant wants another party to contract with customers and assume selected payment, tax, invoicing, refund, or compliance responsibilities.

Potential trade-offs include: * Higher cost * reduced control * product restrictions * provider-dependent settlement * provider-controlled refund policy Combined model A mature merchant may use: * Local or regional partner for M-PESA and local methods * Global provider for cards and international customers * Orchestration or an internal payment layer for method routing, statuses, and reconciliation

Payment regulation and licensing Kenya’s payment environment is supervised by the Central Bank of Kenya under legislation that includes the National Payment System Act 2011 and the National Payment System Regulations 2014. CBK maintains a directory of authorized payment-service providers and the services each institution has been approved to perform. The May 15, 2026 directory includes mobile-money issuers, processors, gateways, and organizations approved to process payments on behalf of merchants. (Central Bank of Kenya) The directory proves that an institution has specified regulatory approval. It does not prove that: * The provider accepts the merchant’s category * A specific API is available in production * An international merchant can contract directly * Local settlement is available * Refunds are supported * Recurring collection is supported * The quoted commercial terms are current National policy direction Kenya launched its National Financial Inclusion Strategy for 2025–2028 in December 2025. Its broader policy direction includes expanding meaningful, affordable, safe, and equitable financial access while addressing consumer protection and usage quality. (Central Bank of Kenya) Responsibilities by participant Merchant Typically responsible for: * Lawful product or service * accurate description * pricing * fulfilment * cancellation * refund policy * customer support * fraud controls * tax treatment * evidence retention * protection of customer data Payment provider May be responsible for:

* Merchant onboarding * payment processing * M-PESA or card connectivity * transaction reporting * settlement * authentication support * dispute administration * monitoring Mobile-money operator May control: * Customer account * wallet authentication * limits * transaction execution * customer notification * agent network * wallet-level reversal procedures Acquirer May control: * Card acceptance * scheme relationship * authorization routing * settlement * chargebacks * card-network compliance Marketplace May assume additional responsibilities for: * Seller onboarding * customer-fund handling * seller payouts * product monitoring * complaints * tax reporting * reserves * regulated payment-service boundaries Merchant of Record May contract with the customer and take responsibility for selected payment, tax, invoicing, refund, and compliance functions under its agreement. Legal, regulatory, tax, and accounting disclaimer: This article provides general information and does not constitute legal, regulatory, tax, or accounting advice. Merchants should confirm all applicable obligations and operating requirements with qualified advisers and relevant payment partners.

Tax and invoicing context Kenya’s tax treatment depends on: * Merchant residence * Customer location * Product or service * Digital versus physical supply * Consumer versus business transaction * Marketplace role * Fulfilment model * Entity receiving payment * Invoicing party The Kenya Revenue Authority states that nonresident businesses supplying services in Kenya through the internet, an electronic network, or a digital marketplace may be required to register for VAT regardless of whether they meet the ordinary KES 5 million turnover threshold. A simplified registration, filing, and payment system is available for qualifying suppliers. (Kenya Revenue Authority) Merchants should seek advice on: * VAT registration * digital marketplace supplies * electronically supplied services * physical-goods VAT * withholding * permanent establishment * marketplace responsibilities * eTIMS or electronic invoicing * invoice fields * refund-related tax adjustments * Merchant of Record treatment * seller payouts The payment architecture and tax architecture should be reviewed together. The party receiving funds, issuing an invoice, supplying the service, paying a seller, and processing a refund may not always be the same entity.

Data protection and customer information Kenya’s Data Protection Act 2019 regulates personal-data processing and sets out rights of data subjects and obligations of controllers and processors. Supporting regulations address general processing, registration of controllers and processors, complaints, and enforcement. (Data Protection Office) Payment implementations may process: * Mobile number * customer name * order and account references * transaction identifiers * IP address * device information * location * identity documents * seller data * fraud signals * support records Merchants should: * Collect only necessary data. * Explain the payment purpose. * Protect mobile numbers and transaction records. * Restrict internal access. * Establish retention periods. * review cross-border data transfers. * define processor and controller roles. * assess whether local registration obligations apply. * secure callback endpoints and credentials. * avoid exposing full customer details in logs or support tools.

Checkout localization Language English is widely used in commerce. Kiswahili can improve accessibility and trust for broader domestic audiences. The most important content to localize includes: * M-PESA instructions * merchant identity * PayBill or Till information * account-reference guidance * pending status * failed-payment explanation * refund timing * support contact A mixed-language interface is acceptable where it remains consistent and understandable. Mobile and feature-phone behavior Kenya’s connected-device base includes both smartphones and feature phones. A merchant should not assume every customer will complete payment through a high-end application experience. Design for: * Smaller screens * lower-cost Android devices * slower connections * app switching * SIM-toolkit or USSD interaction * push delays * page restoration * customer exit and return * asynchronous confirmation Merchant identity Show the name the customer should expect in the M-PESA prompt or confirmation. A mismatch between the storefront brand and payment-recipient name can create: * Customer abandonment * suspected fraud * support contact * payment to the wrong identifier * dispute risk Where the legal recipient name differs from the trading name, explain the relationship before payment. Account references For PayBill: * Explain exactly what belongs in the account field. * Prepopulate it where possible. * Validate expected length and format. * Avoid ambiguous examples. * Preserve leading zeros. * Show it again before confirmation.

* Match it automatically after payment. Phone formatting Support: * Local numbers beginning with zero * International +254 format * spaces or common punctuation * normalization behind the interface Do not reject a legitimate number merely because it was entered in the customer’s familiar format.

Authentication and customer verification M-PESA The customer normally authorizes through an M-PESA-controlled interface using a secret PIN or other operator-supported mechanism. The merchant should never: * Ask for the PIN * capture the PIN * request it through chat * request it by phone * simulate an M-PESA authorization screen * tell the customer to approve a different amount The merchant controls: * The accuracy of the request * displayed merchant identity * amount * reference * request timing * retry behavior * callback security * fulfilment decision The operator controls the wallet authentication and execution. Cards Card payments may involve: * 3-D Secure * OTP * banking-app approval * risk-based frictionless authentication * issuer challenge * tokenized wallet authentication Merchants should separately measure: * Authentication success * authorization approval * technical completion * completed order A successful authentication does not guarantee authorization.

Recurring payments and subscriptions Recurring commerce in Kenya requires more than repeating a one-time STK Push. One-time authorization A normal M-PESA Express payment authorizes a specific customer-initiated transaction. It should not automatically be treated as: * Stored wallet credential * standing merchant mandate * permission to debit later * card-on-file equivalent * merchant-initiated transaction M-PESA Ratiba M-PESA Ratiba allows customers to schedule recurring transactions such as PayBill, Buy Goods, and other supported payments. Safaricom positions it for scheduled obligations and subscription-type use cases and lists a related capability through Daraja. (Safaricom Developer) The important merchant distinction is control. A customer-created standing order is not necessarily equivalent to a merchant-controlled recurring token. Merchants must confirm: * Who creates the instruction * whether the merchant can request it * fixed or variable amount * permitted frequency * customer cancellation * payment-failure status * provider API support * merchant eligibility * refund process * reconciliation * renewal notice Cards Cards may provide the most practical automatic recurring method where the merchant can support: * Card-on-file * tokenization * initial authentication * subsequent merchant-initiated transactions * account updater * failed-payment recovery * cancellation * refunds The reachable card audience is narrower than the M-PESA audience. Recommended subscription portfolio

For Kenyan SaaS, education, gaming, or media: * M-PESA for customer-initiated payment * PayBill for referenced renewal * Ratiba or another customer-controlled schedule where supported * cards for automatic recurring billing * bank payment for annual B2B plans * reminders and grace periods * clear distinction between automatic and manual renewal

Refunds, reversals, and disputes M-PESA Confirm with the provider: * Transaction reversal support * Merchant-initiated refund support * Full refund * Partial refund * multiple refunds * time limits * business-balance requirements * maker-checker approval * callback or status notification * customer confirmation * failed-refund workflow Cards Cards can involve: * Authorization reversal * full refund * partial refund * chargeback * fraud dispute * service dispute Merchants should retain: * Authentication outcome * payment record * product description * customer communications * delivery or access evidence * refund history * cancellation terms Bank payments A bank transfer refund may require: * Verified beneficiary details * bank approval * reference matching * separate payout * manual review Do not send refunds to a new account solely on the basis of an email request. Dispute design Customer support needs access to: * Original order * original payment * M-PESA or provider reference * status history * fulfilment * refund * duplicate attempts * support history The goal is one case record rather than separate records across payments, orders, and support.

Settlement and treasury The customer can pay successfully while the market remains commercially unattractive to the merchant. Treasury must confirm: * Collection currency * settlement currency * payout currency * domestic-account requirement * local-entity requirement * payout timing * minimum payout * reserve * provider fee * operator fee * tax or withholding deduction * FX conversion * exchange-rate basis * refund funding * negative-balance treatment * reconciliation report * international repatriation Customer funds versus usable merchant funds Distinguish: 1. Customer balance debited 2. Merchant collection confirmed 3. Provider settlement calculated 4. Funds transferred to a business balance or bank 5. FX conversion performed 6. International payout initiated 7. Merchant bank credits usable funds 8. Finance reconciles the payout The economics of each stage matter. A high-converting method can still be unprofitable if: * Settlement is slow * FX is expensive * refunds require prefunding * reserves are high * finance must reconcile manually * payouts require local treasury infrastructure

Fraud and risk characteristics Kenya should not be classified broadly as a high-risk market. Risk should be analyzed by method, customer behavior, device, transaction, and merchant vertical. Social engineering Customers may be targeted through: * Fake support calls * requests for M-PESA PIN * false reversal instructions * fraudulent STK prompts * impersonated merchant messages * fake refund requests * compromised social accounts The checkout and support policy should state that employees will never request an M-PESA PIN. Wrong merchant identifier A customer can send money to: * The wrong PayBill * Wrong Till * Incorrect account reference * Personal number impersonating the merchant Merchants should provide identifiers inside the secure checkout rather than relying on copied social-media posts. Fake screenshots and messages Never fulfil solely from: * Screenshot * forwarded SMS * typed transaction code * browser success page * customer assurance Use the provider API, status query, or reconciled transaction report. Callback replay and duplication Secure integrations should protect against: * Replayed callback * forged request * duplicate notification * out-of-order event * altered amount * reused transaction ID * duplicate fulfilment Account takeover Particularly relevant to: * Gaming * marketplaces * gig platforms * stored-value accounts * subscription services Controls can include: * Device and account history * step-up verification * payout delay after account changes * notification of profile changes * velocity

* secure recovery * beneficiary verification Marketplace fraud Marketplaces should manage: * Fake seller * non-delivery * collusion * refund abuse * duplicate accounts * fraudulent beneficiary * payout-account changes * prohibited goods * account takeover * cash-on-delivery refusal Seller controls and payout timing may be as important as buyer-payment screening.

Provider landscape and operating models CBK’s May 2026 directory identifies licensed institutions approved for combinations of mobile-money issuance, processing, storage, transfer, and merchant-payment processing. Merchants should use the directory as the starting point for regulatory diligence, not as a substitute for capability verification. Direct M-PESA integration Best for: * High local volume * maximum checkout control * custom status handling * direct reconciliation * specialized merchant journeys Potential burden: * Merchant onboarding * API maintenance * callback security * certification * separate settlement * support escalation * local operating requirements Local or regional PSP Best for: * Faster M-PESA access * additional local methods * hosted checkout * local support * consolidated contracting Potential limitation: * Provider-specific API behavior * indirect access * eligibility restrictions * different refund capability * extra settlement layer Global PSP Best for: * Cards * international customers * reusable regional infrastructure * subscriptions * central reporting Potential limitation: * Incomplete local-method depth * less control over M-PESA state recovery * cross-border settlement economics Merchant of Record Best for: * Digital merchants seeking support with local selling, tax, payment acceptance, and customer contracting Potential limitation: * Higher cost * reduced control * product restrictions * provider-dependent refund and settlement Payment orchestration Best for: * Multiple providers

* method routing * common payment states * failover * monitoring * regional expansion Orchestration cannot create local eligibility or payment access that the underlying providers do not possess.

Payment strategy by merchant vertical Vertical Transaction pattern Priority methods Main operating risk Recommended launch approach Gaming and digital goods Frequent low- and medium-value instant purchases M-PESA Express, cards Duplicate fulfilment, account takeover, refund abuse Launch one-time M-PESA first; validate recurring separately Marketplace Buyer collection, commission, seller payout M-PESA, PayBill, cards, PesaLink Seller fraud, custody, payout, refunds Design the entire buyer-to-seller fund flow before launch Travel and mobility Booking, deposit, ride, ancillary purchase M-PESA, cards, Till or QR, bank transfer Foreign customers, cancellation, post-service adjustment Serve domestic M-PESA and international card customers separately Education Course, fee, term, tuition, application PayBill, STK Push, cards, bank transfer Payer-to-student matching, partial refunds Use mandatory structured references SaaS Monthly or annual renewal Cards, M-PESA renewal, PayBill, bank payment Automatic recurring coverage, failed renewal Offer automatic and customer-initiated plans Subscription media Low-value repeat access M-PESA, cards, Ratiba where supported Renewal friction, churn, low-value support cost Combine passes, manual renewal, and automatic card billing B2B platforms Invoice and supplier payment PesaLink, bank transfer, PayBill Reconciliation, approvals, invoicing Prioritize structured bank and account-based payment On-demand services Frequent low-value transaction M-PESA Express, Till, QR, cards

Cancellation, delayed callback, duplicate payment Optimize status recovery and rapid refunds

Payment-performance measurement Do not blend M-PESA and cards into a single Kenya success rate. Metric Recommended calculation Method visibility rate Eligible checkouts showing the method ÷ eligible checkout sessions M-PESA selection rate M-PESA selections ÷ checkouts where M-PESA was shown Prompt initiation rate Valid STK requests initiated ÷ M-PESA selections Prompt approval rate Customer-approved prompts ÷ valid prompts sent Provider confirmation rate Confirmed successful payments ÷ valid attempts Callback delay Time from customer authorization to callback receipt Status-recovery rate Pending attempts resolved by query or reconciliation ÷ unresolved pending attempts Duplicate-payment rate Duplicate confirmed payments ÷ successful orders Unmatched-payment rate Successful payments not automatically matched to an order ÷ successful payments Card authorization rate Approved card authorizations ÷ submitted authorizations Authentication success Successful card authentications ÷ authentication attempts Completed-order rate Paid, accepted orders ÷ checkout sessions Refund success rate Completed refunds ÷ valid refund requests Refund delay Time from merchant approval to customer receipt Technical-error rate Technical failures ÷ initiated attempts Cost per successful payment Payment and provider cost ÷ successful payments Cost per completed order Payment, fraud, support, and fulfilment cost ÷ completed orders Settlement delay Time from payment confirmation to usable merchant funds Reconciliation-exception rate

Unmatched transactions or adjustments ÷ reportable transactions Support-contact rate Payment-related support cases ÷ payment attempts Retained revenue Collected revenue minus refunds, fraud, disputes, fees, and unrecovered operating costs Segment by: * STK Push * PayBill * Till * QR * other mobile money * card * bank payment * provider * device * mobile network * customer type * domestic versus foreign-issued card * new versus returning customer * order value * product * vertical * checkout version

Launch recommendations by merchant stage Merchant testing demand Start with: * KES pricing * One strong M-PESA integration * Cards * Structured bank payment only where value justifies it * Limited product range * Clear market-validation targets * Controlled manual exception handling * Verified refund process * Defined settlement route The test should determine whether customers can complete and retain purchases—not only whether they visit checkout. Merchant launching nationally Add: * PayBill or Till where the use case requires it * Robust callback handling * Transaction-status retrieval * automated reconciliation * full refund testing * support procedures * English and Kiswahili payment guidance * fraud controls * local tax and data review * formal provider escalation Merchant scaling volume Investigate: * Additional mobile-money coverage * local card acquiring * provider redundancy * payment orchestration * automated exception queues * settlement optimization * reserve negotiation * store- or seller-level Till structures * advanced fraud controls * structured marketplace payout Merchant optimizing performance Focus on: * Prompt delivery * phone-entry errors * customer cancellation * callback latency * pending-payment recovery * duplicate prevention * amount and reference mismatches * device and network cohort * method ordering * customer-support rate * refund time Merchant introducing subscriptions Validate: * Card tokenization * merchant-initiated card transactions * customer-controlled Ratiba or standing-order functionality

* PayBill renewal * failed-payment recovery * reminder timing * grace periods * cancellation * refunds * clear automatic-versus-manual language Merchant expanding across East Africa Reuse: * Payment-state model * idempotency * reconciliation engine * provider abstraction * fraud data * refund workflow * support tools Keep country-specific: * Mobile-money operator * merchant shortcode * customer authorization flow * settlement * currency * regulation * tax * provider availability * local checkout instructions Do not assume that M-PESA behavior, coverage, merchant access, or settlement is identical in every country where the brand is available.

Kenya launch checklist Market and customer * Confirm which Kenyan customer segment the product serves. * Estimate pricing and retained margin in KES. * Separate one-time, recurring, consumer, and business demand. * Confirm merchant-category eligibility. * Validate likely transaction values and low-value economics. M-PESA collection * Choose STK Push, PayBill, Till, QR, or an appropriate combination. * Use a proper merchant-collection model rather than personal P2P transfers. * Display M-PESA prominently to eligible domestic customers. * Show the merchant name customers should expect. * Validate mobile-number formatting. * Validate account-reference formatting. * Test customer cancellation, timeout, and insufficient balance. Confirmation and fulfilment * Implement secure asynchronous callbacks. * Implement transaction-status retrieval. * Use unique payment-attempt IDs. * Make callback processing idempotent. * Make fulfilment idempotent. * Create a persistent pending state. * Prevent repeated prompts while an attempt is unresolved. * Test delayed and duplicate callbacks. * Match amount, currency, reference, and transaction ID before fulfilment. Cards and bank rails * Add cards for international and recurring use cases. * Segment domestic and foreign-issued cards. * Validate 3-D Secure. * Evaluate PesaLink or structured bank payment for higher values. * Avoid fulfilment based on payment screenshots. Recurring payments * Distinguish one-time M-PESA authorization from recurring permission.

* Validate M-PESA Ratiba or provider-specific recurring support. * Validate card tokenization and subsequent charges. * Create manual-renewal reminders. * Prepare grace periods and failed-payment recovery. * Make cancellation easy to understand. Refunds and support * Test transaction reversal. * Test business-to-customer refunds. * Confirm partial-refund capability. * Link refunds to original payments. * Define refund timing. * Prepare duplicate-payment procedures. * Train support not to request PINs. * Give support access to payment and fulfilment status. Settlement and reconciliation * Confirm processing, settlement, and payout currencies. * Confirm local entity and account requirements. * Validate fees, reserves, and payout timing. * Reconcile transaction to order. * Reconcile provider report to settlement. * Reconcile settlement to bank payout. * Reconcile refunds and reversals. * Assign owners for every exception type. Regulation, tax, and data * Confirm the provider’s CBK authorization. * Confirm the merchant’s production eligibility. * Review National Payment System requirements. * Review VAT and digital-supply obligations. * Review electronic-invoicing requirements. * Review marketplace responsibilities. * Review Data Protection Act obligations. * Protect API credentials, callbacks, mobile numbers, and transaction records. * Obtain qualified legal and tax advice. Measurement * Define the denominator for every metric. * Measure M-PESA separately from cards. * Track callback latency.

* Track pending and unmatched payments. * Track duplicate payments. * Track refund completion. * Track support contacts. * Track settlement delay and retained revenue. * Establish a formal post-launch review date.

Final merchant recommendation Kenya should be prioritized by merchants whose products fit a highly connected, mobile-money-oriented customer base and whose teams are prepared to operate the full payment lifecycle. The strongest opportunities include: * Gaming and digital goods * Marketplaces and gig platforms * Travel and mobility * Education * SaaS * Subscription media * On-demand services * Selected B2B platforms A merchant’s first Kenya payment release should generally include: 1. KES pricing 2. M-PESA displayed prominently 3. An appropriate collection model—usually STK Push, PayBill, Till, or a combination 4. Server-side callbacks and transaction-status recovery 5. Idempotent payment and fulfilment systems 6. Cards for international and recurring segments 7. Structured bank payments for higher-value or B2B transactions 8. A tested refund, settlement, and reconciliation operation Before committing significant acquisition and engineering resources, validate: * Merchant-category eligibility * Provider production access * Exact M-PESA collection flow * callback and status-retrieval behavior * customer-visible merchant identity * refunds and partial refunds * recurring-payment design * local settlement * international payout * tax * data protection * finance reconciliation * customer support Kenya’s defining commercial advantage is not that customers can use their phones to pay. It is that mobile money already operates as part of the customer’s financial life.

The merchant’s job is to connect that familiar financial operating system to an equally reliable order, fulfilment, refund, settlement, and repeat-purchase system.

Prepared from the Kenya country-specific editorial brief, including its mobile-money-first evidence anchor, merchant journey, operating distinctions, priority verticals, and publication requirements. Current datasets place Kenya’s 2025 nominal GDP at approximately $135.9 billion, or around the mid-60s globally depending on the ranking methodology. The exact rank should be recalculated from the publication-day dataset rather than treated as permanent. (World Bank Open Data) Editorial recommendations package SEO recommendations Title options 1. Payments in Kenya: M-PESA, Merchant Collections and Mobile Commerce 2. Payment Methods in Kenya: A Guide for International Merchants 3. Accepting Payments in Kenya: M-PESA, Cards and Bank Transfers 4. Kenya Payments Guide: M-PESA Integration, Refunds and Settlement 5. Ecommerce Payments in Kenya: A Mobile-Money-First Strategy Recommended SEO title Payment Methods in Kenya: Merchant Guide 2026 Recommended H1 Payments in Kenya: M-PESA, Merchant Collections, and Mobile-First Commerce Meta description Learn how customers pay in Kenya, including M-PESA, PayBill, Till, STK Push, cards, bank transfers, refunds, recurring payments, and settlement. URL slug /payments-in-kenya/ Primary keyword Payment methods in Kenya Secondary keywords * Payments in Kenya * M-PESA payments * M-PESA merchant payments * Accept payments in Kenya * Kenya payment gateway * M-PESA API integration * M-PESA STK Push * M-PESA PayBill * M-PESA Till * Kenya mobile money * Kenya ecommerce payments

* Kenya local acquiring * Kenya recurring payments * M-PESA refunds Related entities * Central Bank of Kenya * Communications Authority of Kenya * Safaricom * M-PESA * Daraja * Lipa na M-PESA * PayBill * Buy Goods * Business Till * STK Push * M-PESA Express * Dynamic QR * PesaLink * Kenyan shilling * KES * National Payment System Act * Kenya Revenue Authority * Office of the Data Protection Commissioner * FinAccess Search intent The primary intent is commercial investigation with implementation and operating guidance. The reader is likely evaluating: * Why M-PESA is necessary * Which M-PESA collection flow to use * How STK Push differs from PayBill or Till * Whether cards are sufficient * How to verify successful payments * How refunds work * Whether M-PESA supports subscriptions * How settlement and reconciliation work * Which provider model supports launch Article excerpt Kenya is not simply a market where mobile payments are popular. M-PESA operates as a general-purpose commerce rail connecting customers, merchants, bills, bank accounts, cash agents, and everyday financial activity. This guide explains how merchants should design collection, confirmation, fulfilment, refunds, recurring payments, and settlement around that reality. Social description A successful M-PESA debit is not automatically a successful order. Merchants entering Kenya must connect mobile-money authorization to reliable callbacks, status recovery, fulfilment, refunds, settlement, and reconciliation. Here is the complete operating model.

Internal-link recommendations

* Local payment methods * Mobile-money payments * How mobile wallets work * Account-to-account payments * Payment gateway integration * How to expand payments into a new country * International payment expansion checklist * Global payment strategy * Local PSP versus global PSP * Payment orchestration * Merchant of Record versus PSP * Payment authorization versus conversion * Why payments fail * Payment API failures * Payment reconciliation * Refunds and reversals * Subscription-payment recovery * Gaming payments * Marketplace payments * Education payments * Travel payments * Global Payments Atlas * Expand into Africa Use contextual anchor text such as: * “M-PESA merchant collections” * “mobile-money payment confirmation” * “payment callback recovery” * “local payment-method integration” * “international settlement”

Authoritative external-source recommendations Prioritize and periodically recheck: * Central Bank of Kenya for mobile-payment statistics, card figures, payment regulation, authorized-provider directories, and financial-inclusion policy. (Central Bank of Kenya) * Communications Authority of Kenya for mobile subscriptions, mobile money, broadband, connected devices, and operator market share. * Kenya National Bureau of Statistics for GDP, population, economic sectors, tourism, and consumer indicators. (Kenya National Bureau of Statistics) * World Bank for internationally comparable GDP, GDP per capita, population, internet use, and remittances. (World Bank Open Data) * Safaricom and Daraja documentation for M-PESA flows, APIs, PayBill, Till, QR, transaction status, Ratiba, and business-account functionality. (Safaricom Developer) * Kenya Revenue Authority for digital-supply VAT, registration, invoicing, and marketplace requirements. (Kenya Revenue Authority) * Office of the Data Protection Commissioner for data-processing and controller or processor obligations. (Data Protection Office) Provider marketing pages should not be the sole evidence for merchant eligibility, production access, refunds, recurring payments, or settlement.

Structured-data recommendation Use: * Article or BlogPosting * BreadcrumbList * FAQPage after adding an equivalent visible FAQ * ImageObject for the hero and original diagrams Recommended Article properties include: * Headline * Description * Author * ReviewedBy * DatePublished * DateModified * Publisher * MainEntityOfPage * About * Mentions * Citation * Image Potential FAQ topics: * What is the most popular payment method in Kenya? * What is the difference between M-PESA PayBill and Till? * How does M-PESA STK Push work? * Can an international merchant accept M-PESA? * Can M-PESA payments be refunded? * Does M-PESA support recurring payments? * Should merchants also accept cards in Kenya? * How should a merchant confirm an M-PESA payment? Do not add an FAQ answer to structured data unless the same answer is visible on the page.

Original asset recommendations Asset 1: M-PESA payment state machine Purpose: Show every state from checkout selection to final settlement, including delayed callbacks, duplicate attempts, refunds, and reconciliation. Intended reader: Developers, product managers, payment operations, and support leaders. Data required: * Initiation event * provider request ID * customer authorization * callback * status query * final payment status * fulfilment * reversal * refund * settlement Recommended format: Technical but editorially clean flowchart with separate customer, provider, merchant, and finance lanes. Recommended placement: Immediately after the mobile-money-first customer-journey introduction. Suggested caption: “An M-PESA payment is not complete when the prompt is sent—or even when the customer sees a debit. The merchant must resolve confirmation, fulfilment, refund, and settlement.”

Asset 2: PayBill versus Till versus STK Push versus QR Purpose: Help merchants choose the correct M-PESA collection model. Intended reader: Product, payments, engineering, sales, education, marketplace, and travel teams. Data required: * Who initiates * customer steps * account-reference support * immediate checkout suitability * physical-commerce suitability * confirmation * refund capability * recurring suitability * reconciliation complexity Recommended format: Four-column decision matrix with a compact “best used for” row. Recommended placement: Beside the section explaining collection models. Suggested caption: “PayBill, Till, STK Push, and QR all collect through M-PESA, but they solve different merchant and customer problems.”

Asset 3: Customer payment to usable merchant funds Purpose: Explain the separation between customer debit, business collection, provider settlement, bank payout, FX, and usable international merchant funds. Intended reader: Finance, treasury, legal, compliance, and executives. Data required: * Customer wallet * M-PESA operator * PayBill or Till * PSP or aggregator * settlement account * fees * tax deductions * Kenyan bank * FX * international payout * refund route Recommended format: Two-direction flow-of-funds diagram. Recommended placement: In the settlement and treasury section. Suggested caption: “A successful customer payment and an international merchant payout are separate events with different timing, participants, and risks.”

Visual recommendations Hero image concept Show a Kenyan mobile customer approving an M-PESA prompt while the payment continues through a visible operational chain behind the phone: * Merchant identity * STK prompt * callback * order confirmation * fulfilment * refund * reconciliation * settlement The merchant dashboard should show M-PESA as the principal domestic method, with cards and bank payments as supporting routes. Avoid: * Generic Nairobi skyline * Flag-dominated imagery * Oversized credit card * An M-PESA logo without a customer journey * A visual implying that confirmation and settlement occur simultaneously Hero caption: “In Kenya, the mobile-money account is part of the customer’s financial operating system. The merchant must connect it to an equally reliable commerce operation.” Hero alt text: “Illustration of a Kenyan customer approving an M-PESA payment connected to merchant confirmation, order fulfilment, refunds, reconciliation, and settlement.” Diagram concept Title: From M-PESA Prompt to Completed Order Show four lanes: 1. Customer 2. M-PESA or payment provider 3. Merchant platform 4. Finance and support Include branches for: * Approved * canceled * timeout * delayed callback * duplicate * refund * settlement exception Alt text: “Flowchart showing the M-PESA payment journey from customer prompt through callback, merchant fulfilment, refund, and financial reconciliation.” Chart concept Title: Mobile-Money Access Is Broader Than Card Access Compare: * M-PESA monthly active customers

* Mobile-money subscriptions * Registered mobile-money accounts * Debit cards * Credit cards * Mobile-broadband subscriptions * Connected smartphones The chart must state that these measures have different definitions and are not unique-customer totals. Alt text: “Comparison of M-PESA active customers, mobile-money subscriptions, mobile-money accounts, cards, smartphones, and broadband subscriptions in Kenya.” Map concept A map is appropriate only with credible county or regional data showing: * Mobile connectivity * agent access * merchant acceptance * tourism demand * delivery coverage * customer concentration Do not create an unsupported county-level “market opportunity” score. Suggested caption: “National mobile-money adoption does not mean that connectivity, agent access, merchant density, and logistics are identical across Kenya.”

Human review and contribution recommendations Required before publication Kenya payments specialist Review: * M-PESA terminology * PayBill, Till, STK Push, QR, and Pochi distinctions * Customer behavior * local method ordering * interoperability * merchant eligibility Payment product and integration specialist Review: * Callback states * status retrieval * idempotency * transaction references * refunds * Daraja functionality * recurring functionality * production integration requirements Kenyan regulatory counsel Review: * National Payment System Act * National Payment System Regulations * PSP and operator roles * marketplace fund flows * local entity requirements * merchant-category restrictions * customer-fund handling Kenyan tax adviser Review: * VAT * digital marketplace supplies * nonresident registration * eTIMS * withholding * marketplace treatment * Merchant of Record implications * refund adjustments Strongly recommended Treasury and settlement specialist Review: * KES settlement * domestic account needs * provider deductions * payout frequency * reserves * FX * international repatriation * refund liquidity Reconciliation and payment-operations specialist Review: * Callback delay * duplicate payment * unmatched payment * status retrieval * business statements * settlement reports * refund matching * support escalation Fraud specialist Review: * Social engineering * false STK prompts * fake screenshots * callback replay * account takeover * marketplace fraud * gaming and digital-goods risks Data-protection reviewer Review:

* Mobile-number processing * transaction records * fraud data * callback logs * cross-border transfers * retention * controller and processor roles Optional enhancement Kenyan gaming or digital-goods merchant Potential first-hand contribution: * Low-value transaction economics * prompt completion * duplicate-payment recovery * account-entitlement matching * refund abuse Marketplace or gig-platform operator Potential first-hand contribution: * Buyer collection * seller payout * PayBill references * delayed release * dispute handling * reconciliation Education or travel merchant Potential first-hand contribution: * Payer-to-student matching * booking references * mixed M-PESA and card customers * refund expectations * support lessons The publication should not imply that any proposed review or contribution has already occurred.

Final fact-check recommendations Verify immediately before publication: 1. Kenya’s 2025 nominal GDP. 2. The exact global nominal-GDP rank in the selected dataset. 3. Regional economic rank. 4. KNBS population projection and World Bank population distinction. 5. GDP per capita. 6. 2025 economic growth. 7. 2026 quarterly economic performance if retained. 8. Formal financial-inclusion percentage. 9. Current M-PESA monthly active customers. 10. M-PESA share of mobile-money subscriptions. 11. Total mobile-money subscriptions. 12. Total registered mobile-money accounts. 13. Active mobile-money agent count. 14. Definition of “active agent.” 15. M-PESA Kadogo transaction total and denominator. 16. Mobile-data and mobile-broadband subscriptions. 17. Connected-smartphone count and penetration methodology. 18. Individual internet-use percentage. 19. PayBill customer journey. 20. Till and Business Till functionality. 21. STK Push initiation and callback behavior. 22. Transaction-status and pull-transaction API availability. 23. Dynamic QR functionality. 24. Mobile-money interoperability. 25. Pochi la Biashara merchant use. 26. M-PESA reversal functionality. 27. Full and partial merchant-refund support. 28. Business-to-customer payout capability. 29. M-PESA Ratiba customer and merchant functionality. 30. Recurring API availability. 31. PesaLink participant coverage and transaction limit. 32. Debit-, credit-, and prepaid-card totals. 33. Local-acquiring availability. 34. Local entity and bank-account requirements.

35. KES settlement and international-payout options. 36. Authorized PSP directory and provider status. 37. National Financial Inclusion Strategy status. 38. Consumer-protection requirements. 39. Data-controller or processor registration requirements. 40. VAT and digital-marketplace registration. 41. Electronic-invoicing requirements. 42. Marketplace fund-handling requirements. 43. Settlement timing, fees, reserves, and deductions. 44. Tourism and travel-growth indicators. 45. Gaming, education, SaaS, and marketplace opportunity claims.