Сравнивая платёжных провайдеров в Кении, выясните, как платёж превращается в пригодную для учёта запись. Поступление M-PESA должно быть отнесено к нужному клиентскому счёту или счёту на оплату. Для выплаты нужно определить получателя, источник средств и порядок согласования до сверки результата. Это отдельные операционные требования, даже если оба потока идут в кенийских шиллингах. Поэтому полезный вопрос точнее, чем просто «поддерживает ли провайдер M-PESA»: сохраняют ли предлагаемые сервисы приёма и выплат необходимые вашему бизнесу данные и меры контроля?

24исторических предложений
12предложений приёма
12предложений выплат

Числа для предметного сравнения провайдеров

Мы разобрали исторические платёжные предложения, связанные только с этой страной. Всего уникальных записей: 24. Приём платежей: 12; выплаты: 12. На их основе можно предметно сравнить стоимость платежей, доступность денег и операционные требования. Предложения с несколькими странами исключены из расчётов: таких записей 66.

Источник — выгрузка PayStar от 14 сентября 2026 года с данными, предоставленными платёжными шлюзами. Агрегаты пересчитаны, но коммерческие заявления независимо не подтверждены. Это историческая выборка, а не обзор рынка, число PSP или методов, доказательство действующих подключений или текущей доступности. Условия могут меняться еженедельно и чаще. Независимые связи страны, валюты и метода не подтверждают все возможные платёжные маршруты. Число предложений по направлениям и график расчётных сроков охватывают все записанные валюты. Только сравнение процентов ниже ограничено записями комиссий в KES.

Уникальные предложения только этого GEO по всем записанным валютам: 24. Это не методы, провайдеры или действующие подключения.
Уникальные предложения только этого GEO по всем записанным валютам: 24. Это не методы, провайдеры или действующие подключения. Скачать SVG

Что показывают записанные процентные компоненты в KES

Мы считаем среднее арифметическое явно указанных процентных компонентов в KES, с одинаковым весом каждого сопоставимого предложения. Запись включена только при совпадении структурированного процента с одним однозначным процентом в исходном описании комиссии. Другая валюта комиссии, пропущенный процент и неоднозначное описание исключены.

Также исключены проценты с оговорками «от», диапазонами, тарифными ступенями и явно ограниченными категориями клиентов. Точный номинальный процент может остаться в выборке при фиксированном минимуме или максимуме комиссии; эти ограничения всё равно влияют на итоговое списание.

НаправлениеnСреднееМедианаДиапазон
Приём124,61%4,5%3–7,5%
Выплаты122,69%2,5%1,5–5,5%
Только явно указанные процентные компоненты в KES. n — сопоставимая выборка направления; пропуски исключены, а не приняты за нулевую комиссию.
Только явно указанные процентные компоненты в KES. n — сопоставимая выборка направления; пропуски исключены, а не приняты за нулевую комиссию. Скачать SVG

Это процентные компоненты, а не полная цена платежа. Отдельно нужно учитывать фиксированные комиссии, FX, налоги, резервы, минимумы, возвраты и другие нестандартные операции. Выборка не взвешена по обороту, не содержит измеренной конверсии и не позволяет ранжировать качество провайдеров. Малые или недостаточно независимые группы не публикуются.

Условный расчёт для одного платежа

Возьмём условный платёж 1 000 KES; это не типичный чек рынка. Применение округлённых средних из таблицы даёт:

  • Приём: 1 000 KES × 4,61% = 46,1 KES.
  • Выплаты: 1 000 KES × 2,69% = 26,9 KES.

Каждая строка — отдельное направление, а не общая цена комплексной услуги. Расчёт показывает только процентную часть. До расчёта чистой выручки запросите актуальные условия для вашего чека, оборота, модели бизнеса и валюты расчётов.

Важно, когда деньги становятся доступны

Предложения приёма по всем записанным валютам. T/D сохранены как в источнике: календарные или рабочие дни не предполагаются. «Другие» включает сложные обозначения и объединённые группы менее 3 записей. Это не гарантия сроков расчётов.
Предложения приёма по всем записанным валютам. T/D сохранены как в источнике: календарные или рабочие дни не предполагаются. «Другие» включает сложные обозначения и объединённые группы менее 3 записей. Это не гарантия сроков расчётов. Скачать SVG

Успешное уведомление об оплате и деньги, доступные бизнесу, — разные события. Используйте записанные сроки как вопросы к провайдеру: что запускает отсчёт, какой действует cut-off, учитываются ли выходные, на какой счёт приходят средства и могут ли резерв или проверка отложить доступность?

Для выплат согласуйте предфинансирование, проверку получателя, обработку отказов и отражение вернувшихся денег в остатке. Срок расчётов по приёму не доказывает время завершения выплаты.

Пример планирования денежного буфера

Если бизнес должен ежедневно финансировать обязательства на 100 000 KES, разрыв в один день требует 100 000 KES, в три дня — 300 000 KES. Дополнительный буфер составляет 200 000 KES. Это условная модель постоянного потока без комиссий, резервов и колебаний, а не наблюдаемое обещание сроков расчётов.

PayBill и Buy Goods начинаются с разных платёжных инструкций

Опубликованные инструкции Safaricom для клиентов различают эти два сценария приёма платежей. Для PayBill плательщик вводит номер бизнеса и номер клиентского счёта. Для Buy Goods инструкция требует номер торговой точки — till — и сумму. В FAQ PayBill Safaricom объясняет, что номер счёта помогает определить связь клиента с организацией-получателем. Платёжные инструкции Safaricom, FAQ PayBill.

