Создание системы продаж «внутри системы» — удаленное подключение магазинов и выплата средств

Большинство решений PAYSTO ^[1] отсутствуют на рынке. Это не значит, что мы делаем «никому не нужное» — просто это нужно «не каждому», а в некоторых случаях создается универсальное решение для конкретной задачи. Сегодня я расскажу как раз о таком решении…

Чтобы все было понятно, начну с самого начала…
Где-то 2 года назад к нам обратился владелец одного проекта с такой задачей:
Запускается система, которая будет предоставлять своим пользователям услуги для взаимодействия с другими пользователями. Функционал системы будет платным и необходим прием рекуррентных платежей (автоматическая оплата через определенный период). Дополнительной услугой для пользователей системы станет возможность продавать собственные цифровые товары (например статьи) другим пользователям в Интернет. При этом всё должно работать внутри единой системы — без переходов на другие сайты, т.е. «не выходя из системы». Здесь хорошая ассоциация — appStore в iPhone, когда пользователи могут делать приложения и продавать их другим пользователям — все процессы заказа, оплаты и выдачи товаров осуществляются в одном месте. Не забываем, что в этом случае нам еще потребуется выплата средств пользователям при продаже их товаров.
Найти готовое решение для этого невозможно, а для создания собственной инфраструктуры уйдет не только много времени, но и ресурсов. К тому же по расчетам, планируемый доход не сможет покрывать поддержку такой инфраструктуры. Остается искать решения в аутсорсинге услуг по обработке платежей, причем для оптимизации финансовых потоков все задачи желательно решить в одном месте:

1. Прием платежей для основной системы, включая рекуррентные платежи;
2. Прием платежей для магазина (продажа товаров пользователей);
3. Выплата средств пользователям (продавцам) самыми различными способами — на банковский счет, карту или в платежные системы.

Первую задачу решили с использованием upBalance ^[2].
Для остальных двух планировалось использовать onlineMerchant ^[3]и paymentGate ^[4], но возникла другая проблема — юридическое оформление отношений основной системы с пользователями-продавцами, т.к. соединить все в одном законно не получалось ввиду того, что основная система к тому времени уже получила венчурное финансирование и использование «серых» схем было недопустимо. На осознание данного «тупика» ушло больше года. В начале сентября я встретился с владельцем системы и мы стали искать другое решение…
Предложенная клиентом идея выглядела как «персонализация процессов подключения магазина», т.е. оформление всех процессов в стиле клиентской системы: создание пользователя, подключение магазина и выплата средств. Конечно, можно было бы сделать и так, но по сути для нас это стало было создание клона PAYSTO, что не входило в наши планы развития, т.к. потребовало бы значительного времени на разработку. Для упрощения, я предложил использовать решение аналогичное «Войдите с помощью..Facebook, Google, Twitter и т.п.», а в качестве логина/пароля использовались бы данные учетной записи пользователя в клиентской системе. Подобный подход реализуется достаточно быстро. На этом остановились и решили выяснить технические возможности каждого на своей стороне.

Собрав совещание с нашими разработчиками было предложено иное решение — мы реализуем специальное API для требуемых процессов:

1. Создание нового пользователя в системе PAYSTO;
2. Добавление и управление реквизитами пользователя PAYSTO;
3. Создание и подключение магазина в onlineMerchant;
4. Создание и контроль заявок на вывод средств из PAYSTO;

С точки зрения безопасности, изменений не будет — регистрация пользователя и вывод средств осуществляются также по коду подтверждения, отправляемому на e-mail владельца, но вводятся они уже в клиентской системе.

Фактически, данный функционал позволяет организовать продажи в любой внешней системе. На стороне клиента можно использовать CMS для управления магазином, с небольшой доработкой и адаптацией дизайна. Учитывая, что у нас есть готовые модули для всех распространенных CMS ^[5], много времени реализация такой задачи не займет.

Описание нового API можно посмотреть здесь ^[6].

Теперь про условия сотрудничества …
Наш интерес в «этом» абсолютно стандартный — мы не берем никакой дополнительной платы за новый функционал. Все услуги предоставляются согласно выбранного тарифа на прием платежей ^[7], в среднем 5% от суммы платежа.
Монетизировать данные услуги на стороне клиента можно через оплату внутри клиентской системы, например как дополнительную услугу. Однако такой вариант может быть не удобен по ряду причин, поэтому клиент участвующий в реализации данного решения поставил условие, что при продаже товаров через такой магазин, пользователю должна зачисляться сумма с комиссией = 30%. Такая ставка обусловлена тем, что клиент обеспечивает рекламу товаров пользователя. Для «прозрачности» отношений, разница 25% зачисляется на партнерский счет клиента внутри PAYSTO и выводится на его расчетный счет по договору о сотрудничестве.

Автор: paysto

Источник ^[8]