Продажи в СНГ: Kaspi, Payme, Click, ERIP и почему карта не всегда работает

# Продажи в СНГ: Kaspi, Payme, Click, ERIP и почему карта не всегда работает

Заявка пришла в четверг вечером — женщина из Алматы, оформила заказ на партию промышленных фильтров, сумма приличная, под сто тридцать тысяч тенге. Дошла до оплаты, ввела номер карты, экран покрутился и выдал ошибку. Попробовала ещё раз — та же ошибка. Написала в чат поддержки: «У меня карта Kaspi Gold, она не проходит». Менеджер, который отродясь не сталкивался с покупателями не из России, растерялся, предложил оплатить банковским переводом по реквизитам — процедура, которая для случайного розничного покупателя выглядит откровенно пугающе и неудобно, где-то на грани «это вообще не разводка?». Заказ так и остался неоплаченным, женщина ушла, скорее всего, к тому продавцу, у которого оплата с первого клика.

Я разбирал этот случай уже постфактум, когда владелец магазина спросил, почему у него в аналитике из месяца в месяц болтается заметная доля брошенных корзин именно у покупателей с казахстанским, узбекским и белорусским IP — притом что органический трафик из этих стран не выглядит случайным, его вполне прилично приводит и поиск, и сарафанное радио от русскоязычных сообществ. Магазин продаёт на русском языке, ассортимент интересен покупателям из соседних стран, доставка транспортными компаниями через границу давно отработана — но платёжный шлюз стоит один, российский, заточенный под карты Visa и Mastercard, выпущенные российскими банками, плюс СБП. И вот тут вся цепочка красиво выстроенной воронки продаж упирается в стену на последнем шаге, том самом, где деньги должны перейти от покупателя к продавцу.

Дальше выяснилось ещё интереснее. Я попросил выгрузку заказов за полгода и разбил её по странам покупателя, определённым по IP из логов аналитики. Из России — конверсия из визита в оплаченный заказ на привычном для ниши уровне. Из Казахстана — трафика почти столько же в абсолютных цифрах, сколько из какого-нибудь среднего российского региона, а конверсия в оплату — в три с половиной раза ниже. Из Узбекистана — трафика меньше, но конверсия ещё хуже, почти в пять раз. Из Беларуси, как ни странно, разрыв не такой драматичный — процентов на тридцать ниже российской, и это тоже наводящий факт, к которому мы ещё вернёмся, когда будем разбирать белорусский случай отдельно. При этом ни один из этих визитов не был случайным трафиком с рекламного клика в чужой стране — это были люди, которые целенаправленно искали конкретный товар на русском языке, доходили до сайта, клали товар в корзину и в подавляющем большинстве случаев отваливались именно на странице оплаты, а не раньше.

Это не редкий частный случай, а системная особенность рынка, о которой мало кто задумывается, пока не увидит цифры брошенных корзин в разрезе по геолокации. Русский язык — общий для десятков миллионов людей далеко за пределами России, и поисковики совершенно исправно показывают русскоязычным пользователям в Казахстане, Узбекистане и Беларуси те же самые сайты, что и пользователям в Москве или Новосибирске. Трафик приходит бесплатно, просто в силу языковой и культурной связности региона. А вот платёжная инфраструктура этих стран — это не Visa и Mastercard в чистом виде, это отдельные национальные экосистемы со своими правилами, своими картами и, что важнее всего, своими привычками покупателей, которые сформировались годами и которые невозможно просто проигнорировать, предложив взамен банковский перевод по реквизитам.

Трафик приходит, деньги — нет

Смысл проблемы легко проговорить одной фразой, но стоит разложить её по частям, чтобы понять, почему она настолько упорно повторяется на самых разных магазинах. Часть карт, выпущенных банками в Казахстане, Узбекистане и Беларуси, физически не входят в международные платёжные системы Visa и Mastercard — например, значительная доля повседневных платежей в Казахстане идёт через собственную платёжную систему банка Kaspi, а в Узбекистане расчёты бытового уровня массово идут через локальные карты Humo и UzCard, которые не эквивалентны международному пластику и не всегда принимаются шлюзами, заточенными строго под Visa/Mastercard. Дальше добавляется ещё один слой проблемы: даже там, где карта технически совместима с международными системами, покупатель может просто не иметь привычки платить картой через форму на незнакомом сайте — потому что в его повседневной жизни платежи давно перешли в формат приложения на телефоне, QR-кода, локального агрегатора.

