Платежные системы. Не проходят платежи.

Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.

Изменения (39)

просмотр истории страницы
При возникновении проблем с приемом платежей проверьте что пакеты от платежной системы на биллинг приходят и отправляются обратно.
{toc:maxLevel=3}

Для этого: 

h5. 1. Запустите на биллинге tcpdump командой
h1. Ошибка при переходе на страницу оплаты из личного кабинета

Для стандартных настроек платежной системы без шифрования без шифрования
{code}tcpdump -nvi any port 1444{code}Для стандартных настроек платежной системы без шифрования с шифрованием
h3. Как проверить что проблема в этом?

Совершить тестовый платёж. На странице оплаты возникает сообщение об ошибке.

{code}tcpdump -nvi any port 1443{code}
h3. Как исправить?

*Примечание: Порты могут быть другие, в зависимости от того, какие указаны у вас в настройках* *[платежных систем|http://docs.carbonsoft.ru/pages/viewpage.action?pageId=49087129]**.*
# Включите повышенное логирование модулей кабинета по [статье|Отладка модулей кабинета];
# Попробуйте совершить тестовый платёж;
# Соберите данные по тестовому платежу;
# Отправьте запрос в техническую поддержку платёжной системы с данными о платеже;
# Создайте заявку в helpdesk с комментариями от технической поддержки платёжной системы.

h5. 2. Проверяем доступность портов платежных систем
h1. Убедитесь что на стороне платежной системы правильный адрес обработчика биллинга

h3. Как проверить что проблема в этом?

Чтобы проверить, адрес правильный или нет - просто откройте его в браузере, предварительно добавив свой адрес в список разрешенных для доступа к платёжным системам.

h3. Как исправить?

Укажите правильный адрес с учетом всех нюансов в личном кабинете платёжной системе или попросите их поддежку указать нужную ссылку (зависит от возможности ЛК платёжки).

h2. Локализуем проблему

h3. Возможно какая-то ошибка в тексте ссылки (неверные символы и тд)

* Орфографические ошибки где-то в названии php:
{code}https://bestisp.ru:1443/ossssmp.php{code}
Ошибка в имени php-файла, правильно "*o{*}{color:red}{*}s{*}{color}{*}mp.php*"

* Проверить можно, в том числе и по логу web-сервера asr_fiscal:
{code}tail -f /app/asr_fiscal/var/log/httpd/access_log{code}

h3. Может не тот протокол (http вместо https или наоборот)?

* Неправильный протокол, http вместо https или наоборот:
{code}http://bestisp.ru:1443/osmp.php{code}
Здесь должен быть протокол *https*, так как используется защищенный порт _1443_

h3. Может не тот порт? (например, 1444 для https или 1443/2443) для http
{code:title=Неправильно}https://bestisp.ru/osmp.php{code}
{code:title=Правильно}https://bestisp.ru:1443/osmp.php{code}
Был пропущен порт, указанный в [основных настройках платежных систем|CarbonBilling:Основные настройки платежных систем]

h1. Возможно запросы не проходят firewall

Убедитесь, что IP-адреса платёжной системы есть в разрешенном списке. Это можно сделать в меню [настройки сети|CarbonBilling:Настройка сети для платежных систем] платёжных систем.
{info}
Бывает, что платёжная система меняет IP-адреса с которых приходят данные о платежах. Если данные о платежах не приходят, нужно запросить актуальный список IP-адресов.
{info}

h3. Как проверить, в этом проблема или нет?

# Добавьте в [список разрешенных IP|CarbonBilling:Настройка сети для платежных систем] "весь интернет": подсеть 0.0.0.0/0
# Совершите платёж как обычно

Если платёж пройдет - значит точно дело в адресе

h3. Как исправить?

Заведите адреса или подсети платёжных систем в список разрешенных.

{warning}Не забудьте убрать подсеть 0.0.0.0/0 из списка разрешенных когда закончите отладку\!{warning}

h2. Локализуем проблему

h3. Запросы приходят не с того адреса

Если адреса есть в списке, но запросов от платежной системы не видно в логе, проверьте приходит ли от них трафик на [порты платежных систем|CarbonBilling:Основные настройки платежных систем] с помощью tcpdump:

{code}tcpdump -nnei any port 1443 or port 2443 or port 1444{code}

Такое может случиться если у платёжной сети изменились IP-адреса - возможно у них сменился провайдер или они просто расширили сеть.

h3. Запросы приходят не на тот порт

{info}Примечание: Порты могут быть другие, в зависимости от того, какие указаны у вас в настройках *[платежных систем|http://docs.carbonsoft.ru/pages/viewpage.action?pageId=49087129]*.{info}

Если уверены, что адреса точно правильные, запустите tcpdump без указания порта, но с IP-адресами платежных систем. Допустим, адреса платежной системы 10.0.0.1 и 10.1.1.0/24, команда будет такой:
{code}tcpdump -nnei any host 10.0.0.1 or net 10.1.1.0/24{code}

Такое может случаться, если со стороны платёжной системы определён ограниченный набор сетевых портов по которым они могут интегрироваться - например, [CarbonBilling:Тинькофф] может отсылать запросы только на порты 80, 8080, 443 и 1443, а на 1444 и 2443 - не может.

h4. Как исправить?

В том же примере с [CarbonBilling:Тинькофф] \- правилами DNAT.

Но попробуйте вернуться к самому первому пункту этой инструкции и убедитесь что правильно указали адрес обработчика.

Если ни чего не помогло - видимо проблема глубже и совсем нетипичная. Подключите поддержку платёжной системы к решению.

h3. Проверяем доступность портов для платежных систем

Предварительно на сервере оставьте команду tcpdump, чтобы видеть пакеты. Тестировать прохождение пакетов вы можете командой
{code}
...


h5. 3. Проверяем доступность обработчика платежной системы

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

  !pay_sys.png|border=1!
По возможности проверьте возвращаемый код при передаче параметров
В случае, если платежная система использует 443 порт - необходимо изменить поле "ПОРТ, НА КОТОРОМ ДОСТУПЕН ВЕБ-ИНТЕРФЕЙС АБОНЕНТА:", который по умолчанию так же указан 443, на любой другой, например 2443 во вкладке "Платежные системы"

h5. 4. По возможности проверьте возвращаемый код при передаче параметров
!port443.png|border=1!

Его можно получить самостоятельно если вы разбираетесь в платежных системах.

Либо можно его запросить у специалиста платежной системы. Здесь нужно знать какой запрос шлет платежная система и что ей отвечает на него обработчик.
h3. Возможно трафик блокирует rp_filter

Запрос будет вида:
Если прочие пункты инструкции Вы проверили и всё в порядке, возможно проблема в rp_filter.
Убедитесь, что ответный маршрут к IP платёжной системы ведёт через тот же интерфейс, на который она обращается.
Проверить это можно так:
# С tcpdump посмотрите, на какой интерфейс приходит пакет
# Посмотрите, как пойдёт ответ с помощью {{ip r g to <IP>}}, где вместо <IP> подставьте адрес платёжки.
Интерфейсы должны совпадать.

Так же Вы можете включить логирование "марсианских" пакетов - такими ядро Linux считает пакеты, у которых трафик по scr адресу ожидается на другом интерфейсе
{code}echo 1 > /proc/sys/net/ipv4/conf/all/log_martians{code}
Пример, как диагностировать по логу:
{code}
http://11.22.33.44:1444/robokassa.php?<список параметров>
# пришедший пакет в логе
[root@CarbonBillingServer ~]# tail -f /var/log/messages
May 23 16:43:42 CarbonBillingServer kernel: martian source 169.254.14.43 from 88.85.210.133, on dev eth0
May 23 16:43:42 CarbonBillingServer kernel: ll header: 0c:c4:7a:e5:a8:56:10:f3:11:14:a3:4a:08:00

# проверка маршрута к адресу источника пакета
[root@CarbonBillingServer ~]# ip r g to 88.85.210.133
88.85.210.133 via 172.22.0.1 dev eth1 src 172.22.0.222
cache mtu 1500 hoplimit 64
{code}
Вывод будет похож на скриншот выше, но иметь другой вывод.
Видно, что пакет к адресу платёжных систем 169.254.14.43 пришел с адреса 88.85.210.133 на интерфейс eth0, а обратный пойдёт через eth1.

h5. 5. При платеже находит несколько абонентов.
h4. Как исправить

Проверьте настройки:
# Добавьте маршрут к адресу источника через нужный интерфейс. Для интерфейса eth0 это будет файл {{/etc/sysconfig/network-scripts/route-eth0}}
На лету это можно сделать отдельной командой:
{code}ip r add 88.85.210.133 via <GATEWAY_IP> dev eth0{code}
Где вместо <GATEWAY_IP> укажите IP шлюза на этом интерфейсе.
При этом в файл сохранить маршрут тоже нужно.
# Если у Вас нет возможность добавить маршрут, можете настроить менее жесткую проверку rp_filter на интерфейсе, откуда куда приходит трафик от платёжной системы, или совсем его отключить.
Допустим, это интерфейс eth0, тогда выполните следующую команду
{code}sysctl -w net.ipv4.conf.eth0.rp_filter=2{code}
И попробуте повторить платёж.
Если это решило проблему, добавьте настройку в {{/etc/sysctl.conf}}, чтобы она сохранилась при перезагрузках
{code}
http://11.22.33.44:8081/settings/asr_fiscal/osmp/
# Controls source route verification
net.ipv4.conf.default.rp_filter = 1
# Для платёжных систем
net.ipv4.conf.eth0.rp_filter = 2
{code}
{note}{{rp_filter=2}} пропустит трафик, если хотя бы один интерфейс может ответить. Этого должно хватить. Если не поможет - можно совсем отключить  rp_filter: {{rp_filter=0}}{note}


h2. Проверка логов платежной системы

# Если есть трафик проверьте логи http сервера. Есть два лога, с ошибками:
{code}/app/asr_fiscal/var/log/httpd/error_log{code}
И общий лог для всех соединений.
{code}/app/asr_fiscal/var/log/httpd/access_log{code}
Если не прошел конкретный платёж найдите его в логе по времени.
# Если данные о платеже есть в логе http сервера, проверьте лог обработчика используемой платежной системы (как правило называется подобно наименованию обработчика) и посмотрите, что в нем нет ошибок обработки платежей.
Логи платежных систем располагаются в папке:
{code}/app/asr_fiscal/var/log/paysystems/{code}
Также путь к логу Вы можете узнать в [документации по настройке платежной системы|CarbonBilling:Платёжные системы].

h2. Проверка логов API

Убедитесь по журналу API биллинга, что в них отсутствуют ошибки:
В первую очередь журнал запросов API в контейнере платежных систем:
{code}/app/asr_fiscal/var/log/api.log{code}
Если в нем есть какие-либо ошибки, их можно проанализировать в логах биллинга:
{code}/app/asr_billing/var/log/django/system_api.log
/app/asr_billing/var/log/admin_web_server.log{code}
{note}Файлы журналов могут ротироваться каждые сутки и храниться в течение 30 дней; если необходимо найти ошибку, произошедшую в недавнем прошлом, найдите соответствующий архивный файл:
/app/asr_billing/var/log/*admin_web_server.log* \- +актуальный+ файл
/app/asr_billing/var/log/*admin_web_server.log-20190218.gz* \- +архивный+ файл{note}
Пример поиска ошибок в логе */app/asr_fiscal/var/log/api.log*:
{code}grep -i err /app/asr_fiscal/var/log/api.log | tail -n 2{code}
Вывод:
{code}2019-02-18 01:08:58 __call_api->curl_error($ch): Failed to connect to 169.254.80.82 port 8082: Connection refused
2019-02-18 12:23:15 __call_api->curl_error($ch): Operation timed out after 30001 milliseconds with 0 bytes received{code}

h1. Примеры решения проблем

h2. При платеже находит несколько абонентов.

В логе платежной системы возникает ошибка
{code} get() returned more than one Abonents -- it returned 2!{code}

Проверьте настройки в разделе *Главное меню биллинга - "Платежная системы" - "Настройки OSMP"* Также, для быстрого перехода можно использовать ссылку ниже:
{code}
http://169:254:80:81:8081/settings/asr_fiscal/osmp/
{code}
{info}*169:254:80:81* замените на IP Вашего биллинга{info}
Настройки *ИДЕНТИФИЦИРОВАТЬ* позволяют выбрать, по каким параметрам все обработчики платежных систем ищут абонента. Рекомендуется оставить только один вариант, наилучшим будет *ИДЕНТИФИЦИРОВАТЬ ПОЛЬЗОВАТЕЛЯ ПО НОМЕРУ ДОГОВОРА*

h5. 6. В случае, если платежная система использует 443 порт - необходимо изменить поле "ПОРТ, НА КОТОРОМ ДОСТУПЕН ВЕБ-ИНТЕРФЕЙС АБОНЕНТА:", который по умолчанию так же указан 443, на любой другой, например 2443 во вкладке "Платежные системы"
h2. Стали повторяться номера платежей

h5. 7. Все данные, которые удалось получить необходимо будет передать специалистам технической поддержки через заявку в [HelpDesk|http://helpdesk.carbonsoft.ru]
Перестали проходить платежи через Робокассу. Сервис выдает ошибку: 40 (со стороны Робокассы).
Данная ошибка 40 возникает на стороне магазина. В момент формирования запроса на инициализацию оплаты биллинг передает в Robokassa значение InvId (уникальный номер платежа), которое уже использовалось прежде. Этот параметр должен принимать с каждой переадресацией в сервис ROBOKASSA уникальное значение. Ошибка показывает, что один из клиентов уже оплатил данный номер заказа ранее, а сейчас биллинг переадресует в Robokassa другого плательщика, выставляя ему тот же номер счета.
Проблема может возникнуть, если Вы переключили интеграцию Робокассы с другого биллинга на Carbon Billing.
Необходимо исправить начальное значение параметра InvId. Это может сделать техническая поддержка по запросу, следовательно, нужно создать заявку с описанием проблемы в Helpdesk.

{info} Платежные системы отправляющие данные в формате XML
Примеры: [Биллинговые системы, Центральная Касса, КиберПлат|CarbonBilling:Сбербанк. ООО Биллинговые системы, Центральная Касса, КиберПлат], [ОСМП|CarbonBilling:Инструкция по подключению ОСМП. Несколько операторов]

# В лог платежной системы пишутся параметры пришедшие на обработчик в виде XML
# ОСМП-подобные протоколы обязательно должны содержать account и act=pay/check{info}

h1. Если все равно не удалось понять в чем проблема

Создайте заявку в [HelpDesk|http://helpdesk.carbonsoft.ru], опишите результаты проверки по инструкции выше: текст, скриншоты или видео.
Если возможно, сделайте скриншоты настроек *в личном кабинете платёжной системы* и приложите к заявке. Также ускорит решение заявки наличие логов.