Как стать автором
Обновить

Комментарии 44

В стандарте ISO8601 разделители (кроме T) являются опциональными и могут быть редуцированы, т.о. валидным значением является и 1970-01-01T0000 и 19700101T0000. Так что для удобства я бы использовал полный формат и время без двоеточий:


  • 1970-01-01T00:00
  • 1970-01-01T0000

Так получится избежать URL-encoding, что будет удобным при ручном вводе.

Спасибо! Добавил вариант в голосование.
НЛО прилетело и опубликовало эту надпись здесь
Пятый вариант с «timestamp»?
НЛО прилетело и опубликовало эту надпись здесь
А вы собираетесь когда-нибудь передавать сумму списания денег с кошелька, если она проходит в валюте отличной от валюты баланса?

Например, у меня есть баланс в 100 EUR на кошельке, я по api делаю out транзакцию 100 RUB для пользователя. В результате я не знаю какую сумму в EUR вы снимаете c моего счета. Я знаю, что по вашим правилам это произойдет по курсу ЦБРФ+1%, но для нормальной сверки в режиме реального времени мне необходимо знать сколько конкретно денег в какой валюте вы с списываете с моего кошелька.

Почему так сложно в ответном запросе передавать сумму списания?
В ответном запросе — это в уведомлении вашего сервера или в запросе информации по счету?
Мы давно хотим внести ряд изменений в уведомление, но там считается подпись по всем полям и пока нет версионности в протоколе, поэтому сейчас, при изменении числа параметров, есть риск возникновения проблем у неопределенного числа партнеров. Есть желание добавить поддержку версий и сделать, в частности, возврат суммы списания, но это потребует усилий квалифицированных Java разработчиков, которых мало и мы ищем. :)
Да-да, ищем;) Описание одной из этих вакансий можно найти в Моем круге: https://moikrug.ru/vacancies/1000028469
Довольно тяжело читается, статья выглядит довольно сумбурно, будто бы её писали сразу несколько разных человек — маркетинг, пиар, безопасник, ПМ и разработчик:

Сначала начинаете за здаривие — мол меняется протокол, затем что-то про ПМов, разработчиков, верстальщиков и как сложно вытащить разработчика. Причем, от знания, что у вас есть Java-разработчики и Oracle-разработчики и что они делают — в статье никак это не пригождается. И никак к теме про новый протокол для партнера не относится…

Затем наконец-то самое интересное про протокол: вроде интересно, а потом возникает неизвестное слово «партнер» — кто такие партнеры. Сначало естественно кажется — это те, кто вложился с вами в бизнес, т.е. вроде как руководство Qiwi. Затем, думаешь что это какие-то рекламщики, развивающие киви, но тоже по контексту не подходит…
Только под конец понял, что «партнеры» для вас — это Юр.лица имеющие личный кабинет и продающие товары через интернет через QiWi. А для обычного читателя это так и останется непонятным (вы ведь на большую интернет-аудиторию сообщаете новость, а не просто на своём сайте, чисто для своих клиентов?).

> После недолгих обсуждений был выбран второй вариант
Честно. Пытался 5 раз найти этот самый «второй вариант». Не нашел, где вы упоминали «первый варианТ» и «второй вариант».

> т.к. многие до сих пор передают success_url без url кодирования
Я считаю, что раз партнеры настолько низкопрофильные, что не могут сделать urlencode, то требовать от них более сложных вещей, вроде времени по ISO 8601 — считаю слишком непосильной задачей. Предлагаю вам пойти навстречу чайникам, и разрешить им передавать в этом параметре несколько вариантов значений — в unixtime, либо в ISO 8601. Определить на стороне бэкэнда, что нам пришло — не такая уж непосильная задача, а для пользователя вы решите еще одну проблему с передачей времени. Ну и да, до int32 при unixtime(на старых системах) проработает до 2038года. К тому времени, можно будет и еще раз протокол обновить…
Статья при этом написана лучше, чем документация для разработчиков. Это понятно — техническому писателю в структуре процесса места попросту нет. Загадка в другом: что в этих текстах такого секретного, что скачать их можно только имея доступ к аккаунту магазина?
Видимо, чтобы было меньше скрипт-кидди, пытающихся «взломать» action-url, о котором здесь любезно рассказали.
Очень мало может вызвать доверия использование такой защиты. 9 из 10 платежных систем вешают ссылку на документацию не то, что на главной странице — на первом экране.
Без возможности настроить магазин, в большинстве случаев и документация бесполезна. Поэтому, увидев минимальное число скачиваний из неавторизованной зоны, просто убрали этот раздел. Планируем в этом году запустить портал на основе swagger, где будет и документация и интерактивные формы для выполнения запросы, которые решат проблему.
Довольно тяжело читается, статья выглядит довольно сумбурно, будто бы её писали сразу несколько разных человек — маркетинг, пиар, безопасник, ПМ и разработчик