А есть ещё момент, который чаще всего упускают из виду российские предприниматели, — большинство платёжных шлюзов, интегрированных в российские интернет-магазины, физически не поддерживают приём в национальной валюте покупателя. ЮKassa и Тинькофф, о которых я подробно писал в статье про оплату без лишних плагинов, заточены под расчёты в рублях с российскими банками-эмитентами. Формально международная карта может через них пройти, если банк-эмитент поддерживает трансграничные операции и у него нет ограничений, но по факту конверсия у иностранного покупателя резко падает, потому что вся форма оплаты, вся логика обработки ошибок, все банковские 3-D Secure подтверждения выстроены с расчётом на внутрироссийский платёжный контур.

Стоит понимать и масштаб явления в контексте всего рынка, а не только одного конкретного магазина. Русскоязычный сегмент интернета исторически объединяет не только Россию — это касается и части Казахстана, где русский язык остаётся одним из основных в деловой среде и в интернет-поиске, и значительной части городского населения Узбекистана и Беларуси. Поисковые системы не делают различий по государственной границе там, где граница не выражена явно в языке запроса — человек в Алматы, который ищет «купить промышленный фильтр», получает в выдаче ровно те же сайты, что и человек в Екатеринбурге, если, конечно, у сайта нет геотаргетинга, который специально отсекает не-российский трафик. Большинство небольших и средних интернет-магазинов такого таргетинга не настраивают вообще, просто потому что не задумывались об этом — и в итоге собирают трафик из соседних стран как побочный эффект, даже не планируя это целенаправленно.

Собрать реальную цифру, «сколько теряет типичный магазин из-за этого», честно говоря, трудно — она сильно зависит от ниши, от доли трафика из СНГ и от среднего чека. Но логика примерно такая: если у вас в аналитике заметная доля визитов с IP из Казахстана, Узбекистана или Беларуси, и при этом конверсия из этих визитов в разы ниже, чем из российских, а на этапе оплаты растёт доля отказов именно у этой аудитории — вы, скорее всего, смотрите ровно на эту проблему, просто она замаскирована под общую «низкую конверсию из региона», хотя причина куда конкретнее: покупатель физически не может провести платёж привычным для себя способом.

Есть и четвёртый пласт причин, чуть более прозаичный, но не менее реальный — это банальное доверие к форме оплаты. Покупатель из другой страны, попадая на незнакомый сайт, интуитивно более осторожен, чем покупатель, который видит знакомый интерфейс банка, к которому привык. Если единственный способ оплаты — ввести данные карты в стороннюю форму, у которой нет узнаваемого логотипа локального провайдера, у части аудитории просто срабатывает защитный рефлекс — «а вдруг это мошенники», и человек уходит проверять магазин по отзывам, а по дороге забывает вернуться или находит альтернативу. Наличие узнаваемой иконки Kaspi или значка bePaid на странице оплаты работает не только как технический канал приёма денег, но и как визуальный сигнал доверия — примерно так же, как логотип ЮKassa или СБП работает для российского покупателя.

Стоит добавить и ещё один нюанс, который отдельно всплывает у B2B-покупателей из соседних стран — а такие тоже встречаются, особенно в нишах вроде промышленного оборудования и запчастей, где закупки идут не только в розницу. Юридическое лицо из Казахстана или Узбекистана, которое хочет купить партию товара, сталкивается с ровно тем же ограничением, что и частный покупатель, только на большую сумму, и вместо неудачной попытки оплаты картой просто переходит к запросу коммерческого предложения и оплате по счёту напрямую, минуя интернет-магазин как канал вообще — тема, которую я разбирал отдельно в статье про запрос коммерческого предложения в B2B. Для крупных закупок это рабочий обходной путь. Для розничного покупателя с чеком в сто тридцать тысяч тенге — как в истории, с которой началась эта статья — выставлять отдельный счёт и объяснять реквизиты уже перебор, и именно здесь чаще всего теряются деньги.

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

Казахстан: Kaspi — это не эквайринг, а привычка

