В выборе банка Эквайера, в данном случае не мне приходится решать.... Клиенту "Навязывают" этот банк Отписал в банк, что документация не соответствует действительности... Вариант который сейчас пробуем реализовать, у них называется двухфазным. Типа самый простой! Есть ещё варианты (как вы и описали в своём последнем ответе) и ещё ++, когда сначала запрашиваем токен, потом с токеном отправляем запрос на старт платежа, потом все тоже самое что и при двухфазном варианте. Но! там есть подводные камни тоже, например с вариантом хранения данных карт! Уж очень не хочется хранить такие персональные данные в своей системе, так как вскоре может последовать какое нить новое положение по сертификации системы согласно "Стандарт PCI DSS", чему сейчас могут быть подвержены существующие Интернет магазины. Уж лучше, пусть всё на их стороне пусть будет!
Верно. С сертификацией PCI лучше не связываться и данные карт не хранить. Но есть еще два подводных камня - 3D Secure и блокировка зачисления на счёт получателя после завершения транзакции. На территории ЕС это обязательные оптии. 1. В случае применения 3D Secure, платёжный сервис в процессе акцептирования, в начале присылает ответ со статусами "отклонён" или "на запросе", а затем после подтверждения кода через SMS, отправляется ответ со статусами "отклонён" или "успех". Это сильно усложняет реализацию акцептирования платежей в реальном времени на стороне клиента. 2. После завершения транзакции срок зачисления на счёт получателя определяется в договоре между клиентом и платёжным сервисов и может быть различным (от 60 до 120 дней). Очевидно, что выгоднее выбрать такой сервис, у которого этот срок минимальным. Это связано с тем, что период возврата платежа (Chargeback) - восемь недель, для платежей дебетовыми и кредитными картами Mastercard, Visa и American Express.
Доброго времени всем! В общем, продвинулся немного! Запрос от банка не приходил по банальной причине, протух сертификат SSL. Точнее скриптовый сертификат у нас обновился, а у них его не обновили. Получив доступ в консоль магазина на стороне Банка, была видна ошибка, что запрос не прошел проверку. Вот только не понятно почему со стороны банка скрипт не останавливал работу не понятно... Не уведомлял что сертификат не соответствует... отправлял второй запрос о не удавшемся платеже... Настроили (вместе с банком) чтоб первый запрос приходил на нужный нам адрес, сейчас он vircgpb/cpareg Они предлагали сделать vircgpb/cpareg.php Но почитав в мануалах усвоил, что обращаться к исполняемому скрипту это плохой тон... (правильно усвоил, или есть мнения?) Настроил на адрес... Сейчас вопрос больше базовых знаний, GET запрос приходит, в нем проверяются параметры, нужно теперь сравнить одинаковые параметры из моего запроса, с таким же, параметром из запроса к нам. например, o_order_id Наш GET запрос через форму: Код (Text): Array ( [merch_id] => 946AD4CD0F6B946B0EF3 [back_url_s] => 2https://nanaca.ru/lk [back_url_f] => https://nanaca.ru/lk [o_order_id] => 70500770-486BBD44F3F8F6E2AE6B-1031233115 ) GET запрос банка: Код (Text): Array ( [merch_id] => 946AD4CD0F6B946B0EF3 [trx_id] => 8MC8Y3G4RZ8AIQEK [o_order_id] => 70500770-486BBD44F3F8F6E2AE6B-1031233115 [ts] => 20241031 23:31:20 [q] => vircgpb/cpareg ) Мне при сравнении нужно значение параметра из базы выдергивать, или он в памяти ещё есть после запроса через форму?
Добрый день! В памяти после перезапуска скрипта есть только то, что передаётся в скрипт - $_REQUEST или $_SESSION. Если нужно что-то сохранить, то перед отправкой запроса через форму сохраните данные в $_SESSION Удачи!
Дополнение При работе с платёжными системами, клиентские скрипты, обрабатывающие данные транзакций, запускются асинхронно. Продолжительность акцептирования на стороне сервиса может превышать время жизни сессии PHP. Поэтому, в этом случае безопасно передавать данные можно только сохраняя их в БД. Мною на практике проверено такое решении: На каждый платёж в БД в таблице payment заводится запись с данными транзакций и ссылкой на таблицу заказов (order_id). Ежедневно через Cron Job запускается PHP-скрипт проверяющий, данные заказов и их оплату. В том случае, если оплата заказа не была успешной, из этого скрипта отправляются мэйлы бухгалтеру фирмы и клиенту-плательщику. В письмо клиента, кроме текста с требованием оплаты, встраивается линк на оплату заказа.
День добрый! В документации написано, что данный этап выполняется синхронно. В общем, у них гибридный вариант, первый запрос от нас, и первый и второй ответ от них - асинхронные, но на первый и второй ответ от них, нужно отвечать синхронно. В базе сохраняется конечно сгенерированный номер "платежного счета", и сумма платежа по нему. Про безопасность услышал, будем вытаскивать из базы инфу о платежном счете... Но, если ответ синхронный, значит нужно ответить ответом типа "$response = ", тут тоже ещё один вопрос возник, через форму отправлять или можно как то по другому, в документации нет такого описании. Задал им вопрос, пока молчат...
На первом подготовительном этапе (пока на стороне сервиса фомудяр оплаты для клиента ещё не открылся), да м.б. синхронно. Но я написал Вам об ответах, которые приходят с сервиса после того как клиент нажал кнопку "оплатить". Причём если оплата проходит по регламенту 3-D Secure, ответа может быть два. Это работает только асинхронно. По опыту, бывает длительная задержка во времени (десятки минут) между ответом со стасом "payment on request" и вторым ответом со статусами "success" или "rejected"