BiTel

Имеем следующую конфигурацию модуля ПС

# ComePay
mps.2.mode=1
mps.2.title=ComePay
mps.2.protocol=comepay
mps.2.login=comepay
mps.2.passw=xxx
mps.2.pid=7
mps.2.comment=$contract_title ($contract_comment)
mps.2.cert=0
mps.2.search.mode=contract
mps.2.search.allow.contract.groups=1,10
mps.2.timeoffset=300

У тестировщиков ПС есть слудующие замечания



При указании отрицательной суммы на самом деле возвращается не некорректный XML, а вообще ничего не возвращается
operation=payment&id_payment=2062&account=10000000000001&sum=-10.0000&date=20110414174706

Ну и например для наглядности при запросе
operation=check&account=10000000000001&sum=10.0000
выводит



Чаво делать ?

Будут ли фиксы или комментарии по этому поводу? Или может есть у кого работающая схема с кампэй? в доке ничего особенного про них не обговорено.

Нужно описание протокола. Судя по всему что-то изменилось с момента поддержания.

Говорят что давно не меняли протокол, а про 4 знака после запятой что вообще с самого начала такое было. Протокол взаимодействия в приаттаченном файле.

Не совсем понятно: просто вывод должен быть в формате 10.0000, или должна быть поддержка платежей вида 10.0002.
Потому что последнее только один раз прописано в описании, а в примерах до двух знаков; и самое главное - биллинг не поддерживает платежи с точностью больше копейки.

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

Обновитесь.

Обновились.

На запрос
operation=payment&id_payment=2062&account=10000000000001&sum=-10.0000&date=20110414174706
выдает пустой ответ (нет XML), а должен выдать фатальную ошибку.

На запрос
operation=check&account=10000000000001&sum=10.0001
выдает все корректно, а на запрос
operation=check&account=10000000000001&sum=-10.0001
выводит


т.е. не выводит сумму и ошибку. таким образом остается проблема с обработкой ошибочного запроса с указанием отрицательной суммы. также если указать тип операции, например check1 - тоже выдает пустой ответ, при проведении платежа без указания какого-нибудь параметра (дата, ID, сумма, аккаунт) - тоже пустой ответ, а должна ошибка неправильного запроса вываливаться с кодом 508 + фатальность. получается механизм проверки корректности запроса не работает или отсутствует. Ладно про операции сказано что они check и payments, а вот про сумму сказано что это

но нет ясности про знак и в первом сообщении топика также процитировано сообщение сотрудника кампэй про запрос платежа с отрицательной суммой, а также в регламенте (пункты 2.2.5.1 и 2.2.7) описано про проведение проверки и обработку ошибок.

выше уже есть, но я все же добавлю свои 5 копеек еще один регламент, мало ли ...


пожалуйста, очень прошу, нет, умоляю, покажите бумажку монету достоинством в -10 (минус десять) рублей и, если Вас не затруднит, продемонстрируйте то, как Вы вставлете ее в терминал - страсть как хочется ЭТО увидеть

Это вопрос к ПС, они замечания выдали. Но из личных соображений скажу, что ПС - это не обязательно терминал, это процессинговый центр, через который могут проходить платежи как от своих и дилерских терминалов, так и прочих электронных систем (например девушка сидит и через компьютер заносит данные, принимая наличные, и ошиблась случайно, ввела не те или не полные данные. есть и другие примеры кроме терминалов), поэтому в любом случае, да еще и по регламенту, нужно корректно реагировать на любой запрос с выдачей необходимых кодов ошибок.

Я их (ПС) вовсе не защищаю, у них даже в регламенте про сумму говорят формат 19.4, а сами в примерах ответа пишут в формате хх.2, но сейчас не про это. Я всего лишь констатирую замечания тестировщиков ПС, а раз уж поддержка ПС Кампэй заявлена в биллинге, то поведение последнего должно соответствовать требованиям ПС.

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

делаем

Обновитесь.

Спасибо за оперативность, однако по регламенту (и тестировщики ПС опять завернули)



Пробую запрос на который получаю


А должен вывалить фатальную ошибку 501.

В ОСМП, ЕМНИМС, подобные тесты относились к дополнительным и никак не влияли на внедрение ПС в биллинг Были основные обязательные и дополнительные на которые я вообще забивал

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

т.е. на отрицательную, сумму не ругается? Проверю.

Причем тут ОСМП и ЕМНИМС, когда здесь Кампэй со своим уставом. У каждого своя логика.

Да, не ругается на отрицательную сумму при operation=check. При payment нормально отрабатывает, только при отсутствующем account тоже пустой резалт (что check, что payment), но тестировщики сказали что такого запроса в тестах и в работе нет, что они все с параметром account и на это можно в принципе забить, а можно и вывести ошибку, вот здесь уже на ваше усмотрение.

обновитесь.

Обновился. Опять незадача



делаю запрос без суммы
operation=check&account=10000000000001
получаю


А должен выдать ОК или договор не найден (если нет такого аккаунта)
Сделали одно, сломали другое. проверку суммы при check нужно только в том случае, если этот параметр присутствует в запросе (пункт регламента 2.3.2)

обновитесь

Обновился. Таможня дает добро! Всем спасибо за участие.

ОСМП - Объединенная Система Моментальных Платежей
Comepay работает через ОСМП
ЕМНИМС - Если Мне Не Изменяет Мой Склероз



бекпорт фиксов в 5.0 ждать?

Да неужто ? Это уже дилерство называется, тогда не было бы необходимости с ними проключаться, т.к. все платежи через ОСМП и шли бы. Кампэй - это отдельная контора (ПС) со своим процессинговым центром.

ОСМП в данном контексте - это не столько контора, сколько протокол [1, 2]

а надо?

учитывая то сколько тут народу сидит на 5.0 - однозначно, ДА! IMHO

завтра постараюсь сделать

спасибо!

Обновил 5.0

Выявил следующий момент: Если делать дублирущий платеж с таким же id_payment, то ошибку выдаст только в том случае, если дата идёт тем же месяцем что и уже успешно проведенный платеж. Если месяц или год поставить другой, то платеж проходит, хотя id_payment у ПС уникален глобально по времени. Видимо это из-за того, что проверка идет только по конкретной таблице месяца. Даже не знаю насколько это критично, думаю что не очень, т.к. как правило дублирование идёт с небольшим разрывом по времени из-за плохой связи, но так, на всякий случай на заметку разработчикам.