Статью писал я и в разное время получил опыт в нескольких сферах. Маркетинг и pr, конечно, проверяли. Старался показать наиболее интересные вопросы, которые возникали в разное время, пока запускали проект, но видимо, получилось, действительно сумбурно.
Первый раздел отвечал на вопрос — почему думали 5 лет, а не сделали сразу.
Про партнеров: внутри они называются мерчантами, но это сленг. Более адекватных определений не нашли и в прошлой статье таких вопросов не возникало. Спасибо, дам определение.
Честно. Пытался 5 раз найти этот самый «второй вариант».

Первый вариант — доработка REST запроса. Самое начало главы.
Определить на стороне бэкэнда, что нам пришло — не такая уж непосильная задача

Спасибо. Хорошее предложение. Добавил в голосование.

Даже тут комиссию берете? :)
Ваша покупка 1.23
Сумма к оплате 1.24
В — внимательность! На pull протоколе никогда и нигде нет верхней комиссии при оплате с кошелька. Это единственный тестовый провайдер, где проверяется, что она теоретически может быть, т.к. это заложено в интеграционные тесты. :)
Документация доступна только из личного кабинета — это очень удобно (особенно с учетом того, что старые аккаунты вы отключили).
Что со сроком жизни «устаревших» протоколов? Отключите или будете поддерживать?
И баг-репорт: научите разработчиков корректно обрабатывать кавычки (и прочие символы) в поле комментария к счету
1) Какую документацию предоставить? Аккаунты на вход блокируются только службой антифрода и крайне редко. Старые аккаунты мы массово не отключали.
2) SOAP и REST протоколы будут поддерживаться и дальше. Описанное в статье расширение протокола HTTP это лишь приятное дополнение к одному из них, т.к. оповещение оповещение об оплате счета в любом случае должно прийти на сервер.
3) Спасибо, воспроизведем и поправим.
1. Собственно
Скриншот
image
страница идентификации, видимо, уже не существует — предлагает регистрироваться заново. Документацию на обновленный протокол — кулуарность подобной документации никогда не была понятна. Тем более вы хотите критики.
2. Хотелось бы верить, а то ряд платежных шлюзов забывает не только о поддержке, но и об уведомлениях перед прекращением поддержки.
1. Для доступа к именному кошельку требуется получить упрощенную идентификацию на qiwi.com для связанного с ним номера телефона. После этого вы сможете войти в ishop.
2. Мы до сих пор поддеживаем url для выставления счета, которые были сделаны в 2008 году. :) Исключение — вынужденное отключение XML протокола год назад, т.к. по нему участился фрод, а сам протокол был закрыт для новых подключений более 4 лет.
Оно мне предлагает регистрироваться заново (или это ошибка «перевода»?), а не восстанавливать доступ, имхо, это существенная разница. (предполагаю, что связанные с аккаунтом тестовые магазины так же канули в лету)
Ошибка перевода. А чем переводите? Достаточно зайти на qiwi.com с номера +7916***49 и идентифицироваться в настройках профиля. Все ваши тестовые проекты будут доступны.
Собственно, перевожу с русского на русский глазами. Как я понимаю, qiwi кошелек был удален, поэтому лишь один вариант — регистрация как нового пользователя, но вот связь (вероятно, по номеру телефона) с тестовыми магазинами осталась, для оживления доступа к которым пришлось таки ввести паспортные данные (внутренний параноик в ужасе и заранее думает о способах удаления/закрытия аккаунта).
Именной кошелек — это кошелек физического лица. Переводы между физическими лицами должны быть идентифицированы, согласно закону, который был принят в 2014 году. Поэтому для продолжения работы, к сожалению, вы обязаны указать свои данные в личном кабинете. Идентификацию привязанного кошелька можно провести по ссылке после авторизации.
Вы до сих пор не показываете лимиты на операции. Это невозможно ж пользоваться!
Показывает, лимит «250000 руб», пытаюсь оплатить 30к — говорит «превышен лимит».
И так и сяк, и да пошли вы, выкрутился иначе.
Спасибо. Ошибка достаточно редкая. Не думали, что она доставляет такие проблемы. Постараемся что-нибудь придумать с командой UX, т.к. для большинства пользователей эта информация не нужна.
Критика:
  • Формат номера телефона: Телефон в формате 71231234567. Необязательный параметр, в остальных местах строго с + (если быть совсем точным, то tel:+71231234567). Еще один вариант передачи или наоборот послабление в строгости формата?
  • Валидация формы не полная: получаем Ошибка в параметрах запроса без уточнения, что сумма со многими нулями не по зубам (и ограничение на прием платежей более 15к уже не действует?), что валюты с переданным кодом не существует и т.п. (видимо предварительная проверка формы )
  • Ну и несколько раз получил Оу! Сервер барахлит. Обновите страницу с кодом 403.
  • Формат номера оставили тот, который использовался ранее в протоколе HTTP без подписи. С плюсом номер передается в REST протоколе.
  • Валидацию расширим, спасибо. Ограничение на платежи больше 15 000 сняли для большинства провайдеров. В этом месяце снимаем для всех, кроме именных кошельков, поднимая лимит на выставление счета до 250 000 р.
  • Хм. Такая ошибка выдается при отсутствии связи с сервером. Обратим внимание, спасибо. Мы сейчас налаживаем мониторинг ошибок на стороне клиента. Это одна из новых ошибок, которая раньше обрабатывалась некорректно.

