По какой схеме работают агрегаторы платежных систем и как реализовать такую схему для личного пользования?

Question

[# a r t u r #]

Здравствуйте!

Есть несколько сайтов, все они подключены к разным платежным системам и нескольким агрегаторам.

Сегодня задумался, а что если подключить свои сайты к своему простому агрегатору, тема интересна ради практики.

Представляю это так:

1. Есть сайт, на нем человек выбирает товар и способ оплаты, формируется что-то вроде счета, секретная строка. Человек нажимает на кнопку "Оплатить".
   
2. Далее человека перебрасывает на сайт агрегатора где в зависимости от его выбора сформирована готовая форма для оплаты. На этом этапе я так понимаю нужно сверять домен откуда поступил переход с белым списком и проверять данные, сравнивая их с секретной строкой (значение соли вероятно должно храниться на сайте магазина и на сайте агрегатора)
   
3. Человек оплачивает нужную сумму через форму и его по идее должно вернуть на сайт магазина, при этом
   должен быть передан статус success или error, в зависимости от результата оплаты... ну и ID счета, который оплачивался... вероятно результат тоже лучше зашифровать и включить в него фактическую сумму оплаты чтобы можно было и на сайте магазина сверить эти данные?
   

P.S.: Относительно расширяемости (подключения левых магазинов) - такой задачи нет, хотелось бы реализовать подобное для личного пользования, но с другой стороны было бы удобно подключать каждый новый проект к этой схемке, исключая тем самым рутинной возни с кучей платежек и сторонних агрегаторов при открытии нового сайта. Так что единственное, что приходит на ум - хранить на стороне агрегатора доверенный список доменов и уникальную соль для каждого магазина... что еще?

Правильно ли мыслю? Кто что может подсказать/добавить, особенно касательно защиты и самой логики? Какой метод лучше использовать для обмена данными?

Вероятно многие пробовали такое реализовать и у кого-то прекрасно работает, поделитесь практикой, что я упускаю в логике? Что почитать?

Очень жду комментариев, спасибо за проявленный интерес!

Answer 1

[Антон Шаманов]

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

По поводу реализации: возьмите описание к любому популярному агрегатору - оно содержит ответы на большинство возникших вопросов - просто сделайте по аналогии.

Comments

[# a r t u r #]

Плюсы и минусы ясны, подскажите, как обеспечить безопасность? Ну с фильтрацией и валидацией данных это понятно, проверка данных на стороне агрегатора и на стороне магазина - тоже ясно, https, как определить домен с которого перешел человек, вероятно со 100% гарантией никак т.к. на HTTP referer полагаться нельзя...

[Антон Шаманов]

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

Answer 2

[Александр Кубинцев]

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

Технически я делал такую штуку на основе не взлетевшего проекта платежного агрегатора.

По поводу технической реализации нужно api которое будет:
1) создавать ордер с параметрами siteId, amount, email, externalOrderId, successUrl, declineUrl, callbackUrl и возвращая в ответ orderId
2) принимать команду на платеж по orderId
3) отстукивать siteId при получении колбеков от платежных систем по указанному callbackUrl с параметрами orderId, externalOrderId, amount и sign

Можно реализовать и функционал для возвратов, добавив дополнительный параметр в api методе для колбека.

Первые 2 пункта позволяют избавиться от задвоений при "плохом интернете", но нужно вешать лок через табличку типа [key, timestamp] при обработке 2-го пункта.

Comments

[# a r t u r #]

Согласен, вопросы со стороны платежек наверняка будут возникать, пока над этим не думал (

Спасибо информацию!

Answer 3

[Andry]

Вижу ваш вопрос как две задачи:
- избавиться от чужих агрегаторов и научиться самому работать с разными платежными системами напрямую
- научить мою одну точку оплаты работать с несколькими моими же точками продаж.

Если всё верно, то первый вопрос реализуется очень просто. Достаточно изучить пяток апи разных платежек. Могу поделиться своим вариантом (серверной частью) (сейчас его и перекраиваю из опыта использования https://toster.ru/q/327212).

О второй части предлагаю подумать ещё раз. А надо ли оно? Если у вас будет универсальный код/модуль/плагин для оплаты, то что вам мешает раскидать его на разные сайты? Большинство платежный систем поддерживает "один договор/учетка и много магазинов".
Вводя дополнительные "пробрасывания/шифрования/и т.д." вы добавляете лишние звенья, увеличиваете шанс уязвимости, уменьшаете надежность системы в целом.