Проблемы API/SCI Liberty Reserve

Предлагаю в этой теме обсуждать проблемы API/SCI Liberty Reserve.

Со вчерашнего дня после того как либерти была некоторое время недоступна, у меня перестали приходить запросы после SCI оплаты на моем сайте на адрес lr_status_url. Это не первая (и я думаю, не последняя ) проблема с API/SCI Liberty Reserve. На lr_success_url и lr_fail_url возвращается нормально.

У кого еще возникли подобные проблемы? Отпишитесь плз.

Попробуйте укажите другой хост в lr_status_url, а там поставьте "ловушку".
Я думаю это либо либа забанила IP вашего хоста, либо ваш хостер забанил либу. Либо просто нет связи между вашим хостом и либой.

о блин а я думаю че у меня мобилу не пополнило на вашем сервисе а еще скайп на другом обменнике

С хостером я связывался, IP не забанен, в поддержку Либы написал, но как они отвечают - наверное все знают
Придется пока искать обходные пути...

добавлено через 5 часов 54 минуты
Пообщался в чате с поддержкой ЛР, они сообщили что "есть некоторые проблемы с SCI" , обещали передать технической службе мой вопрос для его решения.

Мерчант либы не шлёт уведомления уже три дня.

У меня на один из трёх хайпов вчера вечером не пришли деньги.Так это значит проблема у либерти?Что посоветуете в данной ситуации

Что касается хайпов, тут Вам точно ответить может только админ.
Хотя как правило, большинство скриптов хайпов определяют, что пришел платеж по странице, на которую вернулся пользователь после оплаты, а это работает нормально.
Пишите админу, отправляйте ему реквизиты платежа - и удачи Вам!

Вчера начали приходить запросы от мерчанта - будем надеяться что наладили.

Снова у Либерти проблемы - не приходят запросы на lr_status_url, и на почту не приходят письма...

У меня та же проблема - именно lr_status_url, ответ не приходит... Но на этом весь сервис держится... Как эту проблему решить?

Navrus, я Вам ответил в другой теме - вот это сообщение - попробуйте..
У меня вроде нормально сейчас (по крайней мере пару дней назад проходила автоматическая оплата)..

Последние 2-3 недели проблем не наблюдается...
Как давно у Вас проблемы?
В скрипте обработки получайте данные из массива $_REQUEST (поменяйте $_POST на $_REQUEST) тогда не будет иметь значения, каким способом GET или POST отправлены данные, у меня была подобная проблема, заменил $_POST на $_REQUEST - и проблем стало меньше

Если пример скрипта брался с сайта Liberty - то у них REQUEST и было прописано изначально...

У меня проблема была связана именно с тем, что запрос не хотел отправляться вообще на мой status_url...
В приёмном скрипте у меня все через REQUEST и запрашивалось, вот только не попадало оно в этот скрипт после оплаты..
Поменял пару раз метод отправки - и всё заработало..
Такое ощущение, что нужно было просто пересохранить настройки для отправки status_url...

У меня изначально $_REQUEST тоже стояло... Сейчас попробую поменять настройки.

последнее время либерти стало не стабильно работать и даже в новостях не пишут с чем это связанно какой то беспредел

тоже самое в поддержке не могут конкретно обьяснить с чем это связанно.

Первый момент.
Ни у кого нет проблемы с "дублями" платежей с либерти?
В API документации намекают, что 2 платежа с одним ИД не должны проходить
было попробовано <TransferRequest id="888">
и даже <TransferId>888</TransferId>
тем не менее платежи проходят и всё тут.
Где-то что-то не так поняли и не так сделали... или это бага? Суппорт молчит.
(та же проблема с перфектом, PAYMENT_ID пропускаются дубли, но там хотя бы по документации они и не должны фильтроваться).

Второй момент.
Есть жуткая задержка с получением истории по api, т.е. даже если платеж отправлен, ответ по какой-то причине не получен/не записан, то выдергивать историю имеет смысл только минут через 15, т.к. раньше данные могут просто не отдаваться. Это как-то решается? Где-то задокументировано?

Заранее спасибо за ответы.

p.s.: прикольный тут форум, да.

Несколько "встречных" вопросов:
1. Если вы читали в документации по API о id, то читали ли вы, что дубликатом считается запрос не только с тем же id, но и с идентическими другими параметрами запроса (такими как валюта, сумма, номер получателя и т.д). Тем более дубликаты ищутся за недавний период деятельности этого конкретного API (какой именно в документации правда не указано).
2.
TransferId это не уникальный идентификатор трансфера, это мерчант референс. Вот из документации цытата:
<TransferId>merchant reference</TransferId> <!-- not required -->
Merchant reference: Optional, additional identifying information that can be set by Merchant. Up to 20 characters long (varchar(20))
3. Вы на какой URL отправляете свои API запросы? Вся API документация написана для https://api2.libertyreserve.com.

1. А что значит дубли платежей ?
Вы делаете один перевод денег, а вместо одной операции проходит две ?
Такого быть не может...
2. Где Вы вычитали что параметр id в TransferRequest это уникальное значение и по нему чего-то там фильтруется ?
Параметр id - это текстовое значение длиной в 20 символов... (Line of text, up to 20 characters long (varchar(20)).
3. Кто и что должно фильтроваться что-то мне не совсем понятно...
У Liberty единственное уникальное значение - TransactionID, но Вы на него не влияете... Этот номер проставляется сервером Liberty при каждой транзакции.. Вот он уникальный... Не может быть 2-х операций с одинаковым TransactionID.
Этот номер возвращается Вам в ответном пакете на операцию Transfer, или в пакете запроса истории платежей.
А если Вы хотите для себя лично по какому-то другому полю фильтровать - то тут уж Вы сами должны следить за уникальностью...
Хотите использовать параметр id в TransferRequest - пожалуйста - сделайте этот параметр уникальным (например текущий timestamp), и следите за этим..
4. Насчет истории - тоже какую-то жуть Вы описываете...
Лично я с таким не сталкивался....
Сразу после получения ответа о транзакции - зачитываю историю - и всё нормально проходит...
Никаких 15 минут ждать не нужно...
Может Вы историю запрашиваете за год - и проблема в том что очень много данных и Вы их не дожидаетесь или еще чего-то в этом роде ?
Если так - то попробуйте запрашивать в истории последние 10 транзакций - и сервер такой запрос будет обрабатывать быстрее, и результирующий пакет будет намного меньше.

Подтверждаю, что сейчас у либерти всё работает тьху-тьху нормально.

Такую фильтрацию я вижу только у ЛикПей по параметру transaction_order_id если попытаться оплатить с transaction_order_id который уже был, получается ошибка "duplicate order id". У либерти и у перфекта я такого не видел.

"жуткая задержка" возможно происходит если Вы сразу после платежа идете в аккаунт Либерти и пытаетесь найти платеж, вот в аккаунте платежи могут появляться не сразу а с задержкой несколько минут, однако АПИ платеж видит сразу, как только Вы получили в ответном XML батч (lr_transfer)