Комментарии 44
В стандарте ISO8601 разделители (кроме T) являются опциональными и могут быть редуцированы, т.о. валидным значением является и 1970-01-01T0000
и 19700101T0000
. Так что для удобства я бы использовал полный формат и время без двоеточий:
1970-01-01T00:00
1970-01-01T0000
Так получится избежать URL-encoding, что будет удобным при ручном вводе.
Например, у меня есть баланс в 100 EUR на кошельке, я по api делаю out транзакцию 100 RUB для пользователя. В результате я не знаю какую сумму в EUR вы снимаете c моего счета. Я знаю, что по вашим правилам это произойдет по курсу ЦБРФ+1%, но для нормальной сверки в режиме реального времени мне необходимо знать сколько конкретно денег в какой валюте вы с списываете с моего кошелька.
Почему так сложно в ответном запросе передавать сумму списания?
Мы давно хотим внести ряд изменений в уведомление, но там считается подпись по всем полям и пока нет версионности в протоколе, поэтому сейчас, при изменении числа параметров, есть риск возникновения проблем у неопределенного числа партнеров. Есть желание добавить поддержку версий и сделать, в частности, возврат суммы списания, но это потребует усилий квалифицированных Java разработчиков, которых мало и мы ищем. :)
Сначала начинаете за здаривие — мол меняется протокол, затем что-то про ПМов, разработчиков, верстальщиков и как сложно вытащить разработчика. Причем, от знания, что у вас есть Java-разработчики и Oracle-разработчики и что они делают — в статье никак это не пригождается. И никак к теме про новый протокол для партнера не относится…
Затем наконец-то самое интересное про протокол: вроде интересно, а потом возникает неизвестное слово «партнер» — кто такие партнеры. Сначало естественно кажется — это те, кто вложился с вами в бизнес, т.е. вроде как руководство Qiwi. Затем, думаешь что это какие-то рекламщики, развивающие киви, но тоже по контексту не подходит…
Только под конец понял, что «партнеры» для вас — это Юр.лица имеющие личный кабинет и продающие товары через интернет через QiWi. А для обычного читателя это так и останется непонятным (вы ведь на большую интернет-аудиторию сообщаете новость, а не просто на своём сайте, чисто для своих клиентов?).
> После недолгих обсуждений был выбран второй вариант
Честно. Пытался 5 раз найти этот самый «второй вариант». Не нашел, где вы упоминали «первый варианТ» и «второй вариант».
> т.к. многие до сих пор передают success_url без url кодирования
Я считаю, что раз партнеры настолько низкопрофильные, что не могут сделать urlencode, то требовать от них более сложных вещей, вроде времени по ISO 8601 — считаю слишком непосильной задачей. Предлагаю вам пойти навстречу чайникам, и разрешить им передавать в этом параметре несколько вариантов значений — в unixtime, либо в ISO 8601. Определить на стороне бэкэнда, что нам пришло — не такая уж непосильная задача, а для пользователя вы решите еще одну проблему с передачей времени. Ну и да, до int32 при unixtime(на старых системах) проработает до 2038года. К тому времени, можно будет и еще раз протокол обновить…
Довольно тяжело читается, статья выглядит довольно сумбурно, будто бы её писали сразу несколько разных человек — маркетинг, пиар, безопасник, ПМ и разработчик
Статью писал я и в разное время получил опыт в нескольких сферах. Маркетинг и pr, конечно, проверяли. Старался показать наиболее интересные вопросы, которые возникали в разное время, пока запускали проект, но видимо, получилось, действительно сумбурно.
Первый раздел отвечал на вопрос — почему думали 5 лет, а не сделали сразу.
Про партнеров: внутри они называются мерчантами, но это сленг. Более адекватных определений не нашли и в прошлой статье таких вопросов не возникало. Спасибо, дам определение.
Честно. Пытался 5 раз найти этот самый «второй вариант».
Первый вариант — доработка REST запроса. Самое начало главы.
Определить на стороне бэкэнда, что нам пришло — не такая уж непосильная задача
Спасибо. Хорошее предложение. Добавил в голосование.
Ваша покупка 1.23
Сумма к оплате 1.24
Что со сроком жизни «устаревших» протоколов? Отключите или будете поддерживать?
И баг-репорт: научите разработчиков корректно обрабатывать кавычки (и прочие символы) в поле комментария к счету
2) SOAP и REST протоколы будут поддерживаться и дальше. Описанное в статье расширение протокола HTTP это лишь приятное дополнение к одному из них, т.к. оповещение оповещение об оплате счета в любом случае должно прийти на сервер.
3) Спасибо, воспроизведем и поправим.
2. Хотелось бы верить, а то ряд платежных шлюзов забывает не только о поддержке, но и об уведомлениях перед прекращением поддержки.
2. Мы до сих пор поддеживаем url для выставления счета, которые были сделаны в 2008 году. :) Исключение — вынужденное отключение XML протокола год назад, т.к. по нему участился фрод, а сам протокол был закрыт для новых подключений более 4 лет.
Показывает, лимит «250000 руб», пытаюсь оплатить 30к — говорит «превышен лимит».
И так и сяк, и да пошли вы, выкрутился иначе.
- Формат номера телефона: Телефон в формате 71231234567. Необязательный параметр, в остальных местах строго с + (если быть совсем точным, то tel:+71231234567). Еще один вариант передачи или наоборот послабление в строгости формата?
- Валидация формы не полная: получаем Ошибка в параметрах запроса без уточнения, что сумма со многими нулями не по зубам (и ограничение на прием платежей более 15к уже не действует?), что валюты с переданным кодом не существует и т.п. (видимо предварительная проверка формы )
- Ну и несколько раз получил Оу! Сервер барахлит. Обновите страницу с кодом 403.
- Формат номера оставили тот, который использовался ранее в протоколе HTTP без подписи. С плюсом номер передается в REST протоколе.
- Валидацию расширим, спасибо. Ограничение на платежи больше 15 000 сняли для большинства провайдеров. В этом месяце снимаем для всех, кроме именных кошельков, поднимая лимит на выставление счета до 250 000 р.
- Хм. Такая ошибка выдается при отсутствии связи с сервером. Обратим внимание, спасибо. Мы сейчас налаживаем мониторинг ошибок на стороне клиента. Это одна из новых ошибок, которая раньше обрабатывалась некорректно.
Еще добавлю про $API_PWD. Вообще-то 2016 год, криптоалгоритмы расписаны и разжеваны, ваш алгоритм верификации из 2012. На секундочку – вы финансовый проект, для которого безопасность на первом месте. Пора взрослеть и переходить на подпись транзакций.
p.s. Больше всего за опыт интеграции я был удивлен, когда европейским партнерам пришлось кидать ссылку на wiki про url encoding… Индусы на аутсорсе не вызывали удивление с таким же непониманием.
Массово: все крипто-валюты, крипто-биржи и т.п. Но продукт, который перешел бы на подписи не назову. Это дает вам дополнительное конкурентное преимущество на ровном месте. Стоимость перехода на подписи не так велика, как кажется. Посудите сами весь алгоритм цифровой подписи включает один дополнительный вызов содержащий два параметра: хэш данных запроса и секретный ключ.
А для преодоления трудностей в интеграции я бы советовал разработать SDK для самых популярных платформ, все-таки низкий порог вхождения – в ваших же интересах. Так же не лишним было бы сделать песочницу, чтобы наглядно продемонстрировать механизм работы.
// 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, как будто не новое, а старое.
Лучше выкатить нормальную библиотеку для работы с АПИ
Полностью согласен. Давно над SDK думали, но без обновления ishop.qiwi.com они были почти бессмысленны. Теперь, после доработок API и начала работ над новым ishop, есть желание вернуться к этой теме и заказать разработку open source SDK и плагинов для популярных платформ для REST API. Есть желание поучаствовать?
Ну и странное же у вас API, как будто не новое, а старое.
Для получения обратной связи и написал статью. :) Есть предложения по улучшению?
Зачем тут md5 для ключа не понятно, он нигде не светится.
Зачем shopId тоже не понятно, для разных магазинов, разные client_id и client_secret должны быть.
Где returnUrl задается тоже не вижу, хотя во всех платежках с которыми я работал, он был, а часто их было даже два.
Также рекомендую использовать ключ currency вместо CCY. PayPal и Stripe используют его.
Можно попробовать написать драймер к omnipay, там все достаточно просто и легко.
А вот «текущее состояние страницы оплаты» — ужасное.
Нет никакой информации по тому что это вообще за страница — и для чего она, просто просит ввести номер телефона и комментарий, и после этого сразу высылает сообщение с кодом.
Обращаем Ваше внимание, что выставление счетов другим пользователям является нарушением договора оферты.
В противном случае Ваш Visa QIWI Wallet будет вновь заблокирован.
Просим обратить внимание на то, что Пользователь не вправе использовать Сервис, включая услугу Именной кошелёк, для совершения операций, направленных на систематическое извлечение прибыли.
Для дальнейшего использования Visa QIWI Wallet в коммерческих целях необходимо пройти регистрацию в iShop (https://ishop.qiwi.com).
В противном случае Ваш Visa QIWI Wallet будет вновь заблокирован.
Так, что не уверен насчёт Именного кошелька. Но всё равно спасибо за ответ.
Извините, мы обновляем протокол