Да, это уже понятно из всех предыдущих сообщений. Ближе к вечеру я тут опять появлюсь и расскажу что узнала.
Да, такая возможность действительно нужна и обдумывается.
Это, конечно, не совсем ко мне вопрос (а к Яндексу), но я могу сказать, как себе представляю. Как я понимаю, это вопрос не только "политики", хотя она конечно имеет значение, но и бухгалтерии. Учет этих неясных чеков - совсем не то что нужно Яндексу в его белой и пушистой бухгалтерии.
Наверняка можно. А вот будет ли это делаться - решаю не я. Но как и говорила выше, обещаю узнать и отчитаться :)
Вовсе нет. Ответила на все, где могла что-то ответить. Надеюсь, что S.Alexeev проявится и что-то прокомментирует, тогда сможем все точки над и расставить.
Меня вы уже убедили. Я завтра вам расскажу, что начальство думает, ладно? Сейчас они уже по домам все, это я только по ночам работаю.
Конечно, у нас ежедневно идут возвраты, хоть и немного.
Например, с мобильными операторами, когда они не поддерживают в своем протоколе проверку существования номера телефона до совершения платежа.
Что касается законодательства, я как-то не понимаю, что здесь специального: у нас с магазином заключен договор, мы обязуемся принимать в его пользу платежи и по определенному регламенту рассчитываться и отчитываться. А он выполняет отгрузку товара. Если отгрузку сделать не смог - делает возврат платежа.
Магазины, в которые можно "положить на баланс" - это для нас не совсем магазины. В том смысле, что если они работают просто через кошельки, то они для нас "делают вид", что они физлица. То есть это как бы все равно для нас "p2p".
Но в общем тема понятна, да.
Так у нас же никто никуда не приходит, магазин к вам курьера отсылает. Кроме того, у нас с ним договор, мы его знаем...
И главное, код протекции в таком случае потребует от магазинов какой-то дополнительной доработки их софта, и к тому же ручного ввода кода. Сомневаюсь, что они будут готовы так работать. Но обещаю поговорить с начальством и доложиться тут про перспективы.
Oops. Действительно, это мне попросту в голову прийти не могло. Потому что пользователи наши ничего нигде мышками не выделяют, а вписывают номер в формочку на сайте... Тогда действительно все становится на свои места.
Только тогда возникает следующий вопрос.
Если у вас есть некая "малая механизация", которая вам позволяет отправлять платеж через ЯДеньги "мышкой в базе данных", тогда наверно, стоит начать с того, что вам и клиентский софт какой-то другой бы нужен? Ну то есть не "энд-юзерский", а сразу заточенный на механизацию?
Насчет подтверждения - спросила начальство, как это организовать :)
Нет, я не из саппорта Яндекса.
Я из саппорта Яндекс.Денег.
Только зачем так агрессивно-то? Знаю я, что такое код протекции, и даже пользовалась. Но (я выше это написала) у нас большинство операций в системе - это платежи в магазины/сервисы, а вовсе не переводы между кошельками. И зачем код протекции при, скажем, платеже за Скайп - я действительно не понимаю.
Вот ваш коллега SeaBreeze дал пояснения из которых я поняла, что моя гипотеза была правильная: протекция нужна для p2p расчетов. Для платежа магазину, судя по написанному им, действительно не нужна.
Спасибо большое!
То есть если я правильно понимаю, он нужен-важен именно для p2p-платежей, а не платежей в магазины. Тогда скорее всего эта функция планируется к реализации на этот год.
Тут есть такая историческая вещь - в прошлом году приоритет был на платежи за сервисы, а p2p считался чем-то слегка неприличным, от чего отказаться нельзя, но и полностью "белыми-пушистыми" эти операции вроде как тоже не назовешь... Сейчас на развитие p2p как раз задачи ставятся. Наверняка они и код протекции обсуждают, я уточню.
Ну и по-мелочи - у нас очень трудно ошибиться при вводе номера счета, поскольку он включает контрольную сумму. Мне даже когда-то писали, какова вероятность (у нас там в Питере математиков хватает) - но в общем, очень маленькая :)
