Форумы / National / Russian / Идеи / Платежные системы

К вопросу расширения пользовательской базы и благодарностей разработчикам…

(Смотря на популярность «биржи») Подумалось, что достаточно востребованной темой для движка стали бы плагины интеграци систем приема платежей.

Потребность у пользователей однозначно есть. Наверняка многие из вас (разработчиков) уже писали какие-то «велосипеды». В общем-то по трудозатратам написание абстрактного платежного плагина скорее всего займет времени меньше среднего, т.к. API платежных систем стандартизирован, и как правило в доступе есть необходимые библиотеки для PHP, и необходимые примеры.

Полагаю, что некоторые разработчики не стремятся делиться такими наработками, в силу различных причин. Кто-то, считает, что выкладывать такое в общий доступ «забесплатно» не допустимо, кто-то на этом зарабатывает и считает, что выложив это в доступ потеряет поток клиентов, кто-то не представляет как можно отделить платежи от «торговой плащадки». (Собственно ниже я попытаюсь развеять эти страхи.)

Во-первых, разработчиков можно даже простимулировать (если фонд Котонти это позволяет). 
Подобные плагины потом можно выложить за небольшую оплату - тем, кто собирается зарабатывать на своем сайте это погоды не сделает, зато окупит разработку оных. 

Техническая сторона вопроса. Понятно, что многие наработки привязаны к конкретному функционалу (биржа, магазины и т.п.). Но можно создать некий универсальный прототип, который (как пример) позволял бы принимать переводы на свой счет в системе (т.е. у каждого пользователя в системе есть свой накопительный счет, который можно пополнить сделав перевод через одну из систем приема платежей).

В таком случае мы:

• избавляемся от привязки к конкретному функционалу (бирже/магазины/пр.)
• при желании любой разработчик элементарно реализует доп. функционал, который будет списыввать средства со счета в обмен на товары/услуги/бонусы
• разработка плагина становиться достаточно простой
• плагин будет легким в использовании, и простым для интеграции с дополнительным функционалом (это к вопросу о тех разработчиках, которые боятся потерять платящих за «модуль-оплат» клиентов. Они никуда не денуться, т.к. интеграция с конечным функционалом все равно будет необходима). 

В идеале (как я это вижу) это, если бы кто-то из гуру Котонти-разработки, сделал бы шаблон-пример, реализовав основные принципы на примере любой из платежных систем. Именно как пример, и важно, что бы это был хороший с точки зрения кода и продуманый с точки зрения функционала и дальнейшего использования модуль (например продумать где и какие хуки понядобятся, и т.п.).
Т.к. чисто технически реализовать это смог бы и я, но понимаю (смотря на код и решения Trastmaster'a, Gert'a и прочих), что мне нехватает навыков системного мышления, что бы это сделать «красиво» и эффективно вписать в «экосистему» котонти. (Вот идеи генерить это другое дело :))) ) Хотя можно начать и с малого…

А если будет такой шаблон-пример, то реализовать дополнительный платежный механизм «по подобию» сможет уже и «средней руки разработчик».

Наработок в виде кода нет, но есть некоторый опыт изучения внутренней структуры и АПИ, который я попробую обобщить.

(Целевой сайт - сайт на котором изначально пользователь намеревается осуществить оплату услуг/товаро/прочего).

Глобально, платежные операции (ПО) с помощью сторонних платежных систем (ПС) можно разделить на 2 вида:

• Внешние ПО (полного цикла). Пользователь переходит на сайт ПС, производит вход в систему (при необходимости), выбирает (по возможности) средство оплаты, осуществляет оплату, переходит обратно на целевой сайт. (наиболее частый и простой в реализации вариант)
• Внутренние ПО (не переходя с целевого сайта). Все необходимые данные пользователя собирает целевой сайт (в том числе если надо реквизиты карты или счета в ПС), потом он (целевой сайт) передает эти данные на обработку в ПС и получив ответ от ПС информирует пользователя об успешности или неуспешности операции.

Использовать предполагается первый вариант.

Далее ПС можно разделить по типам интеграции с целевым сайтом:

• интеграция платежного модуля на целевой сайт (некий код, который отображает форму оплаты и все необходимые формы для совершения платежа), без редиректа на сайт ПС. (менее распространенный вариант).
• перенаправление пользователя на сайт ПС для совершения платежа (наиболее простой и безопасный).

Здесь нас будет интересовать второй тип.

Далее рассмотрим технические моменты. Все ПС имеют некоторый API, который доступен для зарегистрированного в ПС разработчика. После регистрации в ПС как «магазин» (получатель платежей) мы получаем (как правило) некий идентификационный номер в системе (ID) и кодовую фразу (secret), на основании которых можно будет получить доступ к АПИ. В настройках ПС магазин указывает метод и счет для вывода денег, или периодически выводит их в ручную.

Если рассмотривать глобально ПС, то надо отметить следующие нюансы: 

• ПС может иметь, а может и не иметь «тестовый режима» для разработчика (если тестового режима нет, то отлаживать код придется за собственный счет совершая какие-то микроплатежи)
• Некоторый ПС дают доступ к АПИ только после получения «магазином» определенного статуса. Это может быть проверка документов получателя платежа или проверка целевого сайта на соответствие правилам ПС, и т.п.
• Аналогично может быть ограничен доступ к «тестовому режиму» пока «магазин» не прошел верификацию.

Алгоритм реализации у всех ПС примерно одинаковый (там где вариаци дал пояснения):

• на целевом сайте формируется счет на опату (это может быть список товаров/услуг или просто форма пополнения «своего» счета на N-ю сумму)
• при согласии с условиями покупатель нажимает кнопку оплатить 
• данные платежа (сумма, валюта, номер заказа или операции, данные пользователя ) отправляются на сайт ПС (как правило) Post запросом.
  - Номер заказа или операции подразумевает некоторый идентификатор платежа, который должен сформировать целевой сайт для последующей однозначной идентификации платежа, т.е. необходимо вести внутренний реестр платежных операций.
• Т.о. пользователь переадресуется на сайт ПС, где авторизуется (как например в paypal или ЯД) или просто вводит дополнительные данные для совершения платежа (например данные карты).
• после удачной или неудачной попытки оплатить счет ПС переадресовывает пользователя обратно на целевой сайт. Тут бывает 2 варианта:
   - переадресация на простую страницу. ПС в таком случае не передает никаких данных, а просто переадресовывает обратно на магазин, по указанному в настройках ПС адресу или на главную страницу. Это менее удобный вариант, т.к. целевой сайт должен после этого сделать запрос к API и получить ответ об успешности платежа, перед дальнейшей обработкой заказа пользователя. По этой схеме часто работуют платежные агрегаторы, где время прохождения платежа сожет исчесляться минутами часами.
  - переадерсация на страницу обработчик. ПС в таком случае передает данные о проведенной или нет операции. В таком случае мы можем сразу зачислать на счет сумму или провести операции с заказом. По такой схеме работают большинство ПС с эл.деньгами (вебмани, яндекс, если не ошибаюсь). Адрес конечной страницы настраивается на стороне ПС, реже передается в запросе к ПС и может быть динамическим.
• на основании полученных о платеже данных целевой сайт производит операции с заказом (например заявка на отгрузку со склада) или /счетом пользователя в системе.(начисление внутренней валюты).

Сама схема обработки платежей внутри Котонти, для простоты расширения, мне видится 3-уровневой:  торговая площадка (ТП) [магазин формирует счет на плату, вызывает функции платежного плагина] → платежный плагин (ПП). [контролирует реестр подключенных ПС, их свойств допустимость использования в зависимости от различных условий] → плагин конкретной ПС (ППС) [содержит настройки интеграции, параметры ПС и т.п.]

Общая схема работы внутри Котонти: 

• модуль ТП (биржа/магазин/пополнение внутреннего счета) формирует страницу оплаты/счет, вызывая функцию ПП на формирование «блока оплаты», передавая данные о заказе (сумму/валюту/…). В простом варианте функция возвращает html код и формирует метку вызвавшей ТП, который внедряется на страницу счета. Это может быть просто кнопка «оплатить» или форма выбора ПС с кнопкой.
•  по нажатию «оплатить» пользователь отправляется на сайт ПС (ка описано выше)
• возвращения с ПС происходит на специальную страницу ПП, который вызвав функцию ППС получает результат операции. Далее вызывается общий для всех ТП хук (pay.success или pay.failed), где на основании метки ТП происходят операции по оформлению заказа и вывод пользователю информации о упешной/неуспешной операции. Метка нужна для того, чтобы на одной системе могли работать несколько ТП одновременно, например биржа и магазин или магазин и пополнение внутреннего счета. 

Т.е. надо спроектировать и реализовать связку ПП←→ППС (это может быть единый плагин расширяемый доп.файлами pay.webmoney.php/pay.yandex.php или отдельные плагины для ПС и ППС, тогда каждый ППС это отдельный плаг). Вариант с отдельными плагинами для ПС и плаежным «плагином-агрегатором» мне видится более гибким. К тому же тогда, такие данные как ID, secret, … можно будет вводить через админку в настройке каждого отдельного ППС (иначе прописывать в файл руками, что менее удобно и безопасно).

Основные моменты:

• один ППС (файл/или плагин) - одна подключаемая ПС
• ППС предоставляет данные о ПС (например некоторые ПС вводят ограничения на максимальные суммы платежа, некоторые работают только в определенной валюте, ссылки на сайт ПС и логотип-иконку ПС, включен ли тестовый режим и т.п. ) и интеграции платежному плагину (ПП) 
• ППС не имеет физического функционала, он только предоставляет сквозной интерфейс для взаимодействия ПП с конечной ПС.
• необходим реестр-массив данных о подключенных ППС
• ПП реализует набор функций для взаимодействия с конечным модулем Торговой Площадки (его здесь почти не рассматриваем).
   - например отрисовка формы/кнопки для оплаты заданного платежа
• в ПП в демонастрационных целях можно включить простую страницу для демонстрации платежа (т.е. простой вариант формы/счета торговой плащадки) - аналог простой ТП.

ps/ Теперь немного о юридических и прочих аспектах (к реализации расшрения они не имеют абсолютно никакого отношения, но будут полезны тем, кто соберется их исполтьзовать или проводить дальнейшую разработку).

Каждая ПС, в которой регистрируется разработчик (магазин), имеет свои правила работы. Иможет требовать:

• те или иные документы идентификации контрагента (магазина)
• соблюдения правил по офрмлению целевого сайта (сайта магазина)
• иметь конкретную форму юр.лица (например ИП или ООО)

А также может налагать дополнительные ограничения на вывод средств:

• например % от суммы операции
• выплаты фиксированных сумм (можете получить только тогда когда накопиться N-я сумма на вашем счету)
• фиксированные по времени выплаты (например раз в неделю или месяц)

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

Macik, имеется опыт разработки как модуля интернет магазина так и его работа с ПС, а так же давно в планах публикация этих наработок в сообществе cotonti, но останавливает все время - то что коды заточены под конкретные проекты + отсутвует план, или если так можно выразиться Т3 на модуль электронной комерции опираясь на который можно было бы превратить все свои наработки к эдиному универсальному решению, а так не зная всех возможных вариантов использования даного функционала публикация станет бесполезными костылями подогнать которые под свой магазин сможет только опытный котовод знающий php. Но ваши обширные посты в данном топике, при условии расширения и продолжения их написания, а так же грамотного обсуждения с другими членами команды для уточнения конечного Т3 выбросит этот пункт из списка стоп-факторов публикации своих кодов + время на работу для общественности появляется редко и порционно, а не так как хотелось бы - пусть даже по немногу но регулярно. Потому ваш труд поддерживаю и постараюсь поучаствовать в решени задач даного сегмента функций для cotonti

#36056 Dayver:

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

В Робокассе все проще немного. У нее только один запрос происходит уже ПОСЛЕ произведения оплаты, то есть ответ для сайта, чтобы совершить нужные действия на стороне сайта (запрос result в терминологии Робокассы). А дальше перенаправление для покупатеря на страницу магазина с результатом успешной операции (запрос success), либо при неудачной операции (запрос fail).

Видимо это связано с тем, что Робокасса как и другие агрегаторы ПС (например Интеркасса) уже в себе содержат все необходимые дополнительные проверки отдельных ПС, чтобы не усложнять их интеграцию с магазинами.

Могу поделиться кодами подключения некоторых ПС (QIWI, Webmoney, Robokassa, Interkassa, Yandex). Постараюсь как-нибудь выложить на Github. Гораздо интереснее было бы освоить такие ПС как например PayPal, Assist.