Подключение Payme со стороны выглядит как одна задача, а на деле это три параллельные цепочки: договор с платёжной системой, работа на сайте и проверка сценариев, в которых что-то идёт не так. Разберём по порядку — вы поймёте, за что платите и где обычно теряется время.
Что должно быть у вас до старта
Юрлицо или ИП. Платёжная система заключает договор только с ними, физлицу приём платежей на сайт не подключат.
Сайт, где есть оформление заказа. Оплата — последний шаг: если корзины и заказа нет, подключать пока нечего. Это отдельная работа, см. разработку интернет-магазина.
Доступ к сайту и хостингу. Или контакт того, у кого он есть.
Дальше можно параллелить: пока идёт согласование с Payme, разработчик уже делает свою часть на тестовом контуре.
Что делает разработчик
1. Подключение merchant API
Payme работает по схеме, где платёжная система сама обращается к вашему сайту и спрашивает: такой заказ существует? сумма совпадает? можно проводить оплату?
То есть сайт должен уметь отвечать на эти вопросы — это и есть основная работа. Не «вставить кнопку», а научить сайт разговаривать с платёжной системой.
2. Обработка колбэков
Когда клиент оплатил, Payme сообщает об этом отдельным запросом. Именно по нему заказ меняет статус на «оплачен».
Здесь прячется самая частая ошибка: если полагаться на возврат клиента на сайт, часть оплат потеряется. Человек закрыл вкладку, у него отвалился интернет, он оплатил и ушёл — деньги списались, а заказ висит неоплаченным. Правильный источник истины — колбэк, а не поведение клиента.
3. Сценарии, в которых что-то пошло не так
То, из-за чего сроки «два дня», а не «два часа»:
- Двойная оплата. Клиент нажал дважды, оба платежа прошли
- Отмена. Оплата началась, но не завершилась — заказ не должен зависнуть навсегда
- Возврат. Частичный и полный, с корректным статусом заказа
- Расхождение суммы. Цена изменилась, пока клиент оформлял заказ
- Повтор колбэка. Платёжная система может прислать уведомление дважды — заказ не должен оплатиться два раза
Каждый из этих случаев обязан отрабатывать предсказуемо. Их не видно, пока не случится, и именно они превращают «оплата работает» в «оплата работает всегда».
4. Тестовый контур
До запуска всё проверяется на тестовых ключах: оплата, отмена, возврат. Вы смотрите сами, а не верите на слово.
5. Выгрузка заказа туда, где его увидят
Оплаченный заказ должен попасть менеджеру: в CRM, в Telegram, куда вам удобнее. Иначе получится магазин, где деньги приходят, а обработать заказ некому.
Где обычно теряется время
Согласование с платёжной системой. Документы юрлица, проверка сайта, договор. Это идёт не через разработчика, и повлиять на срок он не может — но может делать свою часть параллельно, чтобы к моменту одобрения всё было готово.
Отсутствие юрлица. Всплывает обычно уже после того, как сайт готов.
Сайт на закрытой платформе. Если сайт сделан на конструкторе, который не даёт доступа к коду, вариантов немного: либо готовый модуль платформы, либо переезд.
Сколько это стоит по времени
Техническая часть — два рабочих дня при готовом магазине. Со стороны платёжной системы сроки свои и зависят от документов.
Подключение второй системы — Click или Uzum — идёт быстрее: механика та же, отличаются детали протокола.
Что дальше
Страница услуги со сроками и стоимостью — подключение Payme. Если ещё выбираете между платёжными системами, есть разбор Click, а если магазина пока нет — разработка интернет-магазина.
Про порядок цен на разработку в целом — отдельный разбор.