Из этого различия следует вопрос для проверки. Если вы выставляете платежи по клиентским счетам или счетам на оплату, уточните, какой идентификатор возвращает провайдер и сохраняется ли он в отчётах по операциям. Для предложения с Till спросите, как система оплаты или продаж связывает полученный платёж с нужным заказом. Одни клиентские инструкции не подтверждают возможности сверки у конкретного PSP.

До сравнения цен запросите пример отчёта. Он должен позволять вашей команде определить идентификатор бизнеса, идентификатор транзакции провайдера, сумму, время оплаты и итоговый статус. Уточните, как сотрудники выясняют отсутствующий или неверный идентификатор и кто может изменить распределение поступления. Подтверждение платежа и отметка об оплате счёта должны опираться на одни и те же проверяемые данные.

Проверьте проблемное поступление, а не только успешную оплату

Рассмотрим вымышленную сервисную компанию в Кении с двумя счетами по 4 500 KES. Один клиент указывает нужный идентификатор счёта, а другой — посторонний. Два поступления в сумме дают 9 000 KES, но эта сумма не устанавливает, к какому счёту относится второй платёж.

Полезная демонстрация покажет, как платёж с верным идентификатором сопоставляется со своим счётом, а второй попадает в очередь исключений. Сотрудники сравнивают запись провайдера с подтверждающей информацией клиента, распределяют поступление по согласованной процедуре и сохраняют исходный идентификатор. Это предлагаемый тестовый сценарий, а не кейс клиента PayStar или утверждение о программном обеспечении каждого провайдера.

Попросите PSP повторить демонстрацию с дублирующим уведомлением. В учёте продаж не должны появиться два оплаченных счёта только потому, что об одной транзакции сообщили дважды. Цель — изучить подтверждения и обработку исключений до того, как объём операций сделает ручное разбирательство дорогим.

Проверяйте выплаты B2C как отдельную услугу

Safaricom описывает Business to Customer (B2C) как платежи бизнеса клиентам. Публичная документация включает управление доступом и платёжные выписки. Поэтому договорённости о приёме платежей оставляют отдельные вопросы о предлагаемом продукте выплат, получателях и доступе к отчётам. Документация Safaricom B2C.

Руководства Safaricom по B2C разделяют инициирование и согласование платежей и описывают настройку согласований. Руководство по счетам также различает рабочие счета и счета utility. Используйте это как основание запросить фактическую конфигурацию для вашего бизнеса; не предполагайте, что любой отображаемый остаток сразу доступен для выплаты. Руководство по платежам B2C, Руководство по счетам B2C.

ПотокКакое подтверждение запроситьКакое решение оно поддерживает
Приём платежа клиентаПоля идентификаторов, запись о транзакции и отчёт об исключенияхСможет ли финансовая команда правильно распределить каждое поступление?
Выплата B2CРазрешённое назначение, требования к получателю, счёт финансирования и настройки согласованияСможет ли этот бизнес безопасно инициировать нужные платежи?
Неудачная или спорная операцияЗапись о результате, процедура расследования и условия обратной операцииСмогут ли сотрудники решить проблему без слепого повторения платежа?

Средства контроля в портале и API нельзя считать взаимозаменяемыми. В опубликованной документации B2C API Safaricom указано, что запросы B2C, отправленные через API, не требуют ручного согласования. Спросите PSP, как выполняется собственное согласование вашего бизнеса до отправки поручения через API. Руководство Safaricom B2C API.

Для выплат в KES выясните, кто пополняет счёт отправителя, когда средства становятся доступны, кто может согласовывать поручения и какое подтверждение устанавливает результат для получателя. Включите в демонстрацию тайм-аут или неизвестный результат. Получите процедуру расследования и повторных попыток провайдера до отправки нового поручения. Отдельно запросите условия обратной операции: наличие такой функции не означает, что любой завершённый платёж всегда можно вернуть.

Проверьте сторону договора и движение средств

Центральный банк Кении публикует реестр организаций с разрешёнными им услугами. Сопоставьте юридическое лицо в предложении с соответствующей записью регулятора и попросите PSP объяснить роль других организаций в схеме. Реестр — отправная точка проверки, а не подтверждение допуска конкретного мерчанта, отрасли или трансграничной схемы. Реестр CBK.

Раздельно зафиксируйте комиссии за приём и выплаты, условия перечисления в банк, требования к финансированию и ответственность за исключения. Подтвердите с провайдером компанию — сторону договора, вид деятельности, необходимые документы и принимающий банковский счёт. Возможность внутренних платежей в KES сама по себе не устанавливает доступность для иностранного мерчанта или перечисление средств за пределы Кении.

Роль PayStar

PayStar предоставляет информацию для сравнения платёжных решений и, если это согласовано, технический слой для подключения и управления ими. PayStar не является банком или поставщиком платёжных услуг и не принимает, не хранит и не осуществляет расчёты по средствам клиентов или бизнеса от своего имени.

Вы выбираете платёжного провайдера и заключаете с ним прямой договор. Провайдер обрабатывает платежи и выполняет расчёты по этому договору. Доступность услуги, необходимые разрешения и коммерческие условия проверяются для вашей компании и задачи. Описание метода в статье не означает, что он доступен через PayStar именно вашему бизнесу.

Информация о платёжных вариантах бесплатна. Обработка платежей и согласованные технические услуги имеют отдельные коммерческие условия.

Официальные источники и рамки исследования

  1. Safaricom: Paying to Businesses and Online
  2. Safaricom: M-PESA PayBill FAQ
  3. Safaricom: Business to Customer API
  4. Safaricom: M-PESA Bulk Payment B2C guide
  5. Safaricom: M-PESA B2C account guide
  6. Central Bank of Kenya: Authorized PSP directory

Проверка источников: 8 октября 2026. Дата выгрузки остаётся 14 сентября 2026. Описания местных систем дают контекст, а не подтверждение возможностей конкретного провайдера.