Пакистан: Raast, JazzCash и easypaisa без путаницы между переводом и эквайрингом

Заказ оплачен «на JazzCash» — этой фразы недостаточно для сверки. Покупатель мог выполнить перевод, оплатить через торговый шлюз или получить токен для последующей оплаты. Аналогично Raast может появляться внутри приложения другого поставщика. Бренд на телефоне не равен виду операции, а появление инструкции к оплате не равно получению денег.

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

Raast ID и merchant alias решают разные задачи

SBP описывает Raast ID для P2P как мобильный номер, связанный со счётом. Перевод можно адресовать зарегистрированному ID либо IBAN; для отправки не требуется собственный Raast ID. В FAQ для физических лиц указана связь одного ID с одним счётом и возможность перепривязки. Сам рельс в этом описании предназначен для внутренних переводов, а конкретные лимиты следует уточнять в банке.

Практический вывод: телефон нельзя хранить как вечное доказательство банковского назначения. Нужны результат проверки получателя и снимок выданных реквизитов для каждой попытки. Если организация собирает деньги за товары или услуги, в досье подключения должно быть ясно, почему используется именно выбранный тип счёта и договора. Личный alias сотрудника не становится торговой инфраструктурой из-за интеграции в кассу.

Raast P2M предусматривает QR, merchant alias, IBAN и Request to Pay с немедленным либо отложенным сроком оплаты. SBP требует проверки бизнеса при подключении и возможности обрабатывать запросы возврата, которые мерчант принимает или отклоняет. Предусмотрены оперативные уведомления о подтверждении или отказе. Это требования к участникам, а не доказательство, что любой банк уже выдал вашему предприятию все функции. Циркуляр о P2M.

Request to Pay — предложение оплатить, не списание

Внутри кассы отделяйте создание запроса от согласия плательщика и финансового результата. Для собственного учёта полезны order ID, attempt ID, идентификатор запроса у поставщика, срок действия, ожидаемая сумма, получатель и итоговый transaction reference. Это рекомендуемая модель данных; конкретные названия API-полей задаёт ваш MSP, а не данная статья.

Учебная ситуация: клиент открыл запрос Later, затем самостоятельно отправил перевод по IBAN. Если процессинг продолжает считать два пути независимыми заказами, возможны двойная оплата и двойная выдача. Нужна политика сопоставления альтернативных попыток одного заказа. Подтверждённую лишнюю оплату обрабатывают отдельно, не растворяют её в следующем заказе клиента и не отправляют случайному адресату из чата.

JazzCash: сохраняйте точную семантику полей

В опубликованной документации шлюза pp_TxnRefNo задаётся мерчантом, pp_Amount передаётся без десятичного разделителя в принятом денежном масштабе, pp_TxnCurrency содержит PKR. Также используются сроки операции и pp_SecureHash. Возврат связывается с исходной операцией через reference. Это конкретная опубликованная версия интерфейса: перед production нужно сверить её с выданной вам спецификацией, включая подпись и порядок статусов.

Особенно дорого стоит ошибка масштаба суммы. Тест 100 PKR должен проверять не только экран покупателя, но и запрос, ответ, отчёт и банковское движение. Копирование числа из одного формата в другой без проверки может дать расхождение в сто раз. Храните сумму во внутреннем однозначном формате и преобразуйте её на границе интеграции, с отдельными тестами для каждой версии API.

JazzCash в описании подключения указывает проверку документов, биометрию, подписание договора и регистрацию на имя бизнеса; в eligibility названы CNIC и NTN. Наличие consumer-кошелька не заменяет эти этапы. Перечень доступных способов оплаты шлюза включает мобильный аккаунт, карты и vouchers, поэтому имя JazzCash само по себе не определяет инструмент финансирования покупки.

easypaisa: токен не является подтверждённой оплатой

В merchant FAQ easypaisa среди способов шлюза перечислены Mobile Account и OTC: токен, который оплачивается через указанные точки и банковские каналы. Для операционной команды принципиально сохранить отдельное состояние «ожидается оплата токена». Нельзя зачислять деньги при его создании. Срок ожидания, возможность повторной оплаты и окончательный статус должны быть получены из вашей действующей спецификации.

Условия easypaisa для перехода retailer в merchant отдельно описывают договор с банком, использование для законных товаров и услуг, назначаемые лимиты и возможность корректирующих списаний. Это хороший контрпример обещанию «получил на кошелёк — больше никто не тронет». Документ не позволяет объявлять любую операцию безусловно необратимой или переносить агентские права на торговый приём.

Где возникает настоящая операционная нагрузка

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

Расчёт с мерчантом сверяйте отдельно от клиентской оплаты. Договор должен объяснять комиссии, удержания, доступный остаток, банковский счёт назначения и сроки после выходных. «Real-time» в описании приёма не обещает одинаковую доступность всех выводов. Возврат по исходной операции и новая исходящая выплата также требуют разных оснований и идентификаторов.

Лицензия на платёжный сервис не лицензирует азартные игры

Pakistan Code содержит специальное законодательство о предотвращении азартных игр. Поэтому иностранная gambling-лицензия и подключение регулируемого кошелька не подтверждают допустимость такого бизнеса в Пакистане. Этот разбор технических методов не является маршрутом для обхода ограничений. До коммерческого запуска нужны применимые местные основания деятельности и явное согласование категории обслуживающей организацией.

Хорошее подключение можно объяснить одним предложением с проверяемыми деталями: кто платит, кому, в каком продукте, на каком основании и каким сообщением подтверждается результат. Если вместо этого остаётся только «местный партнёр всё решит», риск не устранён, а скрыт от мерчанта.