Идея: Система прямого финансирования закупок фондов и штабов Pokupay #21
Comments
|
А фонд оплаты труда? |
|
Из фонда оплаты труда можно охватить регулярные безналичные платежи. Так, сотрудник может занести в сервис свои платёжки за коммуналку, интернет, мобильную связь, спорт или кружок для ребёнка. Получается как "соцпакет" у офисного работника, только краудфандинговый. |
dmikushin
changed the title
|
Да но какой-то суперконтроль людей и суперпрозрачность. Не проще ли криптой? |
|
Когда донейтер желает отправить донейт, севис подбирает ему похожий по сумме платёж, и донейтер должен подтвердить его в разумно обезличенном виде, например "3180 руб., ПАО ТомскОблЭнерго, компенсация волонтёру". Сам сервис конечно знает больше подробностей о платежах, но и значительно меньше, чем обычный банк знает о вас, если вы оплачиваете покупки картой. Представьте себе что вы стоите в очереди на кассу, а покупатель магазина перед вами забыл кошелёк (его заблокировали по делу о 80 миллиардах ФБК). Вы знаете, что он работает на компанию, которую вы поддерживаете. Поэтому вы подойдёте и оплатите его покупку своей картой. Может вы увидите краем глаза, что из его пакетов торчат лук и сосиски - ну и что, кому от этого должно стыдно стать? Наш сервис позволит оказывать такую поддержку в большом масштабе. Крипта - небезупречное решение во многих отношениях. Главное, с точки зрения репутации это будет примерно как раздать сотрудникам фондов банковские карты иностранных банков. Но борьба с коррупцией и волонтёрство в России сейчас трактуются как сугубо суверенные вопросы, как по закону, так и по духу. Чтобы это изменилось, страна должна стать более открытой, но пока такие решения очень многим покажутся неприемлемыми. |
|
Классная идея, мне прям очень нравится. Но механизм работы не очень понятен. Сотрудник организации хочет купить пачку бумаги. Находит его в интернет-магазине, кладёт в корзину, жмёт «оплатить», и...? Ссылки на страницу для реквизитов карты живут очень недолго, шарить их с жертвователем неудобно. Как вариант — выставлять реквизиты для безналичной оплаты: БИК, корсчёт, номер счёта, номер заказа. Это достаточно распределённо, но у магазина могут быть непонятки с оплатой счёта третьим лицом. Плюс перевод по реквизитам — не самый дружелюбный интерфейс. Можно запилить шлюз, принимающий деньги с карты и высылающий их по реквизитам, но это единая точка отказа, потому что российское юрлицо и счёт в российском банке. Плюс в такой системе будут «зависать» любые покупки дороже 500 рублей (медианное пожертвование по данным ФБК). То есть, нужна опция по агрегации нескольких пожертвований. И это снова точка отказа, потому что деньги нужно где-то (на счету в российском банке) хранить до накопления полной суммы. |
Да, мой расчёт именно на процессинг платёжек, в первую очередь. У крупных получателей это точно не вызовет вопросов - так вы можете оплатить чьи-угодно коммунальные услуги, например. И оплатить можно произвольную сумму, хоть 4 раза по 500 рублей. Вообще, идентификация идёт по строке "назначение платежа" - в ней пишется в чью пользу перевод. И перевод всегда проще принять и разобраться в нём, потому что ошибочный перевод по-хорошему нужно возвращать, а это никому не удобно. Можно просить жертвователя предоставить данные банковской карты и разрешённый лимит снятия. Тогда для подтверждения платежа будет достаточно смс-кода. |
|
В голову пришёл, пожалуй, главный минус с процессингом платёжек — невозможность (или крайне высокая сложность) автоматизации. Не существует единого API для отслеживания простых банковских переводов. То есть, мы не можем автоматически проверять, что а) платёж прошёл, б) он на правильную сумму. Максимум, что мы можем — надеяться на магазин и на сотрудника организации реципиента: магазин сообщит об оплате, сотрудник отметит это в системе. Но в этой схеме слишком много человеческого фактора. Вторая проблема — синхронизация нескольких доноров. Несколько человек может оплатить одну покупку, или на большую покупку придёт слишком много маленьких частей. С этим можно бороться «блокировками» на манер блокировок в базах данных (только один донор может жертвовать на одну покупку), но в связи с первой проблемой мы не сможем достаточно оперативно снимать блокировки. В итоге сбор больших сумм очень затягивается, плюс злоумышленники могут злоупотреблять этим механизмом и бесконечно долго держать блокировку на важных закупках. Хранить на стороне сервиса полные реквизиты карты (и, видимо, отдавать их целиком сотруднику организации) — совсем плохая идея. Это со всех сторон небезопасно: от взлома базы с реквизитами (а такая база станет очень лакомым куском для хакеров всех мастей) до всё того же человеческого фактора. Одноразовый пароль — не панацея, потому что он нужен не для каждой оплаты. Можно попробовать пойти по тому же пути, по которому ходят Google Pay, Apple Pay, Samsung Pay и иже с ними: взять один раз реквизиты у пользователя, соорудить на их основе некую виртуальную карту и уже эту виртуальную карту выдать реципиенту. Реципиент оплачивает покупку привычным способом реквизитами карты, а сервис инкапсулирует в себе списание с нескольких карт, проверку лимитов списания и разрешённые статьи бюджета. Насколько я понимаю, это потребует интеграции с платёжными сервисами вроде Visa и Master Card. Хз, насколько это сложно. При этом нужно учесть проблему баланса: деньги должны быть на карте не только на момент привязки карты, но и на момент оплаты. Это можно решить через механизм заморозки денег на счету: в момент донации деньги блокируем, в момент оплаты в магазине подтверждаем блокировку и списываем деньги. Если что-то пошло не так, снимаем блокировку. |
|
Ну и да, нельзя забывать про вопрос удобства. Если жертвовать неудобно, большая часть жертвователей уходит. |
|
Виртуальная карта - это отличная мысль! Более того, многие будут рады получить брендированную кредитную карту с символикой фонда. Но нам следует при этом воздержаться от любых признаков банковской деятельности: заморозка средств - это эквайринг, а наши "взаимоотношения" с VISA/MasterCard погонят расследовать вообще всех следователей каких только найдут в стране. |
|
Нехватку средств у жертвователя на момент оплаты нужно обрабатывать как обычную ситуацию. С этим сталкиваются любые сервисы с продляемой подпиской, тот же GitHub. Не прошёл платёж - отправляем жертвователю грустный смайлик и переходим к следующему жертвователю в цикле. То же самое касается хранения данных банковских карт. Если бы миллионы сервсисов их не хранили, мы бы сейчас тёрли монеткой полоски как 20 лет назад. Серьёзные сервисы существуют благодаря автопродлению, для которого как ни крути необходимо хранить данные. Мы можем подумать как хранить их в не очень глупом виде, например разделить шифрование на несколько верифицирующих серверов, каждый из которых пришлось бы взламывать отдельно. |
|
Допустим, мы пришли к тому, что храним номера банковских карт. Система могла бы выглядеть так. Сотрудник или оператор фонда со своего десктопа заходит на облачный сервер. В этом сервере висит много изолированных контейнеров-киосков с Google Chromium или Firefox. Оператор вводит адрес магазина и переходит к оплате готовой корзины. Браузеры умеют автоподставлять номера банковских карт сразу в виде звёздочек. Мы форкнем эту функцию так, чтобы она брала данные с сервера жертвователей, но полностью скрывала от оператора всё: и номер, и ФИО, и дату, и CVV. Оператору остаётся только нажать на оплату и убедиться, что она прошла. Если не прошла - новая попытка, и автоподстановка введёт звёздочками данные другого жертвователя. Для обслуживания смс-ок потребуется мобильное приложение на стороне жертвователя, авторизованное на получение смс. |
|
Чтобы прям брать и хранить данные карт, нужно пройти сертификацию PCI DSS или пользоваться услугами компании, которая такую сертификацию прошла. Крупные магазины типа Amazon (может, даже Ozon) могут себе позволить сами проходить такую сертификацию, мелкие пользуются чужим хранением. Вариант с форком браузера и запуском на удалённом рабочем столе выглядит, мягко говоря, костыльно, тем более, что есть промышленные решения. Плюс это не решает проблему крупных покупок, всё ещё непонятно, где аккумулировать средства на покупку очередного |
|
@valericus Вы слишком усложняете. Люди в нужде нередко выкладывают номер карты для пожертвований открыто в соцсетях - какие там PCI DSS?? Единственное, что формально может потребоваться - это согласие на обработку персональных данных. Но юрлица-оператора, проверка которого может потребовать предъявить это согласие, не существует. Поэтому и этой проблемы де-юре не существует. На этапе MVP я вижу виртуалку с браузером как минимальную меру защиты. Таким образом мы на всякий случай не даём никакие данные на личный компьютер волонтёра. Это предотвратит утечки в случае изъятия и недобросовестное использование провокаторами. Приведите, пожалуйста, подходящие на Ваш взгляд бесплатные промышленные решения? Аккумулирование средств на более крупную покупку может происходить внутри небольших групп жертвователей, знакомых между собой. Но эту функцию (как и многие другие) следует пока вынести на рамки MVP. |
|
Создал проект https://github.com/stouza и добавил всех тех, кто лайкнул идею. Если кто-то ещё хотел бы присоединиться, пожалуйста, отправьте запрос. |
|
16-значный номер карты — это публичная информация, его можно использовать для пополнения счёта, но (насколько знаю) нельзя использовать для снятия или оплаты. То есть, это совсем не то же самое, что хранить полные реквизиты карты. Плюс «люди в нужде» — это очень плохой аргумент. Я не усложняю, а хочу построить надёжную и безопасную систему, заслуживающую доверия. То, что люди в состоянии стресса делают глупости — не повод самим делать заведомо небезопасное решение. Ещё и в совокупности с разговором о формальном исполнении обязательств. Такой подход подрывает доверие к проекту в частности и к фандрайзингу вообще. Боюсь, бесплатных решений в сфере финансов нет, любой посредник в пересылке денег из точки А в точку Б берёт комиссию. Из промышленных решений могу предложить таки воспользоваться услугами посредника, который возьмёт на себя хранение данных банковских карт. Возможно, с кем-то удастся договориться на приемлемые условия. Виртуалка с браузером, повторюсь, плохая идея. Ни мне, ни, полагаю, вам не достаёт знаний, чтобы сделать такое решение безопасным и устойчивым ко взлому. То есть, нужно делать решение, которое хранит минимум чувствительной информации. Вариант с посредником выглядит адекватно, потому что требует хранения только короткоживущих и отзываемых токенов. В общем, надо определиться с целями и задачами. Сейчас попробую набросать что-то в рамках созданного проекта. |
|
@valericus Спасибо. Мы не найдём посредника, который а) чисто Российский б) не поддастся политическому давлению. Так что ни о какой реальной защите данных через посредника говорить не приходится. Поэтому я говорю об этом как о формальности, имея в виду что защита теоретически должна быть и со стороны Закона, и со стороны посредника. Но на деле её нет, и обеспечить что-то можем только мы сами, своими средствами. |
|
@jerrygreen, спасибо за мысли! Поймите, что как только в сервис с
американским посредником не дай Бог зайдут сколько-нибудь уважаемые фонды,
Минюст даст вам звезду героя за то что вы помогли найти им то, что они 10
лет искали: ИНОСТРАННЫЙ СЛЕД. Никто не будет разбираться в том, что это
технически ложный вывод - наша недальновидность вызовет рецидив
шизофренической шпиономании на долгие годы. Продумайте последствия решения,
и вы увидите, что свой полностью российский сервис -
единственная жизнеспособная схема в нынешние времена.
пн, 23 дек. 2019 г. в 19:22, Jerry Green <[email protected]>:
… Есть такой посредник, Stripe <https://stripe.com>, - это популярный
зарубежный сервис, и это как раз-таки сервис для таких "маленьких", которые
не могут взять на себя риск и ответственность, и позволить себе разбираться
с хранением карт. Stripe берет на себя все проблемы с шифрованием и
безопасным хранением. Вообще, этот сервис для всевозможных действий с
онлайн транзакциями, но:
Простое сохранение карт <https://stripe.com/docs/saving-cards> (для
последующего использования) у них тоже есть.
А еще, - многие банки позволяют создавать виртуальные карты. Это можно
использовать жертвующим, в качестве ограничителя тех средств, которые они
доверяют в использование. И даже рекомендовать им это использовать (а то и
обязать?). Ведь вряд ли кому-то захочется давать реквизиты своей основной
карты, мало ли что пойдет не так. А если в какой-то момент какое-то
конкретное движение загнется (которое собирало донейты), - все
неиспользованные средства останутся у их изначальных владельцев.
За каждую транзакцию Stripe берет 2.9% + 30¢. Для небольших пожертвований
по типу 500р, и для микротрат, - это не подходит. Даже не столько из-за
комиссий (это тоже), сколько из-за того, что едва ли кто-то захочет
заморачиваться создавать виртуальную карту ради 500р, и вообще разбираться
как это работает и зачем. 500р - это медианное пожертвование, но среднее
пожертвование у ФБК выше. Т.е. существуют люди, которые готовы поддержать
сильно больше, чем на 500р. И для каких-то уже более увесистых
пожертвований по типу 10т.р.+, - это хороший вариант. Такие люди более
вовлечены, они будут готовы разобраться с этой концепцией, зачем это нужно,
и создать виртуальную карту им будет не лень. Остальные же, которые
жертвуют по 500р и не хотят заморачиваться, - будут также это делать
прямыми переводами, как сейчас.
Поэтому проблема более крупных транзакций и агрегация мелких сумм, - не
уверен насколько такая проблема вообще есть. Теоретически есть, на практике
не понятно будет ли. В худшем случае, максимальный ценник для огранизации
будет ограничен максимально доступным пожертвованием. Поэтому лучше
алгоритм сформировать так, чтобы в первую очередь происходили снятия с
карт, сумма которых максимально приближена к сумме транзакции (в целом,
алгоритм наверное должен быть еще более умным, это лишь базовая концепция).
Если все-таки очень крупных пожертвований не будет, а очень крупные покупки
нужны, по типу какого-нибудь хорошего дрона, - там агрегирущую функцию
возьмет на себя человек от организации, который снимет деньги нескольких
человек к себе, и сам купит дрона (сейчас ведь так это происходит?).
Итоговые мысли
Да, в плохом случае, это не избавит сотрудников фондов от финансовых
рисков полностью. Но в хорошем случае, - это избавит сотрудников фондов от
финансовых рисков в большинстве своем. Для какого-то Proof of Concept MVP
вполне можно использовать Stripe.
Из плюсов: это будет довольно удобно. Никаких виртуалок с браузерами и
прочей ерунды. Нужно лишь в своем приложении банка создать виртуальную
карту, перечислить туда денег сколько хочется, и оставить реквизиты этой
карты на сайте.
Из минусов: это технически непростой сервис. Не знаю у кого есть столько
мотивации сделать это все. Даже пусть не нужно организовывать свои
хранилища карт, реализовывать сложные стандарты, все равно создание такого
сервиса, интеграция со Stripe, и вот это все, - оно требует немалых усилий.
Не говоря уже о какой-то социальной составляющей: как подружить такую
систему с фондами? Можно потратить месяца на разработку, а потом может
оказаться, что никому это не нужно. Насколько проблема действительно
актуальна?
P.S. Просто некоторые мысли в копилку идей :)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#21?email_source=notifications&email_token=ABLI7KVKDE5QP3NZXWKVWN3Q2D6XVA5CNFSM4JTOPADKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHRVGZA#issuecomment-568546148>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABLI7KWIM2FA525HRCGWC7TQ2D6XVANCNFSM4JTOPADA>
.
|
|
@dmikushin, я поторопился публиковать свое сообщение, и сразу его удалил, потому что хотя можно будет списывать деньги со счетов жертвователей, но с точки зрения сотрудников фондов, - все равно не получится сделать транзакцию напрямую в магазин. Нужно как-то считать реквизиты карт обратно из Stripe, чтобы использовать их для форм оплаты, - но Stripe не позволяет этого сделать, реквизиты он защищает ото всех. Он позволит только вывести к себе на карту, на свой банковский счет. Не раскрывая при этом данных карты. Так что даже технически, это не совсем то, что нужно. Нужно, чтобы была возможность сделать транзакцию напрямую. Нужен другой способ. А еще, я не понимаю такого жесткого смещения в "суверенность". ФБК у себя использует ту же гугл аналитику. И да, им уже жаловались на то, что у них там "иностранное ПО", и что они иностранные агенты, - но ничего это не дало. Как вы думаете, где у них находятся сервера? Да если бы у какого-нибудь российского провайдера, - уже давно бы снесли все к чертям. По крайней мере, какой-то кусочек инфраструктуры у них физически находится во Франции. Домен они тоже зарегистрировали через иностранного регистратора. Это я к тому, что везде нужна своя мера, и не нужно уж слишком сильно идти на поводу у идиотов (достаточно просто соблюдать законодательство). Потому что если идти на поводу у идиотов, делать прям как они желают, то можно и вовсе сказать, что интернет - это иностранная разработка. Так давайте её теперь тоже не использовать? Возьмите себя, пожалуйста, в руки. |
|
@jerrygreen Вы правы, что любую предосторожность можно проигнорировать, намеренно придав ей абсурдности. Допустим, Вас просят ждать зелёного сигнала светофора, а вы возмущённо летите через перекрёсток, приговаривая, что так можно и машины запретить, и вообще из дома не выходить. Я исхожу из модели клиента - того человека, гражданина и жителя РФ, который будет пользоваться сервисом. Попробуйте себя поставить на место жителя среднего российского города (не Москвы), которому в уши льёт ТВ: станет ли он сотрудничать с Вашей системой? Было бы хорошо собрать хотя бы несколько мнений на этот счёт. Если условный рабочий Уралвагонзавода скажет, что "давайте, мне хоть страйп, хоть госдеп, лишь бы за Россиюшку", значит Ваш подход верный, а я зря всё усложняю. |
|
Популярность платформы - важный фактор живучести. Я бы хотел сделать такую архитектуру, которая бы была востребована во множестве сообществ. Допустим, микрокредиты или касса взаимопомощи или бартерные взаиморасчёты. Применений огромное число, в этом сила нашей идеи. И любой сможет её форкнуть и использовать как ему нужно. Поэтому важно не создавать лишних жёстких внешних привязок. Кому понадобится - отрежет нашу собственную систему обработки платежа и прикрутит свою. |
Это как обычная карта, но с динамическим номером. Вот это звучит максимально круто, на самом деле. Только непонятно насколько это реализуемо. В самой концепции/теории, кажется, косяков нет. Должно работать. Это даже не совсем онлайн сервис получается. Вся логика будет зашита в самом девайсе (в локальном приложении). Хотя сервис может тут присутствовать как вспомогательный элемент, чтобы автоматически пополнять базу доступных карт для пользователя, когда появляются новые жертвователи. Возможно как-то еще будет помогать считать общий баланс (с этим могут быть проблемы). Это получается какое-то свое приложение ApplePay (приложение Wallet), которое по NFC будет передавать данные подходящей карты, но динамически. А если есть возможность увидеть оплачиваемую сумму до того, как были выданы реквизиты (не уверен, что так можно), то можно 1 в 1 повторить текущий опыт людей с их собственными картами: просто прикладываешь телефон, и всё. Только здесь будут такие "краундфандинговые карты", за которыми будет стоять множество разных пожертвованных карт, и приложение будет автоматически выдавать более подходящую. Возможно можно использовать стандарт ApplePay, чтобы это все работало с текущими безналичными платежными терминалами, - как бы имитировать ApplePay приложение. Потому что, по большому счету, приложение ApplePay "Wallet" не делает никакой магии, - оно просто хранит данные карты, и передает эти данные в платежный терминал по какому-то стандарту. Уж не знаю, есть ли этот стандарт в публичном доступе, чтобы его можно было повторить. Правда кнопочки "Pay with ApplePay" на сайтах работать не будут в любом случае. Да и вообще, возможно идея с NFC тоже не очень, - там банки могут легко счесть такие транзакции подозрительными из-за странной геолокации. Если пользователь и жертвователь в разных городах, то это может быть проблемой. Причем, банк может разбираться с такими транзакциями как "по указу сверху", так и по своей инициативе, дабы обезопасить своего клиента. Но какой-то более кустарный вариант, с прямым вводом данных карты, - вполне может работать. Забиваешь в приложение нужную сумму, - и оно динамически выдает тебе данные одной из карт. И эти данные уже используешь в любом онлайн магазине, приложении, или для тех же коммунальных услуг. Ох, не знаю, не знаю... Тут много что строится просто от гипотез, нужно проверять кучу моментов, очень много ресерчить... Работы просто выше крыши 😄 Но идея прикольная. |
|
Для подстановки карты в NFC-чип (это называется NFC Host-Emulation), интеграция с Visa/Mastercard не нужна. Но есть проблемы: во-первых, на терминале может быть запрошен пин-код, это неудобно. Во-вторых, NFC считается опасной, поэтому - да - её лимитируют и по гео и по сумме. В конечном итоге, это только для магазина и хорошего телефона (ни в одном из моих NFC-чипа нет). Ещё есть планы запустить на кассах магазинов выдачу наличных денег - это значит может появиться риск обналички. |
Система прямого финансирования закупок фондов и штабов Pokupay
Проблема
Сейчас фонды, действующие в интересах общества, собирают финансовые пожертвования в виде денег на личные счета. В последнее время мы увидели, что даже наиболее "модные" (чуть было не написал "приличные") финансовые институты склонны чинить этому препятствия (блокировка карты Волкова в рокете).
Таким образом, любой банковский счёт для фонда является риском. Более того, в финансовые риски оказываются незаконно вовлечены сотрудники фондов (штабы, ФБК и т.д.) и просто совершенно случайные люди.
Задача
Сделать финансовые потоки максимально распределёнными, чтобы обыски у 2 миллионов человек из-за 300 рублей стали невозможны.
Как?
Допустим, фонд сформировал бюджет на оргтехнику или какие-то услуги подрядчиков. Вместо того, чтобы собирать донейты на свой счёт, можно запустить инфо-сервис, который будет просить донатеров напрямую оплатить ту или иную покупку со своей банковской карты. Для донатера это - то же самое, что переводить деньги. А для фондов - отличная защита от финансового беспредела.
Возможная реализация
Сотрудник или оператор фонда со своего десктопа заходит на облачный сервер. В этом сервере висит много изолированных контейнеров-киосков с Google Chromium или Firefox. Оператор вводит адрес магазина и переходит к оплате готовой корзины. Браузеры умеют автоподставлять номера банковских карт сразу в виде звёздочек. Мы форкнем эту функцию так, чтобы она брала данные с сервера жертвователей, но полностью скрывала от оператора всё: и номер, и ФИО, и дату, и CVV. Оператору остаётся только нажать на оплату и убедиться, что она прошла. Если не прошла - новая попытка, и автоподстановка введёт звёздочками данные другого жертвователя. Для обслуживания смс-ок потребуется мобильное приложение на стороне жертвователя, авторизованное на получение смс от наших номеров.
The text was updated successfully, but these errors were encountered: