отправка данных на платежный шлюз и обратно - возможные проблемы

Question

Я собираюсь использовать один из платежных шлюзов, поэтому пользователи с моего сайта будут перенаправлены на страницу, размещенную на шлюзе, чтобы предоставить все данные CC. Шлюз вернет результаты на указанную мной страницу (назовем ее paymentProcessed.php). Но теперь я беспокоюсь о том, что:

1. кто-то может подделать это. Я имею в виду, что кто-то может быть перенаправлен на платежный шлюз, а затем вместо оплаты вернет результаты на страницу моего сайта paymentProcessed.php с подтверждением того, что все было оплачено. Это подтверждение будет отправлено самим пользователем через обычный POST, и мой сайт затем доставит продукты пользователю, хотя на самом деле оплата не была произведена. Какова обычная практика, чтобы избежать такой ситуации?

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

3. О каких еще возможных проблемах мне следует подумать?

Я пытался объяснить как можно яснее, и я надеюсь, что все вышесказанное имеет смысл. пожалуйста, дайте мне знать, если мне нужно кое-что уточнить. кстати я кодирую в php / mysql

Answer 1

Это на самом деле проще и безопаснее, чем вы думаете. При использовании размещенной страницы оплаты, такой как SIM-карта Authorize.Net SIM , включается какой-то хэш, о котором знают только вы и процессор. Фальсифицировать невозможно, так как для его генерации требуется личная информация, которую имеют только вы и процессор. Поэтому все, что вам нужно сделать, это убедиться, что хеш, отправленный на страницу возврата обработчиком платежей, совпадает с хешем, указанным для транзакции. Если это так, вы можете быть на 100% уверены, что транзакция не была подделана.

Сеансы, как правило, длятся дольше, чем обычно требуется для завершения поездки в форму удаленного извлечения, а сессия продолжается, даже если пользователь покидает ваш сайт. Но если вы беспокоитесь о том, что сеанс истекает до того, как он вернется на ваш сайт, просто сохраните информацию о сеансе в базе данных и используйте cookie для отслеживания пользователя. Затем, когда они вернутся, используйте cookie, чтобы идентифицировать их и получить информацию об их сеансе из вашей базы данных.

UPDATE:

Вот как вы можете продлить сеансовый файл cookie с помощью PHP:

// Makes the cookie last two hours. Make it a higher number to last longer.
session_set_cookie_params(7200); 
session_start();

Answer 2

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

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

• Что если пользователь отключится в середине процесса?
• Некоторые процессоры CC вынуждают вас открывать всплывающее окно для обработки, что, если пользователь закрывает его?
• Что, если на сервере происходит сбой?
• Что делать, если метод оплаты не удался и пользовательхочет повторить попытку с другим типом платежа?

Теперь некоторые случайные мысли о реализации шлюза оплаты:

• Некоторые процессоры откладывают аутентификацию покупки, они возвращаются на ваш сайтчто платеж принят, но вам придется использовать их веб-сервис для проверки окончательного статуса;
• Некоторые процессорыдадут вам право захватить покупку, а это означает, что даже если она была одобрена, вы можете аннулировать или завершить ее позже, это хорошо, чтобы кардеры не покупали вещи с вашего сайта, вы можете проверить информацию пользователя, чтобы убедиться, что все это хорошо, что они захватывают или аннулируютПокупка без возврата платежа.
• Если процессор вашей кредитной карты предоставляет вам доступ к веб-сервису или они выполняют аутентификацию покупки от сервера к серверу, для этого потребуется действующий сертификат ssl, поэтому имейте в виду.

Это все, что я могу вспомнить сейчас.