Еще добавлю про $API_PWD. Вообще-то 2016 год, криптоалгоритмы расписаны и разжеваны, ваш алгоритм верификации из 2012. На секундочку – вы финансовый проект, для которого безопасность на первом месте. Пора взрослеть и переходить на подпись транзакций.

Подписи на основе сертификатов у нас используется в нестандартных api для крупных партнеров. По опыту могу сказать, что это всегда пляски с интеграцией, поэтому для массового api решили использовать простое для реализации, но защищенное решение. Вы не могли бы привести примеры других публичных API, которые уже перешли массово на подпись с сертификатами?

p.s. Больше всего за опыт интеграции я был удивлен, когда европейским партнерам пришлось кидать ссылку на wiki про url encoding… Индусы на аутсорсе не вызывали удивление с таким же непониманием.

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


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

Я конечно все понимаю, вы крупная финансовая компания, и PHP не ваш конек, но блин, оформите хотя-бы PHP код как следует в статье.
К сожалению, PHP разработчиков у нас нет, да. Код писал я для примера, т.к. это наиболее наглядный способ описания. Понимаю, что PHP ушел далеко вперед с 2010 года, когда я им занимался. не могли бы вы уточнить что предлагаете сделать, либо кинуть примером правильно оформленного кода?
Переименова переменные, немного подправил код стайл, немного поменял логику, а вообще конечно лучше выкатить нормальную библиотеку для работы с АПИ
// ID проекта, API_ID, API пароль получаются в настройках по url: https://ishop.qiwi.com/options/rest.action
$shopId = '260***';
$apiKey = '4683****';
$apiPassword = '1T1ea7****';

$CCY = 'RUB';
$amount = 1.12;

// Телефон в формате 71231234567. Необязательный параметр
$phone = null;
// ID транзакции
$txnId = 'habr'.random_int(1,90000);


$params = [$apiKey, $CCY, $shopId, $amount, $txnId];
if (null !== $phone) {
    $params = [$apiKey, $CCY, $shopId, $amount, $phone, $txnId];
}

// Добавляем в параметры секретный ключ
$params[] = md5($apiKey);

// Формируем строку из параметров с разделителем "|"
$paramsStr = implode('|', $params);

