Pull to refresh

Comments 33

мы проводим всероссийский QIWI API Contest

Так как это конкурс, то какие призы?
Так неинтересно, вы заставляете меня регистрироваться на «каком-то» сервисе, у вас партнёрка с телеграмом? ))
Из всех чатиков в Telegram удобно отвечать оперативно на вопросы участников. Отправлять информацию, документацию необходимую — отработано на других конкурсах уже.
Подскажите пожалуйста — какие преимущества у киви-кошелька перед другими средствами пеевода денег (ну, кроме удобства незаконных переводов)?

Все их удобства перечеркивает непомерная жадность. Оплачивал ИВ онлайн виртуальной визой, сняли комиссию. На сколько мне известно это запрещено вроде визой. Да и вобще их комиссии иногда просто ставят в тупик. Пришлось перейти на сами знаете что) тем более пополнение с сбербанка без комисии.

QIWI Кошелек умеет быстро переводить деньги из разных форм в обе стороны — наличные, другие электронные кошельки, банковские карты, балансы номеров сотовой связи. Многие из этих функций уже доступны в API.

PS Переводы требуют идентификации по законодательству РФ
в пользовательском соглашении и не обеспеченным нашим саппортом

Позвольте, а как такие действия соотносятся со статьей 159 УК РФ?
Ведь, по сути(предпоследний абзац статьи), если деньги не ушли, а пришли, то мошенничество на лицо.
Я(пока) не смотрел API, но вы говорите о продолжении разработки оного. А это намекает и на действующие уязвимости(коли таковые существуют) и на возможные в будущем.
Вопрос далеко не праздный — я ваш клиент.
Да, вопрос серьезный. Давайте по порядку:

1. Пользовательским соглашением сервиса Visa QIWI Wallet не регулируется использование сторонних «API» QIWI Кошелька.
2. Более того, мы не рекомендуем вводить логин и пароль от QIWI Кошелька на любых сторонних ресурсах.
3. API Кошелька используется также на qiwi.com и проходит многоступенчатые проверки на безопасность.
4. Связь статьи УК РФ и планами по предоставлению аутентификации пользователей кошелька для третьих сторон не очень понятна. Было бы здорово, если вы написали подробнее о ваших сомнениях на api_help@qiwi.com — тогда мы сможем дать более содержательный ответ.

Обязательно попробуйте наш API и расскажите нам об этом.
Процесс получения токена API и самых методов, всё есть в документации developer.qiwi.com/qiwiwallet/qiwicom_ru.html

Qiwi, конечно, хороший сервис, меня всё устраивает в плане предоставляемых услуг. Но техподдержка и работа с пользователями вообще ужасная. И это отталкивает от использования сервиса.

Написал вам в личном сообщении, уточните, пожалуйста, в чем была проблема.
Вы пишите про OAuth 2.0 в разрезе аутентификации, но справедливости ради — это все-таки стандарт авторизации. Интересно узнать, что у вас отвечает за собственно аутентификацию?
И планируете ли вы уходить от SMS, как от одного из факторов аутентификации?
Строго говоря вы правы: RFC 6749 — это authorization framework.
Пока смс — наше всё, второй фактор, который рекомендован ЦБ.
Но поиск альтернатив ведётся.
Спасибо за ответ.
Было бы неплохо предоставлять пользователям возможность выбора второго фактора вместо СМС.
ЦБ, надеюсь, свои рекомендации пересмотрит, как их пересмотрел недавно NIST. Все таки украсть СМС уже не так дорого, а перевыпуск SIM вообще давно успешно практикуется.

Мы рады, что читатели Хабра поддерживают наше желание найти альтернативу смс.


По поводу дублирования сим-карт — у нас реализована проверка перевыпуска симки через механизм IMSI.

Альтернатива простая — OTP via FreeOTP, Google Authenticator и иже с ними.

Скажу честно, сейчас мы используем «старый API».
Мы разрабатываем софт, и даем нашим клиентам возможность получать информацию о входящих платежах и учитывать их в автоматическом режиме.
Скажу сразу, у нас есть поддержка и коммерческого варианта(через него выставляется счет). И причем часть людей(3% примерно) ушли на коммерческий вариант, после того как забрали возможность выставлять счета на обычном кошельке. Естественно счета выставлялись через «недокументированный» режим, и часть клиентов с 17 апреля начала горевать и с киви ушли(ну ничего страшного, бывает).

Новый API очень нравится, и будем переводить все на «новые рельсы», единственное, сразу могу сказать(а может и попросить от лица наших клиентов), что бы на просмотр истории токен мог выдаваться больше чем на 1 месяц. Потому что люди тёмные и не осведомленные в этом плане, но деньги на кошельках держат. А заходить к ним в кошелек и делать это каждый месяц самостоятельно нам не сильно хочется(сейчас они нам передают логин и пароль от кошелька и мы настраиваем все за них. Да, не все продвинутые, и многие боятся что то самостоятельно делать в кошельке).

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

Нам если честно не важно, пользуются ли они(наши клиенты) Вашим кошельком или нет. Просто небольшой комментарий.
Вы правы — 30 дней для токена это не очень долгий срок.
Но нельзя просто так взять и сделать бесконечные токены на старте, пока такое требование по безопасности. Мы обязательно найдём решение по увеличению времени жизни токена.
А ни кто не говорит про бесконечные. Это правильно что надо ограничивать. Но надо дать пользователю выбор. Или давать выбор на сколько месяцев(1,3 или 6 месяцев например). Раз в пол года сменить API токен никого не будет отягощать.
Т.е. человек выбирает разрешения и говорит срок. И что бы можно было бы создавать несколько токенов. Один для просмотра истории(на 6 месяцев), другой для оплаты с кошелька(на месяц) и т.д.
Идея с выбором срока жизни при создании токена интересная, мы ее изучим.

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

Направление называется «развитие открытых API», информации пока мало, но это всё официально объявлено на fintechru.org

В Европе процесс согласования общих стандартов для открытого банковского API занял больше 5 лет, надеюсь, в России мы справимся быстрее.

Киви Банк как участник ассоции Финтех будет поддерживать отраслевое решение, когда оно появится. А пока мы будем продолжать развивать отрытые методы работы API QIWI Кошелька.
Меня очень радует эта информация. Где-то с полгода назад я общался с рядом развитых в плане IT банков, которые мне задавали вопрос: а вам это зачем? И все объяснения, что мне это нужно для создания приложения, упрощающего жизнь клиентам более, чем одного банка, коим сам являюсь, совсем никак не приводили к пониманию. Надеюсь, что в ближайшее время будет серьезный прорыв. Еще раз моя благодарность!
Отображать в истории операций как успешные так и неуспешные платежи
Так сейчас и работает. Обращение к payment-history возвращает ровно то, что показывает сайт qiwi.com/payment/history

Если вы хотите, чтобы мы разобрали ваш случай детально — пришлите, пожалуйста, нам письмо api_help@qiwi.com с логом запроса.
В истории операций на сайте есть неуспешный входящий платеж. Через API его не видно

PS. историю операций на сайте использую старую qiwi.com/report.action
Очень рад, что наконец-то появился API. До этого приходилось парсить сайт и использовать недокументированный внутренний API, а это долго (много запросов) и не всегда стабильно (на последний запрос может прийти ошибка, а потом приходится проверять историю, чтобы узнать настоящий статус перевода). Вот только 1 месяц действия токена — слишком маленький срок.

Вопрос не по теме (по iShop). Есть ли возможность выставить счет пользователю, не спрашивая заранее номер телефона? Сейчас же крайне неудобно. Сейчас спрашиваем телефон, выставляем счет, направляем на сайт QIWI. А хотелось бы просто перенаправлять на QIWI, передавая сумму, номер счета и пр. в запросе (GET или POST), а там уже пользователь или сразу платит (если есть активная сессия), или вводит телефон, но уже на сайте QIWI.
в любом случае конечный статус платежа надо уточнять в истории операций

Мы сейчас переделываем протокол работы со счетами в ishop. Рекомендую зарегистрироваться на kassa.qiwi.com и ждать новостей про обновленный протокол.

Такая возможность есть в ishop в текущем протоколе. В обновленном протоколе, который мы представим в сентябре, все будет удобнее и это будет основной вариант интеграции. Если будут вопросы — обращайтесь.
добавьте, пожалуйста, в api получение банковской платежки (а не только квитанции), а то приходится это делать логином и подстановкой ссылок. и это не было бы проблемой, но при этом самое неприятное, что форма логина не видит подсовываемые ему имя пользователя и пароль и их приходится вводить вручную.
Да, кстати, в Internet Explorer 11 оплатить выписанные счета с недавних дней стало невозможно. При клике появляется окно с одной кнопкой «Перейти к оплате» и при нажатии на нее открывается новое окно с кнопкой «Перейти к оплате». И так далее. А движок IE широко используется в сторонних программах.

Надо заметить, что качество программирования сайта qiwi в последнее время стало создавать впечатление, что им занимаются гастарбайтеры. Все эти новации ради новаций написаны криво и часто приводят к неработоспособности сайта и к неудобству его использования.
Обычно такая ошибка возникает, когда запрещены куки или кто-то вроде adblock блокирует их установку. Буду рад увидеть скриншот/какие-то доп. данные, чтобы мы могли проверить ваш случай.
Sign up to leave a comment.