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

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

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

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

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

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


php payment-gateway shopping-cart
person spirytus    schedule 14.07.2010    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

ОБНОВЛЕНИЕ:

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

// Makes the cookie last two hours. Make it a higher number to last longer.
session_set_cookie_params(7200); 
session_start();
person John Conde    schedule 15.07.2010
comment
Или вы можете просто настроить PHP так, чтобы он имел более длинный файл cookie сеанса (что можно сделать во время выполнения с помощью session_set_cookie_params ()). - person Lèse majesté; 15.07.2010
comment
@ Lèse majesté Очень хорошее замечание. Внесение изменений в ответ для демонстрации примера. - person John Conde; 15.07.2010
comment
Хэш, возвращенный со страницы размещенной оплаты, был бы отличным, но платежный шлюз, который я использую, похоже, не возвращает ничего подобного. Я полностью облажался, и я не могу реализовать его, не размещая страницу формы самостоятельно и в то же время испытывая проблемы с совместимостью с PCI? - person spirytus; 28.07.2010
comment
Они должны вернуть вам кучу информации. Если вы можете убедиться, что несколько точек данных совпадают правильно, вы можете предположить, что ответ исходит от них. Если у них есть настраиваемые поля, передайте свой собственный хэш и посмотрите, чтобы он вам вернули. Вы также можете убедиться, что IP-адрес, с которого отправляется ответ, является одним из их адресов. - person John Conde; 28.07.2010
comment
К сожалению, проверка IP-адресов не сработает, так как, очевидно, IP-адреса платежных серверов могут меняться в разное время. Существует возможность передать шлюзу дополнительные параметры и вернуть их после оплаты пользователем. Проблема, однако, в том, что эти параметры можно легко найти, поскольку они просто доступны в скрытых полях ввода. Боюсь, что кто-то может проверить все параметры и отправить мне фальшивое подтверждение платежа, не заплатив ни цента. Кажется, не существует способа передачи данных, которые могли бы идентифицировать шлюз и были бы недоступны пользователю в какой-то момент. - person spirytus; 28.07.2010
comment
Легко привыкает свободно. Я уверен, что страницы зашифрованы, что затрудняет доступ к информации. Если вы передаете одноразовый хэш туда и обратно, вы резко повышаете уровень уверенности в личности отправителя. Но похоже, что ваш процессор предлагает плохой API. Вам нужно либо отказаться от них, либо принять менее идеальную безопасность. - person John Conde; 28.07.2010
comment
Я сказал легко, поскольку он прямо там, в виде обычного текста в скрытом поле ввода, очевидно, не отображается, но любой может проверить его с помощью источника просмотра и т.д. Служба запросов, которую они предлагают, имеет ограничение в 100 запросов в день, которое не может быть увеличено. Честно говоря, этот платежный шлюз выглядит очень прилично и очень популярен, насколько я могу судить, поэтому я предполагаю, что, возможно, я не совсем понимаю что-то здесь и пытаюсь найти решение. Кстати, спасибо за ваши ответы и попытки помочь Джону - person spirytus; 29.07.2010

arrow_upward
1
arrow_downward

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

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

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

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

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

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

person Rodrigo    schedule 14.07.2010