Рекомендации по приему платежей

Вы захотите спроектировать свой код таким образом, чтобы сохранить ваши данные в допустимом состоянии.

Большая ответственность, с которой вы сталкиваетесь, заключается в том, что вы отправляете данные для аутентификации/захвата, а затем по какой-то причине что-то на вашей стороне дает сбой. Вы выставили счет своему клиенту, но по какой-то причине вы не знаете этого факта! В конце концов, какой-нибудь разгневанный клиент начнет кричать на вас по телефону. Это плохое время.

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

Вот что я бы сделал:

1. Создайте таблицу базы данных, которая отслеживает платежи (назовем ее «платеж»), и свяжите ее с вашей таблицей «заказов» (так что payment.order_id ссылается на order.id).
2. Когда придет время взаимодействовать с вашим шлюзом, настройте новую платежную запись, содержащую любые неконфиденциальные данные, которые вы собираетесь передать платежному шлюзу. Создайте столбец «Статус» в таблице платежей и установите для него значение «Ожидание».
3. Попытайтесь выполнить транзакцию аутентификации/захвата с вашим шлюзом. Получив ответ, обновите статус платежной записи на «одобрено», «отклонено» или «ошибка» и сохраните все соответствующие метаданные (причины отклонения, идентификатор транзакции и т. д.). Если время ожидания шлюза истекло, это, вероятно, просто своего рода «ошибка», хотя вы можете повторить попытку один или два раза.

Время от времени запускайте задание cron для поиска записей о платежах, которые «ожидают рассмотрения» и старше, скажем, 30 секунд. Если вы их обнаружите, паникуйте и сообщите об этом разработчику/оператору.

Конечно, есть и другие вещи, которые могут пойти не так, но это самое важное, что приходит на ум, и описанная мной стратегия — это стратегия, которую я использовал несколько раз для снижения риска.

Я не эксперт по обработке платежей и разработке приложений для электронной коммерции, но некоторые из моих (здравых) рекомендаций таковы:

1. Принудительно использовать HTTPS для отправки информации CC от пользователей (практически все шлюзы обработки платежей принудительно используют SSL при общении со своим шлюзом);
2. Не хранить информацию о кредитной карте в базе данных после обработки;*
3. Соблюдайте общие правила безопасности (например, не сохраняйте текстовые пароли или пароли электронной почты);

*Примечание:

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

Я мало знаю о проблемах масштабируемости при обработке платежей, так как у меня нет опыта в этой области. Все мои приложения обрабатывают только 5-25 заказов в день.

Используйте SagePay (ранее Protx), он поддерживает PayPal и позволяет принимать платежи по картам. Он также интегрируется в Sage Suite (мечта бухгалтеров) и может автоматизировать ввод данных, отнимающий много времени.

www.sagepay.com

Как говорят другие - Иногда для небольших сайтов не стоит рисковать хранить карты самостоятельно. Я предпочитаю платить на веб-сайтах, где меня перенаправляют на известный платежный сервис (например, paypal, sagepay или google checkout), так как я знаю, что много денег тратится на обеспечение безопасности этого программного обеспечения. Если вы веб-сайт, который я использую в первый раз, ну, я буду отложен.