Про Kaspi нужно понимать одну вещь до того, как разбираться в технических деталях: это не просто ещё один банк с приложением, это целая платёжная культура, которая сформировалась в Казахстане за последние годы и стала default-способом расчёта для огромной доли населения. Люди платят через приложение Kaspi за коммуналку, за такси, переводят друг другу деньги, оплачивают покупки в магазинах через QR-код прямо с телефона — карта физически может даже не доставаться из кошелька. Когда казахстанский покупатель видит на сайте только форму «введите номер карты», для значительной части аудитории это уже морально устаревший, неудобный способ платить, даже если формально их карта Kaspi Gold технически совместима с международной платёжной системой.

С инженерной точки зрения принять оплату через Kaspi — это не абстрактная задача «подключить ещё один способ оплаты», а полноценная интеграция со своим протоколом: мерчант создаёт платёж через API Kaspi, получает ссылку или QR-код, покупатель подтверждает оплату в своём приложении, а магазин получает уведомление через вебхук с подписью, которую нужно проверить, прежде чем считать заказ оплаченным. Мы реализовали для нашего плагина класс платёжного шлюза под Kaspi Pay именно по этой схеме — со своим методом создания платежа, обработкой колбэка, поддержкой возвратов, и заодно зарегистрировали в WooCommerce тенге как валюту, потому что без этого магазину пришлось бы вручную городить конвертацию курса для каждого казахстанского заказа.

Но здесь я должен сказать честно то, что сказал бы любому, кто спросит меня напрямую: этот шлюз готов как инженерная заготовка, а не как готовое к бою решение прямо из коробки. Причина простая и не имеющая отношения к качеству кода — Kaspi, как и большинство банков в СНГ, не публикует открытую документацию своего платёжного API в свободном доступе. Точный формат запроса на создание платежа, реальное название заголовка подписи, структура тела вебхука — всё это выдаётся мерчанту только после того, как он заключил договор с банком и получил доступ в личный кабинет продавца, где, собственно, и лежит техническая спецификация. Мы построили класс шлюза по наиболее вероятной, разумной структуре протокола на основе публично доступной информации о работе с Kaspi Pay и сложившейся практики похожих интеграций, отметили каждое предположение прямо в коде явным флагом «нужно сверить с реальной документацией банка» — от точного пути эндпоинта до формата кодов статуса вебхука.

Смысл в том, что когда конкретный магазин заключает прямой договор с Kaspi и получает боевые ключи доступа, работа по подключению — это не разработка с нуля, а сверка уже готового кода с реальной спецификацией банка и правка тех нескольких мест, где наше предположение могло не совпасть с фактическим форматом протокола. Это принципиально другой объём работы и другие сроки, чем писать интеграцию заново, но это всё же не «включил галочку — и заработало», потому что шаг с заключением договора с банком и получением рабочих учётных данных — это не техническая, а коммерческая задача, которая целиком лежит на стороне магазина и банка, и никакой плагин её не может проскочить или заменить.

Почему вообще Kaspi так закрыт с точки зрения документации, если это крупнейшая финтех-компания страны с миллионами активных пользователей? Мой ответ — потому что Kaspi исторически строился как экосистема для собственного рынка, а не как публичная платформа для сторонних разработчиков наподобие Stripe или той же ЮKassa, которая держит открытую документацию именно потому, что её бизнес-модель — быть максимально доступной для любого мерчанта без исключения. У банка с доминирующим положением на локальном рынке просто нет такого коммерческого стимула распахивать двери — им выгоднее вести каждого крупного мерчанта через персональное сопровождение менеджера по подключению, чем публиковать спецификацию, по которой кто угодно сможет подключиться самостоятельно за один день. Это разумно с их точки зрения и неудобно с точки зрения любого разработчика, который хочет подготовиться заранее, но это данность, с которой приходится работать, а не бороться.

Отдельно скажу про безопасность этой части кода, потому что здесь мы не позволили себе никаких компромиссов даже в статусе заготовки. Все обращения идут только с проверкой SSL-сертификата без исключений, тело вебхука читается напрямую из потока запроса исключительно для проверки криптографической подписи, без какой-либо десериализации содержимого в исполняемые структуры, а сравнение самой подписи всегда идёт через функцию, устойчивую к атакам по времени отклика, а не через простое сравнение строк, которое теоретически можно продавить перебором за счёт замера микросекундных задержек ответа сервера. Секретные ключи в интерфейсе настроек всегда показываются в замаскированном виде — видны только последние несколько символов, — и при сохранении настроек форма не перезаписывает уже сохранённый ключ пустым значением, если админ просто не тронул это поле. Это тот уровень инженерной дисциплины, который мы закладываем в код независимо от того, подключён шлюз к реальному банку сегодня или это произойдёт через полгода — потому что переписывать защиту данных задним числом, когда шлюз уже обрабатывает боевые платежи, — куда более рискованная затея, чем сделать её правильно с первого дня.

Узбекистан: два конкурента, два протокола

С Узбекистаном ситуация интереснее вдвойне, потому что там нет одного доминирующего игрока вроде Kaspi — рынок платежей поделен между двумя крупными конкурирующими агрегаторами, Payme и Click, у каждого своя аудитория и, что важно для разработчика, полностью разные протоколы работы, которые невозможно свести к одному общему решению.

Click работает по схеме, знакомой любому, кто когда-либо интегрировал платёжные системы с редиректом: покупатель перенаправляется на хостинговую страницу оплаты Click, вводит там данные своей карты — UzCard, Humo или баланс Click Evolution, — а магазин получает два обратных вызова от Click на свой сервер: сначала запрос «Prepare», в котором нужно подтвердить, что заказ существует и сумма верна, а затем запрос «Complete», подтверждающий, что оплата прошла и заказ можно считать оплаченным. Подпись каждого такого колбэка проверяется через MD5-хеш из конкатенации нескольких полей — это не самый современный криптографический механизм, но это протокол, который задаёт сам Click, а не мы, поэтому наша задача — грамотно защитить сравнение этой подписи через криптографически безопасное сравнение строк, чтобы хотя бы не открыть дополнительную дыру поверх не самого сильного алгоритма, который использует сам банк.

Payme устроен принципиально иначе — это не REST с редиректом, а JSON-RPC 2.0, тот же протокол, которым пользуются многие внутренние API, но крайне редко встречающийся в мире привычных вебхуков. Шесть методов жизненного цикла транзакции — проверка возможности платежа, создание, подтверждение, отмена, повторная проверка статуса, выгрузка выписки — все они приходят на один и тот же наш адрес одним и тем же способом, и уже внутри нужно различать, какой именно метод вызван, и отвечать в правильном формате JSON-RPC конверта, с правильными кодами ошибок из зарезервированного Payme диапазона. Авторизация там идёт через Basic Auth, что тоже добавляет забавную деталь: в зависимости от того, как сконфигурирован сервер — на Apache с mod_php или на PHP-FPM — стандартные переменные с логином и паролем могут просто не долетать до PHP, и приходится вручную разбирать заголовок Authorization, чтобы не потерять авторизацию только из-за особенностей серверного окружения.

Оба шлюза, опять же, реализованы у нас как полноценные классы платёжных методов WooCommerce — с приёмом соответствующих колбэков, хранением состояния транзакции, поддержкой возврата: у Payme это отдельный вызов отмены транзакции, инициированный уже с нашей стороны в сторону кассы Payme, потому что прямого REST-эндпоинта на возврат у них попросту нет — весь жизненный цикл транзакции идёт через тот же JSON-RPC. Валюта — узбекский сум — регистрируется в WooCommerce один раз, независимо от того, какой конкретно из двух шлюзов в итоге включит магазин, потому что оба они работают в одной и той же национальной валюте.

И снова та же честная оговорка, что и с Kaspi: оба шлюза — это готовая инженерная работа, ожидающая реального договора с агрегатором. У Payme, например, есть тонкость, о которой стоит знать заранее — не все контракты с Paycom (компания, стоящая за Payme) разрешают мерчанту самостоятельно инициировать возврат через API; в части договоров возврат обязан идти только из личного кабинета банка, а не программно. Это ровно тот случай, когда бумажный договор диктует техническую архитектуру, а не наоборот, и любой, кто обещает вам «полностью автоматические возвраты по Payme» без оглядки на конкретные условия вашего контракта, скорее всего, либо не разбирался в вопросе, либо говорит про какой-то усреднённый случай, который не обязательно совпадёт с вашим.

