... {toc:maxLevel=3}
|
|
h1. Ошибка при переходе на страницу оплаты из личного кабинета
|
h3. Как проверить что проблема в этом?
|
Совершить тестовый платёж. На странице оплаты бедет возникает сообщение об ошибке.
|
h3. Как исправить?
|
# Включите повышенное логирование модулей кабинета по [статье|Отладка модулей кабинета];
|
# Попробуйте совершить тестовый платёж;
# Соберите данные по тестовому платежу;
|
# Отправьте запрос в техническую поддержку платёжной системы с данными о платеже;
|
# Создайте заявку в helpdesk с комментариями от технической поддержки платёжной системы.
|
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}
telnet <ip_биллинга> <порт>
{code}
При этом на сервере в выводе tcpdump должен быть вывод вида:
{code}
12:11:56.526872 10.90.1.180.37544 > 10.90.180.10.1443: S [tcp sum ok] 368052329:368052329(0) win 14600
12:11:56.526943 10.90.180.10.1443 > 10.90.1.180.37544: S [tcp sum ok] 3188614068:3188614068(0) ack 368052330 win 5792
{code}
При правильной настройке пакеты будут и входящие и исходящие.
При этом telnet соединение будет устанавливаться.
*Если соединения нет:*
\- Проверьте, что ваш ip-адрес есть в списке разрешенных в настройках [платежных систем.|http://docs.carbonsoft.ru/pages/viewpage.action?pageId=49087129]
Для приема платежей со стороны платежной системы необходимо добавить IP-адреса, с которых осуществляется запрос в список разрешенных, IP через пробел.
Это делается через главную страницу веб-интерфейса администратора Carbon Billing 5 (http://<ip_сервера>:8081) \-> Платежные системы \-> Настройка сети \-> АДРЕСА СЕРВЕРОВ ПЛАТЕЖНЫХ СИСТЕМ
\- Если перед биллингом установлено пограничное оборудование, проверьте разрешен ли трафик по портам платежных систем. Также порты могут быть закрыты у вашего вышестоящего провайдера.
h3. Проверяем доступность обработчика платежной системы
В личном кабинете вашей платежной системы должен быть указан адрес куда сервер платежной системы шлет запросы.
Этот адрес имеет вид:
{code}
http://11.22.33.44:1444/robokassa.php
{code}
где
11.22.33.44 - это ip-адрес вашего сервера или ваше доменное имя,
1444 - порт, который использует платежная система,
robokassa.php - обработчик данных от платежной системы.
Вставьте этот адрес в адресную строку браузера и проверьте вывод. Для платежных систем с шифрованием необходимо скачать с сервера [сертификат в формате \*.pfx|http://docs.carbonsoft.ru/pages/viewpage.action?pageId=49087129] и импортировать его в ваш браузер.
Вывод будет примерно такой:
!pay_sys.png|border=1!
По возможности проверьте возвращаемый код при передаче параметров
В случае, если платежная система использует 443 порт - необходимо изменить поле "ПОРТ, НА КОТОРОМ ДОСТУПЕН ВЕБ-ИНТЕРФЕЙС АБОНЕНТА:", который по умолчанию так же указан 443, на любой другой, например 2443 во вкладке "Платежные системы"
!port443.png|border=1!
|
|
h1. Если все равно не удалось понять в чем проблема
|
h3. Возможно трафик блокирует rp_filter
|
|
Создайте заявку в [HelpDesk|http://helpdesk.carbonsoft.ru], опишите результаты проверки по инструкции выше: текст, скриншоты или видео.
Если возможно, сделайте скриншоты настроек *в личном кабинете платёжной системы* и приложите к заявке. Также ускорит решение заявки наличие логов:
|
Если прочие пункты инструкции Вы проверили и всё в порядке, возможно проблема в 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}
# пришедший пакет в логе
[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.
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}
# 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://11.22.33.44:8081/settings/asr_fiscal/osmp/ http://169:254:80:81:8081/settings/asr_fiscal/osmp/
|
{code}
|
{info}*169:254:80:81* замените на IP Вашего биллинга{info}
|
Настройки *ИДЕНТИФИЦИРОВАТЬ* позволяют выбрать, по каким параметрам все обработчики платежных систем ищут абонента. Рекомендуется оставить только один вариант, наилучшим будет *ИДЕНТИФИЦИРОВАТЬ ПОЛЬЗОВАТЕЛЯ ПО НОМЕРУ ДОГОВОРА*
|
... h2. Стали повторяться номера платежей
Перестали проходить платежи через Робокассу. Сервис выдает ошибку: 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], опишите результаты проверки по инструкции выше: текст, скриншоты или видео.
Если возможно, сделайте скриншоты настроек *в личном кабинете платёжной системы* и приложите к заявке. Также ускорит решение заявки наличие логов.
|
