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

Skip to end of metadata
Go to start of metadata

Ошибка при переходе на страницу оплаты из личного кабинета

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

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

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

  1. Включите повышенное логирование модулей кабинета по статье;
  2. Попробуйте совершить тестовый платёж;
  3. Соберите данные по тестовому платежу;
  4. Отправьте запрос в техническую поддержку платёжной системы с данными о платеже;
  5. Создайте заявку в helpdesk с комментариями от технической поддержки платёжной системы.

Убедитесь что на стороне платежной системы правильный адрес обработчика биллинга

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

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

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

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

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

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

  • Орфографические ошибки где-то в названии php:
    https://bestisp.ru:1443/ossssmp.php

    Ошибка в имени php-файла, правильно "osmp.php"

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

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

  • Неправильный протокол, http вместо https или наоборот:
    http://bestisp.ru:1443/osmp.php

    Здесь должен быть протокол https, так как используется защищенный порт 1443

Может не тот порт? (например, 1444 для https или 1443/2443) для http

Неправильно
https://bestisp.ru/osmp.php
Правильно
https://bestisp.ru:1443/osmp.php

Был пропущен порт, указанный в основных настройках платежных систем

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

Убедитесь, что IP-адреса платёжной системы есть в разрешенном списке. Это можно сделать в меню настройки сети платёжных систем.

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

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

  1. Добавьте в список разрешенных IP "весь интернет": подсеть 0.0.0.0/0
  2. Совершите платёж как обычно

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

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

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

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

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

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

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

tcpdump -nnei any port 1443 or port 2443 or port 1444

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

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

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

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

tcpdump -nnei any host 10.0.0.1 or net 10.1.1.0/24

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

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

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

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

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

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

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

 telnet <ip_биллинга> <порт>

При этом на сервере в выводе tcpdump должен быть вывод вида:

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

При правильной настройке пакеты будут и входящие и исходящие.

При этом telnet соединение будет устанавливаться.

Если соединения нет:

