Комментарии 37
НЛО прилетело и опубликовало эту надпись здесь
Добрый день. Пока не планировали в массовом API, т.к. не было запросов. У нас есть похожий сервис безопасная сделка, но он для крупных компаний. Почему максимальный срок в 1 год обрезает варианты использования? Он кажется более чем длинным.
НЛО прилетело и опубликовало эту надпись здесь
Мой опыт говорит, что описанный кейс очень граничный и не стоит на него ориентироваться. В новых рынках лучше быстрее построить систему и посмотреть, чем пытаться построить идеал, который никому окажется не нужен. Сейчас такие ситуации успешно разрешают арбитражем, который и так потребуется. В подвешенных переводах без срока действия есть множество и юридических и технических ограничений. Я не стал ориентироваться на то, что они быстро развяжутся.
Если блокировка бесконечная — заказчику никакого смысла обманывать нет, он 1000 долларов все равно никогда не получит обратно
Вам не знакома концепция «сдохни ты сегодня, а я завтра»? Или анекдот на ту же тему? Или фраза «так не доставайся же ты никому!»?
А применительно к более-менее реальной жизни, может быть такой кейс: заказчик захотел сверх оговоренного объема работ еще хотелок, потом еще, потом исполнитель вспылил, уперся, потребовал PIN. Заказчик, желая «наказать», PIN не отдает. При этом для исполнителя эта 1000 достаточно существенна, а заказчику, в общем-то, плевать.
НЛО прилетело и опубликовало эту надпись здесь
А лимиты есть какие-нибудь по сумме или прочие ограничения?
постарались сделать процесс безопасным, быстрым и удобным […] хотим снять рискиКак-то хотелось бы от компании, которой доверяются деньги, слышать «сделали» вместо «постарались сделать» и «сняли» вместо «хотим снять» ;)
У нас одна из лучших команд по безопасности в России и открытая bug bounty программа, но, по честному, абсолютно безопасных систем не бывает. Часто задача в том, чтобы цена и сложность атаки превышала любые выгоды. На p2p.qiwi.com мы сделали многое, чтобы номер телефона получателя не раскрывался. Это значительно затруднит, например, восстановление симки злоумышленниками для целевых атак на крупных клиентов.
Язык формы всегда русский, не зависит от языка браузера и ip :(
через неделю, 18 апреля
Вроде бы, 18 апреля послезавтра :)
И вопрос по теме: допустим, у меня есть некий товар, который не размещён ни в каком интернет-магазине или вроде того.
Получить доступ на «виджет» с переводом может любой человек из абсолютно разных мест (личка/группа в соцсетях).
Как мне в этом случае распознать пользователя?
Для меня было бы удобнее, чтобы помимо суммы, в виджете можно было указать комментарий.
Ошибки парсинга и т.д. можно взять на себя.
Допустим, покупка товара в группе ВК.
Пользователь переходит по ссылке из паблика, переводит с банковской карты, в комментарии оставляет ссылку на свою страницу или свой айдишник, а я уже выстраиваю свою логику вокруг этого.
Сейчас же этого никак не достичь? Ни условными utm-метками или чем-то вроде того?
И об отправителе я узнаю только его номер телефона qiwi или номер карты?
Что посоветуете здесь, или подобный сценарий запрещён вообще?
>Вроде бы, 18 апреля послезавтра :)
Статья готовилась чуть дольше. :) Спасибо, что внимательно прочитали.
Виджет для переводов предназначен больше для пожертвований. Мы запустим до конца апреля поддержку доп. параметров для my.qiwi.com, но в целом для этого есть полноценное api. Можно передать любые параметры в customFields, либо при выставлении счета через oplata.qiwi.com, либо в серверном API. Они вернутся при оповещении о оплате.
Статья готовилась чуть дольше. :) Спасибо, что внимательно прочитали.
Виджет для переводов предназначен больше для пожертвований. Мы запустим до конца апреля поддержку доп. параметров для my.qiwi.com, но в целом для этого есть полноценное api. Можно передать любые параметры в customFields, либо при выставлении счета через oplata.qiwi.com, либо в серверном API. Они вернутся при оповещении о оплате.
Я по доке понял сразу примерно, что если я буду выдавать ссылку где-то у себя на сайте или в приложении, в общем, в любом месте, подконтрольным мне — я могу сделать то, что хотел.
Но как быть со статичной ссылкой, размещаемой публично, которую я уже подменить не могу, и где мне нужно идентифицировать отправителя?
При пожертвованиях это не необходимо, да, но в других целях понадобится вполне (незря мне сразу в голову это пришло).
Можете примерно предсказать, в каком виде эта поддержка планируется быть реализована в апреле?
Я сейчас подумал, что даже utm-метки и прочие query-параметры не помогут.
Если эту ссылку, как было упомянуто в прошлом комментарии, разместить в группе в соцсети, юзеры будут разные, а ссылка одна. В итоге идентифицировать их не получится.
Мне кажется, с вашей стороны, дабы не думать о проблемах юзеров вашего апи, проще всего добавить поле в форму для пользователя.
При тех же донатах будет полезно — можно будет аналог donationalerts делать на основе вашего апи.
Но как быть со статичной ссылкой, размещаемой публично, которую я уже подменить не могу, и где мне нужно идентифицировать отправителя?
При пожертвованиях это не необходимо, да, но в других целях понадобится вполне (незря мне сразу в голову это пришло).
Можете примерно предсказать, в каком виде эта поддержка планируется быть реализована в апреле?
Я сейчас подумал, что даже utm-метки и прочие query-параметры не помогут.
Если эту ссылку, как было упомянуто в прошлом комментарии, разместить в группе в соцсети, юзеры будут разные, а ссылка одна. В итоге идентифицировать их не получится.
Мне кажется, с вашей стороны, дабы не думать о проблемах юзеров вашего апи, проще всего добавить поле в форму для пользователя.
При тех же донатах будет полезно — можно будет аналог donationalerts делать на основе вашего апи.
Понял кейс, да, наборная форма из нужных полей тоже есть в беклоге сразу после полноценного запуска для самозанятых. :)
Круто, я законтрибьютил, почти что.
Если добавите какой-то конструктор форм с user-defined форматом и возможностью какую-нибудь регулярку навесить на поле, будет вообще отлично.
Добавлять эту возможность к полю комментария, наверное, будет лишним — но если дать возможность (опционально) добавлять поле комментария, И поле со своим названием и форматом — вот это будет круто.
Для тех же ссылок с соцсетей будет круто — либо ограничить ввод только цифрами и определённой длиной; либо строчкой по регулярке вроде `^https://vk.com/.+`.
Если добавите какой-то конструктор форм с user-defined форматом и возможностью какую-нибудь регулярку навесить на поле, будет вообще отлично.
Добавлять эту возможность к полю комментария, наверное, будет лишним — но если дать возможность (опционально) добавлять поле комментария, И поле со своим названием и форматом — вот это будет круто.
Для тех же ссылок с соцсетей будет круто — либо ограничить ввод только цифрами и определённой длиной; либо строчкой по регулярке вроде `^https://vk.com/.+`.
Ах, да — проверкой валидности введённого в поле значение должен бэкенд заниматься (ваш). Потому что кулхацкеры, меняющие код элемента, не дремлют. И поля, соответственно, должны быть обязательными (по выбору владельца формы)
Этим сервисом можно пользоваться физ. лицам для личных нужд или это именно для налоговой?
Оплатить можно только российской картой? Или другие страны тоже принимаются?
Оплатить можно только российской картой? Или другие страны тоже принимаются?
Сервис открыт для всех. Регистрация самозанятых сделана отдельным разделом и находится на финальной стадии разработки. Открыт прием карт из стран СНГ. Мы внимательно анализируем статистику оплат и, если потребуется, будем постепенно открывать новые.
При выставлении счета через API какой смысл указывать customer.phone? На что он влияет? Вроде бы счет в кабинете не появляется, пользователю всё равно приходится вводить в вашей форме свой номер телефона (для входа).
Можно в payUrl передать параметр paySource=qw https://developer.qiwi.com/ru/bill-payments/
GEG, подскажите, пожалуйста, а возможно ли как-то идентифицировать плательщика? Раньше в ishop счет выставлялся на конкретный номер телефона, с него счет оплачивался, этот же номер передавался в уведомлении на сервер. Теперь же никак нельзя сопоставить поступившую оплату с номером телефона? При создании счета можно указать customer.phone, но он по сути ничем не отличается от произвольных полей customFields? Т. е. ни на что не влияет (оплачивать можно чем угодно) и просто передается обратно «как есть»?
В истории платежей в кабинете qiwi видно замаскированный номер телефона. Не планируете ли передавать его через API в уведомлении?
В истории платежей в кабинете qiwi видно замаскированный номер телефона. Не планируете ли передавать его через API в уведомлении?
Теперь клиент может оплатить любым способом оплаты, не вводя номер телефона. Т.е. с карты, qiwi или мобильной коммерции. Поэтому мы сделали поддержку передачи любых данных в customFields и account. Можете описать какой-то кейс, когда нужны доп. данные? Хеш от номера карты\номера телефона подошел бы?
Основной кейс — борьба с мошенничеством, с отмыванием средств и пр. Когда можно сопоставить, что это и это скорее всего оплатил один человек. Создать аккаунт на сайте и подменить IP просто, а получить новую SIM-карту и оформить новый кошелек — намного сложнее. В общем, очень хотелось бы получать какую-то информацию о пользователе. Если говорить о конфиденциальности, то в кабинете (в истории) всё равно отображается телефон, где некоторые цифры скрыты звездочками. Хотя бы это передавалось бы в уведомлении — уже было бы здорово. Хеш — тоже хорошо, в некотором смысле даже лучше звездочек (не будет ложных пересечений). Но хеш мешает другому кейсу (намного менее важному) — иногда при утере аккаунта или подозрении на взлом спрашиваем старые платежные реквизиты (номер телефона в случае qiwi).
И все-таки в документации, похоже, ошибка.
developer.qiwi.com/ru/bill-payments/#notification
Если customer при выставлении счета не передавать, то в уведомлении приходит customer.phone, соответствующий телефону плательщика.
developer.qiwi.com/ru/bill-payments/#notification
customer.phone — Номер телефона, на который был выставлен счет (если был указан при выставлении счета)
Если customer при выставлении счета не передавать, то в уведомлении приходит customer.phone, соответствующий телефону плательщика.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Открываем API для приема p2p-переводов