// Вычисляем хеш
$signature = hash('sha512', $paramsStr);

// Формируем query стринг
$query = http_build_query([
    'from' => $shopId,
    'to' => $phone,
    'txn_id' => $txnId,
    'summ' => $amount,
    'api_id' => $apiKey,
    'ccy' => $CCY,
    'signature' => $signature
]);

// Собираем итоговый url для клиента
$url = 'https://bill.qiwi.com/order/external/create.action?'.$query;

P.S. Ну и странное же у вас API, как будто не новое, а старое.
Спасибо! Обновил пример. Правда, вместо random_int оставил rand, т.к. random_int появился только в php 7, а пятая версия, как понимаю, все еще очень популярна.
Лучше выкатить нормальную библиотеку для работы с АПИ

Полностью согласен. Давно над SDK думали, но без обновления ishop.qiwi.com они были почти бессмысленны. Теперь, после доработок API и начала работ над новым ishop, есть желание вернуться к этой теме и заказать разработку open source SDK и плагинов для популярных платформ для REST API. Есть желание поучаствовать?
Ну и странное же у вас API, как будто не новое, а старое.

Для получения обратной связи и написал статью. :) Есть предложения по улучшению?

Ну как минимум делать сигнатуру используя тот же query формат, и ключи в алфавитном порядке, поменять summ на amount, также желательно переименовать id и password в client_id и client_secret.
Зачем тут md5 для ключа не понятно, он нигде не светится.
Зачем shopId тоже не понятно, для разных магазинов, разные client_id и client_secret должны быть.
Где returnUrl задается тоже не вижу, хотя во всех платежках с которыми я работал, он был, а часто их было даже два.
Также рекомендую использовать ключ currency вместо CCY. PayPal и Stripe используют его.

Можно попробовать написать драймер к omnipay, там все достаточно просто и легко.
Unixtime религия не позволяет?
timestamp есть в вариантах голосования.
А, ок. Просто timestamp не всегда имеет формат unixtime. К примеру, в MySQL он имеет иной формат.
[offtop]Вы бы лучше разобрались со своей дурацкой системой безопасности по отношению к пользователям стран в которых имеются предоплаченные номера. Я с Украины и мне заблокировали кошелёк и потребовали договор с оператором — которого у меня нет, и быть не может. Хорошо что там денег не много на кошельке оставалось.[offtop]

А вот «текущее состояние страницы оплаты» — ужасное.
Нет никакой информации по тому что это вообще за страница — и для чего она, просто просит ввести номер телефона и комментарий, и после этого сразу высылает сообщение с кодом.
Спасибо, страницу с вводом номера телефона на стороне Qiwi причешем, добавив данные о платеже. Для получения отзывов и выкладывали. Жаль, что пасхалка ко дню разработчика исчезла. Сейчас клиент в магазинах выбирает Qiwi, вводит номер телефона и попадает сразу на смс авторизацию.
Пожелание. Хотелось бы иметь доступ к API без оформления юридического лица. Хотя бы с крошечными лимитами, но пусть будет. Чтобы была возможность протестировать жизнеспособность проекта без всей этой бумажной волокиты. Как пример XML интерфейс у Webmoney.
Сейчас, с небольшой, но волокитой, но это возможно сделать, зарегистрировавшись как именной кошелек. Делаем все возможное, чтобы существенно упростить и полностью автоматизировать механику уже в этом году.
Тестировал сервис (через заревершеный HTTP), но мой кошелек заблокировали. После конечно разблокировали, но с формулировкой
Обращаем Ваше внимание, что выставление счетов другим пользователям является нарушением договора оферты.

В противном случае Ваш Visa QIWI Wallet будет вновь заблокирован.

Просим обратить внимание на то, что Пользователь не вправе использовать Сервис, включая услугу Именной кошелёк, для совершения операций, направленных на систематическое извлечение прибыли.
Для дальнейшего использования Visa QIWI Wallet в коммерческих целях необходимо пройти регистрацию в iShop (https://ishop.qiwi.com).
В противном случае Ваш Visa QIWI Wallet будет вновь заблокирован.


Так, что не уверен насчёт Именного кошелька. Но всё равно спасибо за ответ.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий