Интеграция платёжных шлюзов для бизнеса в Дубае и ОАЭ
Мы интегрируем платёжных провайдеров ОАЭ и международных в сайты, приложения и платформы: карты, Apple Pay и Google Pay, рассрочку, регулярные платежи, возвраты и сверку. Мерчант-аккаунты принадлежат вам, а мы разрабатываем то, что их связывает.
Провайдеры, с которыми мы работаем
Комиссии, требования и доступные функции меняются и зависят от вашего бизнеса, поэтому мы проверяем их под каждый проект, а не называем общие цифры.
| Провайдер | Когда его обычно выбирают | Что проверить на этапе оценки |
|---|---|---|
| Network International (N-Genius) | Нужен крупный эквайер ОАЭ и местные расчёты, часто через отношения с вашим банком | Сроки подключения, поддержку плагинов для вашей платформы, варианты регулярных платежей и токенизации |
| Telr | Нужен шлюз из Дубая с платёжной страницей на стороне провайдера и готовыми плагинами | Способы оплаты, включённые в вашем аккаунте, поведение возвратов и вебхуков |
| PayTabs | Вы продаёте в нескольких странах Ближнего Востока и Северной Африки | Поддерживаемые валюты и местные способы оплаты по странам |
| Checkout.com | У вас большие объёмы, несколько валют или сложная маршрутизация | Требования к мерчантам и трудоёмкость интеграции для вашей схемы |
| Stripe | Ваша компания проходит по требованиям и вам нужны сильные инструменты для разработчиков и биллинга | Принимает ли Stripe ваше юрлицо и вид деятельности, условия выплат |
| Tabby и Tamara | Покупатели берут дорогие товары и воспользовались бы рассрочкой | Одобрение мерчанта, допустимые категории и как проходят возвраты |
Apple Pay и Google Pay обычно подключаются через ваш карточный шлюз, а не как отдельные провайдеры. Для Apple Pay на сайте нужна верификация домена, и каждый шлюз реализует её по-своему.
Платёжная страница провайдера или встроенная форма: ваша зона PCI
От того, как собираются данные карты, зависит, какая часть стандарта безопасности данных индустрии платёжных карт (PCI DSS) ложится на вас.
| Способ | Как работает | Влияние на зону ответственности |
|---|---|---|
| Платёжная страница провайдера | Покупатель переходит на страницу провайдера для оплаты | Минимальная зона; данные карты не касаются вашего сайта |
| Поля или iframe на стороне провайдера | Поля карты отдаёт провайдер внутри вашего оформления заказа | Небольшая зона и более удобное оформление заказа; скрипты платёжной страницы всё равно требуют контроля |
| Прямой API с вашей формой карты | Ваш сайт собирает данные карты и отправляет их провайдеру | Гораздо большая зона и нагрузка при аудите; мы избегаем этого без веской причины |
По умолчанию мы используем страницы или поля на стороне провайдера и никогда не храним номера карт. Какой опросник самооценки применим к вашей схеме, подтверждает ваш эквайер.
Регулярные платежи, кошельки и рассрочка
- Регулярные платежи
- Карта токенизируется при первом платеже, обычно с 3-D Secure, а последующие списания проходят как транзакции по инициативе мерчанта. Мы настраиваем расписание повторных попыток, напоминания об истекающих картах и понятную запись согласия каждого покупателя. Для продуктов по подписке см. разработку SaaS.
- Apple Pay и Google Pay
- Подключаются через шлюз с верификацией домена; кнопки кошельков показываются только на поддерживаемых устройствах и проверяются на реальных телефонах.
- Tabby и Tamara
- Варианты оплаты при оформлении заказа и сообщения о рассрочке на карточках товаров, если провайдер это допускает. Статусы заказов и возвраты синхронизируются обратно, чтобы частичные возвраты обрабатывались правильно.
Вебхуки, возвраты и сверка
Возврат покупателя на ваш сайт после оплаты — не доказательство оплаты. Покупатели закрывают вкладки, связь обрывается. Источником истины мы считаем вебхук провайдера или серверную проверку статуса. Каждый вебхук проверяется по подписи, обрабатывается один раз, даже если пришёл дважды, и записывается в лог, а плановая задача запрашивает у провайдера статус всех платежей, которые ещё в ожидании.
Полные и частичные возвраты запускаются из вашей админки или системы заказов и привязываются к исходному заказу. Сверка сопоставляет отчёт провайдера о расчётах с вашими заказами, чтобы финансовый отдел видел валовые продажи, комиссии, возвраты, чарджбэки и чистую сумму, поступившую на ваш счёт в AED. Если параллельно работает оплата при получении, перечисления курьеров проходят через тот же отчёт. Передача этих данных в бухгалтерию или ERP — часть нашей работы по интеграции API.
Подключение мерчанта: что делаете вы и что делаем мы
Мерчант-аккаунт принадлежит вашей компании, поэтому заявку подаёте и договор с провайдером подписываете вы. Провайдеры проверяют торговую лицензию, структуру собственности, банковский счёт и вид деятельности. Большинство также проверяют сайт перед одобрением. Мы готовим сайт к этой проверке и берём на себя техническую часть, как только у вас появятся тестовые и боевые ключи.
- Понятные страницы о возвратах, обмене, доставке, конфиденциальности и условиях, опубликованные на сайте.
- Название компании, контакты и цены в AED, видимые покупателям.
- Описания товаров, соответствующие виду деятельности в вашей лицензии.
- Тестовые и боевые API-ключи передаются по защищённому каналу, никогда по email или в чате.
Что входит, что не входит и от чего зависит стоимость
Требования и проверка провайдера
Способы оплаты, валюты, платформа, потребность в регулярных платежах и правила возвратов — сверяем с актуальной документацией каждого провайдера.
Интеграция в песочнице
Оформление заказа, вебхуки, возвраты и проверки статуса разрабатываются и тестируются в тестовой среде провайдера.
Тестирование пограничных случаев
Отказы, сбои 3-D Secure, повторные вебхуки, таймауты, частичные возвраты и брошенные платежи.
Переход в боевой режим и мониторинг
Небольшие реальные транзакции для проверки расчётов, затем оповещения о сбоях вебхуков и необычной доле отказов.
- Не входит: открытие мерчант-аккаунтов, переговоры о комиссиях, споры по чарджбэкам с провайдером и сертификация вашей организации по PCI.
- Что влияет на стоимость: количество провайдеров и способов оплаты, платформа (Shopify, WooCommerce или собственная), регулярные платежи, разделение платежей для маркетплейсов, глубина сверки и синхронизации с ERP.
Мы даём фиксированную цену после созвона по объёму работ. Если платежи будут частью нового магазина, начните со страницы разработки интернет-магазинов.
Частые вопросы
У какого шлюза самые низкие комиссии?
Это зависит от вашего оборота, структуры карт, вида деятельности и того, что каждый провайдер предложит вам после проверки. Мы сравниваем полученные вами предложения по функциям и трудоёмкости интеграции, но не ведём переговоры о комиссиях и не получаем вознаграждение от провайдеров.
Можно ли принимать платежи через Stripe в ОАЭ?
Stripe принимает многие компании из ОАЭ, но это зависит от вашего юрлица и вида деятельности. Уточните у Stripe, прежде чем строить всё вокруг него; если он не подходит, мы интегрируем шлюз ОАЭ.
Нужны ли нам одновременно карточный шлюз и Tabby или Tamara?
Обычно да. Сервисы рассрочки работают рядом с карточным шлюзом, а не вместо него, и одобряют мерчантов и категории товаров отдельно.
Можете ли вы интегрировать платежи в мобильное приложение?
Да, через мобильный SDK провайдера или его платёжную страницу, с той же логикой вебхуков и сверки на сервере. Также действуют правила Apple и Google для цифровых товаров. См. разработку мобильных приложений.
Что делать с платежами, которые прошли, а заказа нет?
Их ловят вебхуки и плановая проверка статуса. Если провайдер подтверждает оплату, заказ создаётся или обновляется автоматически и помечается для проверки.
Будем ли мы соответствовать PCI?
Страницы или поля на стороне провайдера сохраняют вашу зону ответственности небольшой, но соответствие — обязанность вашей организации. Мы строим интеграцию так, чтобы сократить эту зону, и документируем схему для вашего опросника.
Расскажите о вашей платформе, провайдерах, в которых вас одобрили или которых вы рассматриваете, и о том, нужны ли регулярные платежи или рассрочка. Мы ответим с планом интеграции и коммерческим предложением. Получить предложение.

