Принятие платежных лучших практик

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

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

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

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

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), поскольку я знаю, что на защиту этого программного обеспечения тратится много денег. Если вы являетесь сайтом, который я использую впервые, я буду отстранен".