О, давайте я вам расскажу, как я интегрировал один сервис с "современной международной IT-компанией Prodamus".
TL;DR 1. API писал студент, а документацию к API - школьник. 2. Документация не обновляется и отвратительно структурирована. 3. Техподдержка плавает в вопросах, касающихся интеграции, при этом разные сотрудники ТП противоречат друг другу, предоставляя диаметрально противоположные по смыслу ответы.
Начнём с того, что для интеграции по API у них в документации есть сразу несколько разных разделов, информация по которым хаотично размазана тонким слоем. - хотите создать платёжную ссылку? Ищите инфу в одном разделе. - хотите настроить вебхуки, чтобы обработать оплату по вышеупомянутой ссылке? Идите в совершенно другой раздел. - хотите посмотреть формат данных в вебхуке? Идите в третий раздел. - хотите посмотреть параметры, которые можно передать в запросе на генерацию платёжной ссылки? Думаете, что эту инфу нужно искать там же, где и инфу по созданию платёжной ссылки (см. п. 1)? Как бы не так. Идите в четвёртый раздел. - ах, вас интересуют рекуррентные платежи? Тогда вам в пятый раздел, где вы увидите ссылки на шестой раздел.
Далее, механизм тестирования интеграции - это просто ужас. Я никогда в жизни не видел настолько ущербно спроектированной и реализованной системы. 1. Данные в вебхуке могут приходить как в JSON, так и URLencoded. Это написано в официальной документации. Но после того, как вы напишете код под JSON, вас ждёт сюрприз, потому что тестовые платежи отправляются только в URLencoded. Поддержка на вопрос "Какого ...?" отвечают "Ну вот так, у нас пока что только так сделано". 2. Вы не сможете легко протестировать рекуррентные платежи, потому что минимальный срок между платежами - 1 день. Да, именно так: если у вас возникла ошибка при списании, то вам нужно ждать 1 день перед тем, как Продамус сможет произвести повторное списание. Думаете, это полный идиотизм? Нет, это "современная международная IT-компания". 3. В документации указано 3 значения поля `action_code`: auto_payment, deactivation, finish. Как вы думаете, что произошло при первом же тестировании механизма подписки? Да, я получил событие с типом `reactivation`, о котором в документации не говорилось. После дальнейшего изучения обнаружилось, что этот параметр мельком упоминается в одном из примеров в совершенно другом разделе. В основной таблице с описанием параметров этого типа нет.
И это ещё далеко не все сюрпризы, с которыми я столкнулся при интеграции.
Вывод простой: доверять работу с деньгами системе, которая настолько похабно написана, точно не стоит. Берите любой банк, Юмани, Робокассу, ещё что-нибудь - вариантов много. А Продамус - это сырой и отвратительно спроектированный продукт.
О, давайте я вам расскажу, как я интегрировал один сервис с "современной международной IT-компанией Prodamus".
TL;DR
1. API писал студент, а документацию к API - школьник.
2. Документация не обновляется и отвратительно структурирована.
3. Техподдержка плавает в вопросах, касающихся интеграции, при этом разные сотрудники ТП противоречат друг другу, предоставляя диаметрально противоположные по смыслу ответы.
Начнём с того, что для интеграции по API у них в документации есть сразу несколько разных разделов, информация по которым хаотично размазана тонким слоем.
- хотите создать платёжную ссылку? Ищите инфу в одном разделе.
- хотите настроить вебхуки, чтобы обработать оплату по вышеупомянутой ссылке? Идите в совершенно другой раздел.
- хотите посмотреть формат данных в вебхуке? Идите в третий раздел.
- хотите посмотреть параметры, которые можно передать в запросе на генерацию платёжной ссылки? Думаете, что эту инфу нужно искать там же, где и инфу по созданию платёжной ссылки (см. п. 1)? Как бы не так. Идите в четвёртый раздел.
- ах, вас интересуют рекуррентные платежи? Тогда вам в пятый раздел, где вы увидите ссылки на шестой раздел.
Далее, механизм тестирования интеграции - это просто ужас. Я никогда в жизни не видел настолько ущербно спроектированной и реализованной системы.
1. Данные в вебхуке могут приходить как в JSON, так и URLencoded. Это написано в официальной документации. Но после того, как вы напишете код под JSON, вас ждёт сюрприз, потому что тестовые платежи отправляются только в URLencoded. Поддержка на вопрос "Какого ...?" отвечают "Ну вот так, у нас пока что только так сделано".
2. Вы не сможете легко протестировать рекуррентные платежи, потому что минимальный срок между платежами - 1 день. Да, именно так: если у вас возникла ошибка при списании, то вам нужно ждать 1 день перед тем, как Продамус сможет произвести повторное списание. Думаете, это полный идиотизм? Нет, это "современная международная IT-компания".
3. В документации указано 3 значения поля `action_code`: auto_payment, deactivation, finish. Как вы думаете, что произошло при первом же тестировании механизма подписки? Да, я получил событие с типом `reactivation`, о котором в документации не говорилось. После дальнейшего изучения обнаружилось, что этот параметр мельком упоминается в одном из примеров в совершенно другом разделе. В основной таблице с описанием параметров этого типа нет.
И это ещё далеко не все сюрпризы, с которыми я столкнулся при интеграции.
Вывод простой: доверять работу с деньгами системе, которая настолько похабно написана, точно не стоит. Берите любой банк, Юмани, Робокассу, ещё что-нибудь - вариантов много. А Продамус - это сырой и отвратительно спроектированный продукт.