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

Skip to end of metadata
Go to start of metadata

Что делать, если в биллинг не поступают платежи

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

Убедитесь что в ЛК платежной системы правильно указан путь до обработчика:

  • Орфографические ошибки где-то в названии 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://bestisp.ru:1443/osmp.php

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

Проверка firewall

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

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

Проверка работы сети

  • Если адреса есть в списке, но запросов от платежной системы не видно в логе, проверьте приходит ли от них трафик на порты платежных систем с помощью tcpdump:
    tcpdump -nnei any port 1443 or port 2443 or port 1444
    Примечание: Порты могут быть другие, в зависимости от того, какие указаны у вас в настройках платежных систем.
  • Если запросов нет, запустите 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

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

Предварительно на сервере оставьте команду 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 во вкладке "Платежные системы"

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

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

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

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

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

Проверка логов 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

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

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

Проверьте настройки:

http://11.22.33.44:8081/settings/asr_fiscal/osmp/

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

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

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

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

Метки

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