Есть и ещё одна тонкость именно узбекского рынка, которая всплывает не сразу, а только когда магазин начинает продавать туда серьёзные объёмы — фискализация. У Payme в протоколе `CheckPerformTransaction` предусмотрен блок с детализацией чека по каждой позиции заказа — для фискальных мерчантов, обязанных предоставлять построчную детализацию покупки с указанием ставок налога. Для немалого числа магазинов, которые продают в Узбекистан нерегулярно и без местного юридического присутствия, эта детализация попросту не нужна, и наш код сейчас отвечает упрощённо, подтверждая саму возможность платежа без построчной раскладки. Но если у вашего бизнеса в Узбекистане уже есть локальное юрлицо и обязанность фискализации — это тот участок протокола, который придётся дорабатывать предметно под ваш случай, и мы говорим об этом прямо, а не прячем за общей фразой «поддерживает Payme».

Раз уж мы заговорили про две конкурирующие системы на одном рынке — интересно, что выбор между Payme и Click для конкретного магазина редко бывает техническим решением. Чаще это решение, продиктованное аудиторией: если основная масса ваших покупателей в Узбекистане пользуется одним из сервисов активнее другого, разумнее сначала подключать именно его, а не пытаться сразу тащить оба. Мы сознательно сделали оба шлюза независимыми классами, которые можно включать по отдельности, именно чтобы не заставлять магазин выбирать сразу оба протокола, если для начала достаточно одного.

Беларусь: ЕРИП — не банк, а дерево

С Беларусью история устроена ещё интереснее, потому что ЕРИП — Единое Расчётное и Информационное Пространство — это вообще не банк и не один конкретный сервис с одним API. Это государственная инфраструктура, огромное дерево зарегистрированных услуг, через которое белорусские граждане оплачивают буквально всё — от коммунальных услуг до штрафов и, что нам интересно, покупок в интернет-магазинах. Чтобы принимать оплату через ЕРИП, недостаточно «подключить API» — нужно, чтобы твоя услуга в принципе была зарегистрирована где-то в этом дереве, а сделать это напрямую, без посредника, может далеко не каждый бизнес.

На практике для интернет-магазина есть по сути три пути. Первый и самый тяжёлый — прямая интеграция с одним из белорусских банков, например Белгазпромбанком или Приорбанком: это собственный протокол каждого банка, обычно на устаревающем XML-формате, обязательный банковский договор и, что особенно неприятно для разработки, отсутствие тестовой среды до того, как у вас на руках уже есть реальный merchant ID — то есть даже потренироваться на песочнице нельзя, пока договор не подписан. Второй путь — тот же расклад с другим банком, тот же уровень трудозатрат. А третий, которым в итоге воспользовались мы при разработке нашего шлюза, — это интеграция через bePaid.by, крупнейший независимый агрегатор в Беларуси, у которого есть внятный REST API для чекаута, поддержка типа платежа именно «erip» внутри их протокола, песочница для тестирования и документация на английском языке, которая покрывает подавляющее большинство реальных сценариев подключения магазинов.

Мы сознательно выбрали именно bePaid как первую цель для этого шлюза, а не прямую интеграцию с конкретным банком — по той же логике, что и с любым инженерным решением: если один путь закрывает девяносто с лишним процентов практических случаев с разумными трудозатратами, а другой требует отдельного банковского договора на каждый из двух-трёх банков ради оставшихся процентов, разумнее сперва закрыть основной путь. Прямые интеграции с Белгазпромбанком или Приорбанком остаются реалистичным следующим шагом, если у конкретного магазина появится такая необходимость и, что важнее, готовность пройти отдельный банковский онбординг именно с этим конкретным банком.

Валюта — белорусский рубль — точно так же регистрируется в WooCommerce отдельным фильтром, а проверка подписи вебхука сделана с запасом — сначала пробуем проверить через HMAC-подпись в заголовке, если bePaid его присылает, и с фолбэком на базовую авторизацию, если по факту приходит именно она. И, опять же, честно: точное название заголовка подписи — из тех деталей, которые предстоит свериться с актуальной документацией bePaid уже на этапе реального подключения конкретного магазина, а не то, что можно было надёжно зафиксировать заранее без доступа к их текущему личному кабинету мерчанта.

Возвращаясь к цифре из начала статьи — почему именно у белорусского трафика просадка конверсии в оплату оказалась не такой драматичной, как у казахстанского и узбекского. Мне кажется, дело в том, что в Беларуси всё-таки заметно выше доля покупателей, у которых на руках есть карта, полноценно совместимая с международными платёжными системами, и привычка платить картой через браузерную форму там не выглядит настолько чуждой, как в случае с Kaspi-культурой Казахстана. Это не значит, что подключать ЕРИП не нужно — какая-то часть аудитории всё равно платит принципиально только через эту систему, у кого-то попросту нет международной карты вовсе, — но приоритет между тремя рынками стоит выставлять исходя из реальной структуры своего трафика, а не из абстрактного «СНГ = одна большая недоступная территория», потому что степень недоступности у каждой из трёх стран своя, и она поддаётся измерению через обычную аналитику, если знать, куда смотреть.

Что стоит между кодом и первым платежом

Я специально построил эту статью не как рекламный список «у нас есть Kaspi, Payme, Click и ЕРИП, подключайте», а как честный разбор того, что реально нужно, чтобы принимать платежи из этих стран, потому что видел слишком много маркетинговых обещаний в этой нише, которые на поверку оказывались красивой формой на сайте, отправляющей данные в никуда, или интеграцией, которая не проходила простейшую боевую проверку из-за неверно угаданного формата протокола. Реальность такая: подключение любого из этих четырёх шлюзов в боевом режиме требует не только кода, но и договора с конкретным банком или агрегатором, реальных производственных ключей доступа и обязательной сверки протокола с их актуальной документацией, потому что банки меняют детали реализации без публичного анонса, а верить чужому пересказу многолетней давности — верный способ получить загадочную ошибку подписи в самый неподходящий момент, когда покупатель уже готов заплатить.

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

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

Хочу проговорить и ещё одну развилку, которая встаёт перед любым владельцем магазина на этом этапе: строить ли отдельный ценник для покупателей из каждой страны, с расчётом в местной валюте, или продолжать выставлять цену в рублях и просто дать локальный способ оплаты поверх неё. Однозначного правильного ответа здесь нет — это вопрос из разряда позиционирования, а не только техники. Ценник в рублях с конвертацией по текущему курсу прямо на странице оплаты честен и прозрачен, но требует от покупателя лишнего мысленного усилия — прикинуть, сколько это в его местной валюте, и курс может неприятно скакнуть между моментом, когда человек положил товар в корзину, и моментом, когда он вернулся оплатить через два дня. Ценник сразу в тенге, сумах или белорусских рублях снимает эту неопределённость, но требует отдельного, постоянно обновляемого прайса и решения, как быть с курсовой разницей на стороне продавца, который в итоге получает выручку в рублях после конвертации через банк или агрегатор. Крупные магазины с заметным объёмом продаж в конкретную страну обычно приходят ко второму варианту, потому что прозрачность цены напрямую конвертируется в доверие и меньшее число брошенных корзин на последнем шаге. Для магазина с эпизодическими заказами первый вариант — рублёвый ценник с локальной оплатой поверх — выглядит разумным компромиссом, который не требует содержать отдельный прайс-лист ради нескольких заказов в месяц.

И есть, конечно, обратная сторона вопроса, о которой честно нужно сказать: не каждому магазину вообще нужны локальные шлюзы. Если доля заказов из Казахстана, Узбекистана или Беларуси у вас невелика — скажем, единичные заказы в месяц, — тратить месяцы на заключение банковского договора с зарубежным партнёром, проходить их комплаенс-процедуры и поддерживать ещё один платёжный метод в админке ради полутора процентов оборота — сомнительная инвестиция времени и денег. В этом случае разумнее честный, проверенный путь — трансграничный эквайринг через международную карту, который худо-бедно закрывает часть спроса, и явное указание на сайте, что для покупателей из этих стран доступна оплата международной картой либо банковским переводом, оформленным по-человечески, с понятной инструкцией, а не сухими реквизитами в один абзац. Порог, после которого стоит вкладываться в отдельную локальную интеграцию — это не универсальное число, а вопрос сопоставления реального объёма упущенных заказов с ценой и сроками подключения конкретного шлюза, и этот расчёт у каждого бизнеса свой.

Честно говоря, я не берусь предсказать, когда конкретно российский интернет-бизнес массово придёт к тому, что подключение локальных платёжных методов СНГ станет таким же стандартным пунктом чек-листа запуска магазина, как сегодня подключение ЮKassa или СБП. Но тенденция очевидна: граница между русскоязычным интернет-пространством и государственными границами становится всё более условной для покупателя и всё более значимой для того, кто эти деньги должен реально получить. Мы предпочли подготовить инженерную часть этого пути заранее, честно обозначив, где заканчивается код и начинается работа с банком, а не обещать то, чего пока не можем гарантировать.

