Открываем API для приема p2p-переводов

    Привет!

    Мы тут в QIWI открыли API приема переводов. Новый сервис должен решить сразу несколько проблем для тех, кто часто посылает (а особенно — получает) деньги именно посредством p2p-перевода. Во-первых, мы открыли возможности, ранее доступные только для бизнеса, и постарались сделать процесс безопасным, быстрым и удобным, а во-вторых, хотим снять риски вида «Мне тут за работу заплатили и банк счет поблочил».


    Зачем все это вообще и как именно мы это сделали, а еще про возможность получить от нас до 3 миллионов рублей в рамках QIWI Universe — под катом.

    Почему p2p-переводы важны


    Люди часто кидают друг другу деньги с помощью переводов с карты на карту или по номеру телефона — суть одна, это прямой платеж от одного физлица другому. Это может быть возврат денег, если вы купили другу кофе, когда у него с собой не было денег (или желания платить за кофе), это может быть открытый сбор средств на что-нибудь, это может быть какой-то киоск с мороженым или тем же кофе в парке, где продавец принимает только наличку, но есть возможность и «кинуть на сбер».

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

    Обсуждать это дело мы не будем, мы решили просто придумать альтернативу.

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

    В том году мы создали универсальный протокол для приема средств, который успешно объединил в себе все доступные способы оплаты — эквайринг-кошелек, банковские карты, мобильную коммерцию, рассрочку по Совести, я писал о нем вот тут. Конечно, для него сделали SDK и поддержку в разных CMS. Поэтому в решении для примера p2p переводов решили использовать именно его. Такой подход позволит клиенту без технологических изменений идти от редких переводов и самозанятости к своей фирме.

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



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

    Посмотрели глубже, как пользователи взаимодействуют с формой. Поняли, что человеку все же важно при переводе видеть в форме, кому именно он переводит деньги (люди привыкли переводить по номеру телефону или ФИО из контактов в смартфоне). Но показывать фамилию целиком на публичной форме — так себе затея, поэтому мы показываем имя и первую букву фамилии.

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

    А теперь получается, что перевод осуществляется либо по короткой ссылке, либо с виджета на сайта, либо с QR-кода.

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

    На чем все крутится


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

    Все это можно посмотреть в работе на p2p.qiwi.com

    При входе с помощью кошелька вам станет доступна персональная короткая ссылка. Например, my.qiwi.com/gkonnov. Её удобно как пересылать в сообщении, так и, например, сделать QR код. Форма хорошо адаптируется к мобильным устройствам, поэтому конверсия будет хорошей. Еще появятся персональные виджеты на выбор (widget.qiwi.com/gkonnov). Их сделали для сайтов и блогов. На виджетах и форме можно кастомизировать по желанию, чтобы они соответствовали оформлению вашего сайта или бренда. Это все было в возможностях для большого бизнеса и крупных магазинов — мы перенесли все и на пользователей.



    А еще появилась возможность выставлять счет за оказанные услуги. Сделали вы кому-то сайт и хотите принять средства за работу — вбиваете нужную сумму, формируете ссылку на счет, пересылаете ее заказчику. Заказчик переходит по ней и понимает, кому переводит и за что.

    Т.к. под капотом полноценное API — есть возможность создавать ключи, настраивать необходимые уведомления, подключать это к своему интернет-магазину на Wordpress и других CMS, все работает.

    Так, а что у вас про самозанятых?


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

    Да, в целом, ничего не мешает использовать p2p.qiwi.com уже сейчас и, если вы самозанятый, регистрировать доход в сервисе “Мой налог”, но прямо сейчас мы активно взаимодействуем с ФНС и интегрируем их API, что позволит и регистрировать самозанятых, и вести учет их деятельности. В общем, человек получит коробочное решение, которое должно будет закрыть все его потребности как самозанятого.

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

    Поэтому кроме p2p.qiwi.com мы запустили QIWI Universe 2019.

    Здесь мы предлагаем командам, желающим написать какой-нибудь свой полезный сервис для самозанятых, поработать вместе с нами, запустить пилот и получить до 3 млн рублей, в зависимости от результата. Подробности, требования к командам и условия оценок тут. Уже работающих компаний это тоже касается. Мы открыты к сотрудничеству по адаптации сервисов для самозанятых, эти проекты тоже можно подавать на QIWI Universe.



    Что это может быть — можно придумать сервис, который поможет собирать средства уличным фотографам, музыкантам, создателям полезных вебинаров, людям, сдающим квартиры, в общем, сценариев может быть множество.

    Главный фокус — самозанятые. Именно им мы должны помогать, запуская продукт. Я искренне верю, что это крутая возможность помочь людям, компаниям и государству на новом, огромном рынке. Остались вопросы? Записывайся на вебинар 24 апреля или спрашивай в комментариях.

    Если вам не очень близка тема самозанятых, посмотрите любой из 8 проектов на QIWI Universe 2019. Они разные.

    Да, кстати, 18 апреля, мы проводим еще и митап для разработчиков, приходите, будем рады.
    QIWI
    114,00
    Ведущий платёжный сервис нового поколения в России
    Поделиться публикацией

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

      0
      В связи с p2p платежами хотел спросить, есть ли у Вас «защищеные» платежи на кошелек: пользователь видит, что к нему пришел платеж и все параметры платежа (от кого, сумму и т.п.), но использовать эти средства может только если введет пин или пароль (с ограничением числа попыток), с возможностью при отправке задать период возможного «зависания» платежаб от нескольких минут до бесконечности? Если нет, то планируете ли добавить такую возможность в будущем?

      В такую функциональность упирается возможность создания различных децентрализованных сервисов (например — фрилансерская децентрализованная биржа). У яндекс-денег есть такой перевод, но максимальный срок блокировки средств в 1 год «обрезает» многие варианты использования.
        +2
        Добрый день. Пока не планировали в массовом API, т.к. не было запросов. У нас есть похожий сервис безопасная сделка, но он для крупных компаний. Почему максимальный срок в 1 год обрезает варианты использования? Он кажется более чем длинным.
          0
          На задержке в год нормального escrow не организуешь.)

          Например, фрилансер договаривается с заказчиком выполнить заказ на 1000 долларов. Для страховки заказчик отправляет фрилансеру «защищенный» перевод на 1000 долларов, пин для разблокировки — после окончания работы. Фрилансер выполняет работу и хочет получить пин. Если блокировка бесконечная — заказчику никакого смысла обманывать нет, он 1000 долларов все равно никогда не получит обратно, если максимальный срок ограничен годом — то уже вполне оправдано не отправить пин (или отправить неверный) и через год получить свою 1000 долларов.

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

          Еще интересно, для Вас, как платежной системы, есть ли разница между созданием безопасных сделок с блокировкой навсегда и блокировкой на год? И если есть, то дело в технических ограничениях или юридических? Ну, просто, чтобы представлять, какие перспективы в этом направлении в будущем.)
            +2
            Мой опыт говорит, что описанный кейс очень граничный и не стоит на него ориентироваться. В новых рынках лучше быстрее построить систему и посмотреть, чем пытаться построить идеал, который никому окажется не нужен. Сейчас такие ситуации успешно разрешают арбитражем, который и так потребуется. В подвешенных переводах без срока действия есть множество и юридических и технических ограничений. Я не стал ориентироваться на то, что они быстро развяжутся.
              +1
              Понятно, спасибо за ответы.)
              +2
              Если блокировка бесконечная — заказчику никакого смысла обманывать нет, он 1000 долларов все равно никогда не получит обратно


              Вам не знакома концепция «сдохни ты сегодня, а я завтра»? Или анекдот на ту же тему? Или фраза «так не доставайся же ты никому!»?

              А применительно к более-менее реальной жизни, может быть такой кейс: заказчик захотел сверх оговоренного объема работ еще хотелок, потом еще, потом исполнитель вспылил, уперся, потребовал PIN. Заказчик, желая «наказать», PIN не отдает. При этом для исполнителя эта 1000 достаточно существенна, а заказчику, в общем-то, плевать.
                0
                У меня достаточно специфический кейс, выполнена работа или нет можно определить программно.)
          0
          Еще один важный вопрос, влияющий на возможность арбитража.) Может ли третье лицо как-то убедиться, что платеж данному пользователю действительно был отправлен?
            +1
            На странице статуса платежа можно отследить успешность, но там не будет видно кто и кому оплачивал. Эту информацию скрываем для безопасности. Полная информация остается только в серверном запросе статуса счета.
              0
              Было бы очень здорово иметь возможность пользователю подтвердить, что он действительно отправил такой-то платеж такому-то пользователю, например, получить файл с информацией о принятом платеже, подписанный вашим каким-то ключем.) Как я понимаю, это и технически, и юридически сделать несложно.
            0
            А лимиты есть какие-нибудь по сумме или прочие ограничения?
              0
              Согласно уровню идентификации. Их можно посмотреть в профиле на qiwi.com.
              +1
              постарались сделать процесс безопасным, быстрым и удобным […] хотим снять риски
              Как-то хотелось бы от компании, которой доверяются деньги, слышать «сделали» вместо «постарались сделать» и «сняли» вместо «хотим снять» ;)
                +1
                У нас одна из лучших команд по безопасности в России и открытая bug bounty программа, но, по честному, абсолютно безопасных систем не бывает. Часто задача в том, чтобы цена и сложность атаки превышала любые выгоды. На p2p.qiwi.com мы сделали многое, чтобы номер телефона получателя не раскрывался. Это значительно затруднит, например, восстановление симки злоумышленниками для целевых атак на крупных клиентов.
                0
                Язык формы всегда русский, не зависит от языка браузера и ip :(
                  +1
                  Под какие языки стоит адаптироваться? Была локализация на английский в предыдущей форме, но упразднили, т.к. все плательщики из постсоветского пространства. Жалоб от клиентов в поддержку не было при переходе.
                  +1
                  через неделю, 18 апреля

                  Вроде бы, 18 апреля послезавтра :)

                  И вопрос по теме: допустим, у меня есть некий товар, который не размещён ни в каком интернет-магазине или вроде того.
                  Получить доступ на «виджет» с переводом может любой человек из абсолютно разных мест (личка/группа в соцсетях).
                  Как мне в этом случае распознать пользователя?
                  Для меня было бы удобнее, чтобы помимо суммы, в виджете можно было указать комментарий.
                  Ошибки парсинга и т.д. можно взять на себя.
                  Допустим, покупка товара в группе ВК.
                  Пользователь переходит по ссылке из паблика, переводит с банковской карты, в комментарии оставляет ссылку на свою страницу или свой айдишник, а я уже выстраиваю свою логику вокруг этого.
                  Сейчас же этого никак не достичь? Ни условными utm-метками или чем-то вроде того?
                  И об отправителе я узнаю только его номер телефона qiwi или номер карты?

                  Что посоветуете здесь, или подобный сценарий запрещён вообще?
                    +1
                    >Вроде бы, 18 апреля послезавтра :)
                    Статья готовилась чуть дольше. :) Спасибо, что внимательно прочитали.

                    Виджет для переводов предназначен больше для пожертвований. Мы запустим до конца апреля поддержку доп. параметров для my.qiwi.com, но в целом для этого есть полноценное api. Можно передать любые параметры в customFields, либо при выставлении счета через oplata.qiwi.com, либо в серверном API. Они вернутся при оповещении о оплате.
                      +1
                      Я по доке понял сразу примерно, что если я буду выдавать ссылку где-то у себя на сайте или в приложении, в общем, в любом месте, подконтрольным мне — я могу сделать то, что хотел.

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

                      Можете примерно предсказать, в каком виде эта поддержка планируется быть реализована в апреле?
                      Я сейчас подумал, что даже utm-метки и прочие query-параметры не помогут.
                      Если эту ссылку, как было упомянуто в прошлом комментарии, разместить в группе в соцсети, юзеры будут разные, а ссылка одна. В итоге идентифицировать их не получится.
                      Мне кажется, с вашей стороны, дабы не думать о проблемах юзеров вашего апи, проще всего добавить поле в форму для пользователя.
                      При тех же донатах будет полезно — можно будет аналог donationalerts делать на основе вашего апи.
                        0
                        Понял кейс, да, наборная форма из нужных полей тоже есть в беклоге сразу после полноценного запуска для самозанятых. :)
                          +1
                          Круто, я законтрибьютил, почти что.
                          Если добавите какой-то конструктор форм с user-defined форматом и возможностью какую-нибудь регулярку навесить на поле, будет вообще отлично.
                          Добавлять эту возможность к полю комментария, наверное, будет лишним — но если дать возможность (опционально) добавлять поле комментария, И поле со своим названием и форматом — вот это будет круто.
                          Для тех же ссылок с соцсетей будет круто — либо ограничить ввод только цифрами и определённой длиной; либо строчкой по регулярке вроде `^https://vk.com/.+`.
                            +1
                            Да, за небольшой фичей скрывается достаточно плотная работа, поэтому решили, что сначала запустим решение для самозанятых. Посмотрим что востребовано и какие потребности есть у клиентов. Увидим первые результаты QIWI Universe 2019 и сделаем под потребности клиентов классный инструмент.
                            0
                            Ах, да — проверкой валидности введённого в поле значение должен бэкенд заниматься (ваш). Потому что кулхацкеры, меняющие код элемента, не дремлют. И поля, соответственно, должны быть обязательными (по выбору владельца формы)
                      0
                      Этим сервисом можно пользоваться физ. лицам для личных нужд или это именно для налоговой?

                      Оплатить можно только российской картой? Или другие страны тоже принимаются?
                        0
                        Сервис открыт для всех. Регистрация самозанятых сделана отдельным разделом и находится на финальной стадии разработки. Открыт прием карт из стран СНГ. Мы внимательно анализируем статистику оплат и, если потребуется, будем постепенно открывать новые.
                          0
                          В форме у вас написано «Выставить счет покупателю», немного смущает формулировка. Если я, например, хочу личный перевод получить от родственника, у которого нет киви? Не получится ли так, что эти «счета» потом пройдут автоматически в налоговую как за оказание услуг?
                            0
                            «Покупателю» — перенесли с kassa.qiwi.com. Уберем, спасибо. Информация в налоговую в интерфейсе передается по прямому согласию клиента.
                        0
                        При выставлении счета через API какой смысл указывать customer.phone? На что он влияет? Вроде бы счет в кабинете не появляется, пользователю всё равно приходится вводить в вашей форме свой номер телефона (для входа).
                          0
                          Можно в payUrl передать параметр paySource=qw https://developer.qiwi.com/ru/bill-payments/
                            0
                            Спасибо, я это сразу понял и быстро изменил вопрос на другой ) А вот про customer.phone до сих пор непонятно.
                              0
                              Ой :) Ответил на старый. Работаем над привязкой телефона к ЛК клиента. Если телефон передан, то инвойсы будут появляться в ЛК.
                          0
                          GEG, подскажите, пожалуйста, а возможно ли как-то идентифицировать плательщика? Раньше в ishop счет выставлялся на конкретный номер телефона, с него счет оплачивался, этот же номер передавался в уведомлении на сервер. Теперь же никак нельзя сопоставить поступившую оплату с номером телефона? При создании счета можно указать customer.phone, но он по сути ничем не отличается от произвольных полей customFields? Т. е. ни на что не влияет (оплачивать можно чем угодно) и просто передается обратно «как есть»?
                          В истории платежей в кабинете qiwi видно замаскированный номер телефона. Не планируете ли передавать его через API в уведомлении?
                            0
                            Теперь клиент может оплатить любым способом оплаты, не вводя номер телефона. Т.е. с карты, qiwi или мобильной коммерции. Поэтому мы сделали поддержку передачи любых данных в customFields и account. Можете описать какой-то кейс, когда нужны доп. данные? Хеш от номера карты\номера телефона подошел бы?
                              +1
                              Основной кейс — борьба с мошенничеством, с отмыванием средств и пр. Когда можно сопоставить, что это и это скорее всего оплатил один человек. Создать аккаунт на сайте и подменить IP просто, а получить новую SIM-карту и оформить новый кошелек — намного сложнее. В общем, очень хотелось бы получать какую-то информацию о пользователе. Если говорить о конфиденциальности, то в кабинете (в истории) всё равно отображается телефон, где некоторые цифры скрыты звездочками. Хотя бы это передавалось бы в уведомлении — уже было бы здорово. Хеш — тоже хорошо, в некотором смысле даже лучше звездочек (не будет ложных пересечений). Но хеш мешает другому кейсу (намного менее важному) — иногда при утере аккаунта или подозрении на взлом спрашиваем старые платежные реквизиты (номер телефона в случае qiwi).
                                0
                                Формально в новом решении возможность переслать счет другому человеку для оплаты вела к повышению конверсии и мы собирались проверять эту гипотезу. :) Для механик, когда номер телефона или карты должен быть подтвержден мы работаем над api привязок способа оплаты.
                                +1
                                И все-таки в документации, похоже, ошибка.
                                developer.qiwi.com/ru/bill-payments/#notification
                                customer.phone — Номер телефона, на который был выставлен счет (если был указан при выставлении счета)

                                Если customer при выставлении счета не передавать, то в уведомлении приходит customer.phone, соответствующий телефону плательщика.
                                  0
                                  «Если customer при выставлении счета не передавать, то в уведомлении приходит customer.phone, соответствующий телефону плательщика.»
                                  Вот это, кажется, наша ошибка. Проверим. Спасибо.

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое