Forums / National / Russian / Идеи / Платежные системы

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

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

Глобально, платежные операции (ПО) с помощью сторонних платежных систем (ПС) можно разделить на 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-я сумма на вашем счету)
• фиксированные по времени выплаты (например раз в неделю или месяц)