Мне вообще кажется важным проговаривать эту границу вслух, а не смазывать её маркетинговым языком, потому что именно в платёжной теме цена обмана ожиданий выше, чем где бы то ни было ещё в интернет-магазине. Если у вас не работает красивый баннер на главной странице — это обидно, но не смертельно. Если у вас не работает или, того хуже, работает неправильно платёжный шлюз — это либо потерянные деньги покупателя, зависшие между его банком и вашим магазином без внятного объяснения, либо задвоенное списание, либо заказ, отмеченный оплаченным, хотя оплата на самом деле не прошла. Именно поэтому, разрабатывая любой платёжный шлюз, даже в статусе инженерной заготовки, мы закладываем в него защиту от таких сценариев с самого начала, а не откладываем на потом: проверка суммы входящего колбэка против суммы заказа с точностью до копейки, защиту от повторного зачисления уже оплаченного заказа при дублирующемся вебхуке — банки нередко присылают одно и то же уведомление не один раз, если не получили от вас ответ достаточно быстро, — и идемпотентную обработку повторных запросов create/perform/cancel с одним и тем же идентификатором транзакции, чтобы повторный вызов возвращал уже сохранённое состояние, а не пытался повторно провести операцию.

Расскажу, почему это не абстрактная перестраховка, а реальный сценарий, с которым сталкивается практически любая платёжная интеграция рано или поздно. Сеть между покупателем, банком и вашим сервером не идеальна — где-то происходит таймаут, где-то временная недоступность сервера в момент пиковой нагрузки. Банк в такой ситуации, не получив от вас подтверждения в срок, скорее всего, попробует отправить тот же самый колбэк ещё раз, иногда и не один. Если ваша логика на этот счёт не продумана, повторный колбэк рискует повторно записать оплату по уже оплаченному заказу, что в лучшем случае создаст путаницу в бухгалтерии, а в худшем — приведёт к двойному зачислению или к ошибочному повторному списанию средств у покупателя. Идемпотентность — то есть гарантия, что повторный одинаковый запрос не меняет состояние системы второй раз, — это не изящная архитектурная деталь ради красоты кода, а прямая защита и продавца, и покупателя от вполне реальных денежных потерь.

Если у вас уже есть заметный поток заказов из Казахстана, Узбекистана или Беларуси, и вы всерьёз рассматриваете подключение локального платёжного метода — имеет смысл в первую очередь посчитать реальный объём упущенных заказов именно из-за оплаты, а не из-за доставки или ассортимента, и уже с этой цифрой на руках решать, стоит ли начинать разговор с банком или агрегатором.

При этом стоит понимать, с чего вообще стоит начинать этот путь по-настоящему, а не с самого экзотичного канала. Прежде чем разбираться с Kaspi, Payme, Click или ЕРИП, убедитесь, что у вас в принципе надёжно и без сбоев работает базовый российский платёжный контур на ЮKassa и Тинькофф, о котором я упоминал выше. Локальные шлюзы СНГ закрывают дополнительный, часто меньший по объёму сегмент спроса, а не заменяют основной платёжный поток. Начинать оптимизацию стоит с той части воронки, которая приносит основную выручку, и только потом расширяться на соседние рынки — иначе есть риск потратить месяцы на подключение экзотичного канала ради нескольких процентов оборота, пока в основном платёжном потоке остаются куда более дорогие в деньгах проблемы.

Если вам близка сама идея — не собирать зоопарк отдельных плагинов под каждую задачу, а держать логику магазина в одном месте, где платежи, доставка, каталог и документы говорят на одном языке данных, — то это ровно тот принцип, который лежит в основе всего нашего плагина, а не только платёжного модуля. Я подробно писал об этом в обзорной статье про то, как один плагин заменяет собой зоопарк из двадцати WooCommerce-расширений, и логика с локальными платежами СНГ — просто ещё одна иллюстрация того же самого правила: когда шлюз для Kaspi живёт в той же архитектуре, что и шлюз для ЮKassa, использует тот же журнал логов, тот же механизм маскировки секретных ключей и тот же паттерн проверки подписи, подключение нового рынка — это расширение существующей системы, а не установка ещё одного независимого чёрного ящика неизвестного происхождения рядом с остальными десятью плагинами, за которые тоже нужно платить и следить, не сломает ли одно обновление другое.

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