- Проверьте, что ваш ip-адрес есть в списке разрешенных в настройках платежных систем.
Для приема платежей со стороны платежной системы необходимо добавить IP-адреса, с которых осуществляется запрос в список разрешенных, IP через пробел.
Это делается через главную страницу веб-интерфейса администратора Carbon Billing 5 (http://<ip_сервера>:8081) -> Платежные системы -> Настройка сети -> АДРЕСА СЕРВЕРОВ ПЛАТЕЖНЫХ СИСТЕМ

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

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

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

Этот адрес имеет вид:

http://11.22.33.44:1444/robokassa.php

где

11.22.33.44 - это ip-адрес вашего сервера или ваше доменное имя,

1444 - порт, который использует платежная система,

robokassa.php - обработчик данных от платежной системы.

Вставьте этот адрес в адресную строку браузера и проверьте вывод. Для платежных систем с шифрованием необходимо скачать с сервера сертификат в формате *.pfx и импортировать его в ваш браузер.

Вывод будет примерно такой:

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

Возможно трафик блокирует rp_filter

Если прочие пункты инструкции Вы проверили и всё в порядке, возможно проблема в rp_filter.
Убедитесь, что ответный маршрут к IP платёжной системы ведёт через тот же интерфейс, на который она обращается.
Проверить это можно так:

  1. С tcpdump посмотрите, на какой интерфейс приходит пакет
  2. Посмотрите, как пойдёт ответ с помощью ip r g to <IP>, где вместо <IP> подставьте адрес платёжки.
    Интерфейсы должны совпадать.

Так же Вы можете включить логирование "марсианских" пакетов - такими ядро Linux считает пакеты, у которых трафик по scr адресу ожидается на другом интерфейсе

echo 1 > /proc/sys/net/ipv4/conf/all/log_martians

Пример, как диагностировать по логу:

# пришедший пакет в логе
[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

Видно, что пакет к адресу платёжных систем 169.254.14.43 пришел с адреса 88.85.210.133 на интерфейс eth0, а обратный пойдёт через eth1.

Как исправить

  1. Добавьте маршрут к адресу источника через нужный интерфейс. Для интерфейса eth0 это будет файл /etc/sysconfig/network-scripts/route-eth0
    На лету это можно сделать отдельной командой:
    ip r add 88.85.210.133 via <GATEWAY_IP> dev eth0

    Где вместо <GATEWAY_IP> укажите IP шлюза на этом интерфейсе.
    При этом в файл сохранить маршрут тоже нужно.

  2. Если у Вас нет возможность добавить маршрут, можете настроить менее жесткую проверку rp_filter на интерфейсе, откуда куда приходит трафик от платёжной системы, или совсем его отключить.
    Допустим, это интерфейс eth0, тогда выполните следующую команду
    sysctl -w net.ipv4.conf.eth0.rp_filter=2

    И попробуте повторить платёж.
    Если это решило проблему, добавьте настройку в /etc/sysctl.conf, чтобы она сохранилась при перезагрузках

    # Controls source route verification
    net.ipv4.conf.default.rp_filter = 1
    # Для платёжных систем
    net.ipv4.conf.eth0.rp_filter = 2
    
    rp_filter=2 пропустит трафик, если хотя бы один интерфейс может ответить. Этого должно хватить. Если не поможет - можно совсем отключить  rp_filter: rp_filter=0

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

  1. Если есть трафик проверьте логи http сервера. Есть два лога, с ошибками:
    /app/asr_fiscal/var/log/httpd/error_log

    И общий лог для всех соединений.

    /app/asr_fiscal/var/log/httpd/access_log

    Если не прошел конкретный платёж найдите его в логе по времени.

  2. Если данные о платеже есть в логе http сервера, проверьте лог обработчика используемой платежной системы (как правило называется подобно наименованию обработчика) и посмотрите, что в нем нет ошибок обработки платежей.
    Логи платежных систем располагаются в папке:
    /app/asr_fiscal/var/log/paysystems/

    Также путь к логу Вы можете узнать в документации по настройке платежной системы.

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

Убедитесь по журналу API биллинга, что в них отсутствуют ошибки:
В первую очередь журнал запросов API в контейнере платежных систем:

/app/asr_fiscal/var/log/api.log

Если в нем есть какие-либо ошибки, их можно проанализировать в логах биллинга:

/app/asr_billing/var/log/django/system_api.log
/app/asr_billing/var/log/admin_web_server.log
Файлы журналов могут ротироваться каждые сутки и храниться в течение 30 дней; если необходимо найти ошибку, произошедшую в недавнем прошлом, найдите соответствующий архивный файл:
/app/asr_billing/var/log/admin_web_server.log - актуальный файл
/app/asr_billing/var/log/admin_web_server.log-20190218.gz - архивный файл

Пример поиска ошибок в логе /app/asr_fiscal/var/log/api.log:

grep -i err /app/asr_fiscal/var/log/api.log | tail -n 2

Вывод:

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

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

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

В логе платежной системы возникает ошибка

 get() returned more than one Abonents -- it returned 2!

Проверьте настройки в разделе Главное меню биллинга - "Платежная системы" - "Настройки OSMP" Также, для быстрого перехода можно использовать ссылку ниже:

http://169:254:80:81:8081/settings/asr_fiscal/osmp/
169:254:80:81 замените на IP Вашего биллинга

Настройки ИДЕНТИФИЦИРОВАТЬ позволяют выбрать, по каким параметрам все обработчики платежных систем ищут абонента. Рекомендуется оставить только один вариант, наилучшим будет ИДЕНТИФИЦИРОВАТЬ ПОЛЬЗОВАТЕЛЯ ПО НОМЕРУ ДОГОВОРА

Стали повторяться номера платежей

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

Платежные системы отправляющие данные в формате XML
Примеры: [Биллинговые системы, Центральная Касса, КиберПлат], ОСМП
  1. В лог платежной системы пишутся параметры пришедшие на обработчик в виде XML
  2. ОСМП-подобные протоколы обязательно должны содержать account и act=pay/check

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

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

Метки

Введите метки, чтобы добавить к этой странице:
Please wait 
Ищите метку? просто начните печатать.