Оплата банковской картой непосредственно на сайте. Как?

Question

[Артур Заяц]

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

Предполагаю, что у тех самых платежных систем наверное есть соответствующие API? Это так? Или все делается подругому? Если есть реальный опыт — расскажите, пожалуйста.

Comments

[Артур Заяц]

Это наверное будет первым шагом к: «купить в один клик». Кстати, а в рунете есть и-магазины с такой функцией? Кто-нибудь сталкивался?

Answer 1

[Kane]

Делается это просто: вы создаёте на своём сайте форму оплаты, а атрибут action у этой формы ведет на сайт платёжного шлюза. Пользователь заполняет форму на вашем сайте и жмёт «Отправить». Данные отправляются в платёжный шлюз, который после обработки делает редирект пользователя обратно на ваш сайт. Знаю два американских платёжных шлюза, работающих по этой схеме: authorize.net и www.braintreepayments.com. Второй, по-моему, приятнее

Comments

[isden]

> Знаю два американских платёжных шлюза, работающих по этой схеме: authorize.net и www.braintreepayments.com. Второй, по-моему, приятнее

На самом деле, все немного не так.
— Authorize.net — у них есть 2 способа интеграции — с вводом данных карточки на их сайте (SIM) и с вводом данных на вашем сайте и отправкой POST-формы им, получением и распарсиванием ответа от них (AIM).
— Braintree — тут все несколько сложнее. Они используют интеграцию через iframe. Т.е. на вашем сайте отображается iframe с их платежной формой.

По сабжу — это возможно сделать несколькими способами. Например:
1. Отправка POST/GET запросов на платежку с получением и обработкой ответа. Через тот же libCurl/etc. Небезопасен в плане того, что вам на сайт могут подсадить трояна для перехвата этих данных. Не PCI-DSS совместим, и Виза, например, не разрешает такое.
2. Интеграция через сторонний доверенный сервис либо через саму платежку внутри фрейма. См. тот же Braintree либо аналоги.

[isden]

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

[Kane]

Ничего не знаю про iframe для braintree. Но интегрировал этот шлюз тем способом который описал — то есть через отправку формы на сторону брейнтрии. И, по-моему, у них тоже есть возможность сделать всё на своей стороне. Впрочем, нет смысла это обсуждать, когда можно просто пойти и почитать документацию :)

[isden]

> когда можно просто пойти и почитать документацию

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

[Kane]

Ну самый простой способ соблюдать PCI — это не обрабатывать персональные данные плательщика на своих серерах. В этом плане у обоих сервисов есть все средства для этого.

Answer 2

[Dolios]

Киберплат, если не ошибаюсь, позволяет сделать такое. Но вам будет необходимо пройти их аудит.
Т.е. оплата все равно будет идти через киберплат, но юзеру будет казаться, что он платит непосредственно на сайте.

Другой вопрос, нафига это надо? Из двух одинаковых магазинов, я выберу тот, который именно перенаправляет на внешний процессинг, а не юзает апи, собирая данные карты самостоятельно.

Answer 3

[Skpd]

Is there free credit card api or payment gateway?
Direct Payment API Introduction

Answer 4

[barker]

У того же ассиста есть вариант заполнения всех данных на сайте и передача уже полностью заполненной формы. На той стороне настраивается авторедирект назад в случае успеха/неуспеха. Но чтобы совсем без перехода туда-сюда я таких не припоминаю даже.

Comments

[MaxUp]

а это просто законодательно нельзя. Т.к. если все на своей стороне делать, нужно уже иметь лиц. на фин. операции.

Answer 5

[ProstoDesign]

Если будете реализовывать все именно на сайте, без перехода на платежный шлюз — количество отказов от оплаты Вас не обрадует, поверьте. Люди и процессинговым центрам-то не всегда доверяют…

Answer 6

[Максим Козлов]

Поэтому лучше выбрать процессинговый центр, который переадресует покупателя на сайт банка для ввода данных карт. Таким образом количество отказов будет минимально. Пример MaxKassa