Pull to refresh

Comments 26

Я бы хотел ознакомится на практике с API яндекс.кассы в тестовом режиме до того как появится реальная необходимость в его использовании (чтобы быть готовым быстро написать собственное решение для проекта достаточно быстро, когда это понадобится), но на данный момент за плечами нет организации, и соответственно возможности зарегистрироваться в системе. Я недавно спрашивал об этом тех поддержку, может с введением нового функционала появится возможность воспользоваться тестовым режимом без регистрации с ИНН?
К сожалению, сейчас выдача тестового магазина возможна только после одобрения анкеты (а значит нужен реальный ИНН и расчетный счет), но если вы хотите потрогать протокол — напишите мне в личку и мы создадим для вас логин/пароль для аутентификации в API. Если же вы планируете писать модули под CMS — напишите, пожалуйста, на cms@yamoney.ru
И это супер косяк. Я в свое время тоже хотел потыкать и разобраться, а нельзя. В чем сложность выдать тестовый магазин без всяких там расчетных счетов — загадка.

И это не единственный косяк. Не далее как в августе помогал интегрировать кассу знакомому. Так после успешной тестовой обкатки решения, было отказано во включении боевого режима без объяснения причин. Слишком всё усложнили. В итоге ушли к Paymaster, где без проблем тебе выдают и тестовый доступ и подключают к магазину. Хотя нужно признать, в кассе протокол надёжнее будет.

Отказ может быть связан с тем, что продаваемые товары и услуги не входят в перечень разрешенных правилами МПС или если и покупатель, и продавец — юридические лица, тогда как Касса проводит платежи от физиков. Могут быть и другие причины, и обычно коллеги стараются ответить подробно. В любом случае если снова будет актуально — приходите, постараемся помочь.
А есть ли вариант организовать приём платежей на сайте через Я.Кассу (с приёмом денег с карт) без аренды кассы у партнёров?
Да, но по закону ФЗ-54 для онлайн-торговли нужна онлайн-касса — либо купленная, либо арендованная. Если арендовать у партнеров Кассы, то онлайн-чеки, передача в ОФД и т.п. — вопрос решенный. Если у другой компании, с кассами которых Яндекс.Касса не интегрирована, то придется настраивать обмен данными между онлайн-кассой и Я.Кассой самостоятельно.
Если ИП на патенте, оказывает услуги, вроде онлайн касса не нужна пока?
ИП на патенте ККТ сейчас правда не нужна. Но этот режим налогооблажения недоступен для дистанционной торговли.
Что касается услуг, можно пока не применять ККТ при условии выдачи клиенту в момент оплаты БСО. А бланк строгой отчётности — это бумажка, а значит обеспечить её выдачу в момент оплаты в онлайне невозможно. Следовательно нужно применять ККТ
Новое API это хорошо, но буквально неделю назад столкнулся с банальной проблемой, ssl сертификат от cloudflare не подходит для вызова вебхуков в моем магазине. Именно по этой причине мы пока решили остаться на робокассе.
Выдержка из документации
Если вы используете HTTPS от cloudflare

Доступ по HTTPS от Cloudflare работает по технологии SNI. В настоящий момент наша платежная система не поддерживает этот режим (поддержка ожидается примерно в четвертом квартале 2017 года). Если ваш сайт работает через Cloudflare, вам надо обратиться в техподдержку Cloudflare с просьбой перевода на HTTPS без режима SNI.

В статье об этом ни слова, но я надеюсь вы двигаетесь в этом направлении.
Да, к сожалению, это известная боль старых протоколов и именно поэтому в новом API такой проблемы больше нет
Не прошло и четырёх лет, как чекаут в строю.
С идемпотентностью подсуетились, реализовали всего на полгода позже ;)
Не прошло и 6 лет, если вы про Stripe ;) Наши API всегда были идемпотентными, начиная с эквайрингового пртокола в 2013. Все-таки это маст-хэв для платежного протокола
У меня только один вопрос
возможно ли выставить чек потенциальному покупателю с признаком «ПЛАТЁЖ» независимо от того совершил он платёж или нет? То есть ДО совершения расчетов?
Расскажите, а какой сценарий вы реализуете и почему появилась такая потребность? Сейчас выставить чек до взаиморасчетов нельзя, так как чек является подтверждением проведения взаиморасчетов между покупателем и продавцом.
то что в фз-54 прописано
5. Пользователи при осуществлении расчетов с использованием электронных средств платежа, исключающих возможность непосредственного взаимодействия покупателя (клиента) с пользователем или уполномоченным им лицом, и применением устройств, подключенных к сети «Интернет» и обеспечивающих возможность дистанционного взаимодействия покупателя (клиента) с пользователем или уполномоченным им лицом при осуществлении этих расчетов (далее — расчеты с использованием электронных средств платежа в сети «Интернет»), обязаны обеспечить передачу покупателю (клиенту) кассового чека или бланка строгой отчетности в электронной форме на абонентский номер либо адрес электронной почты, указанные покупателем (клиентом) до совершения расчетов.

1) клиент присылает мне адрес электронной почты
2) я отправляю клиенту договор оказания услуг в электронном виде и фискализированный чек с признаком «ПЛАТЁЖ» и хэш функцией файла с договором в описании платежа(могу без проблем, это не описание услуги, а сведения о платеже)
3) клиент получает чек проверяет соответствие договора хэш функции с файлом договора (собственно мне все равно проверит или нет в сведениях о платеже хэш указан)
4) клиент оплачивает платёж (акцептует договор).
5) я оказываю услуг
6) клиент производит оплату услуги
7) деньги поступают на мой счет
8) я распечатываю чек и отправляю клиенту электронный экземпляр чека на электронную почту с описанием оказанной услуги и сведениями о поступившей оплате по договору выше. Печатный экземпляр храню у себя. Могу клиенту передать.
9) все довольны

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

1) клиент присылает мне адрес электронной почты
2) я отправляю клиенту договор оказания услуг в электронном виде и фискализированный чек с признаком «ПЛАТЁЖ» и хэш функцией файла с договором в описании платежа(могу без проблем, это не описание услуги, а сведения о платеже, информация о том по какому договору БУДЕТ осуществлен платёж)
3) клиент получает чек проверяет соответствие договора хэш функции с файлом договора (собственно мне все равно проверит или нет в сведениях о платеже хэш указан)
4) клиент оплачивает платёж (акцептует договор).
5) я оказываю услугу
6) клиент производит оплату услуги
7) деньги поступают на мой счет
8) я распечатываю чек и отправляю клиенту электронный экземпляр чека на электронную почту с описанием оказанной услуги и сведениями о поступившей оплате по договору выше. Печатный экземпляр храню у себя. Могу клиенту передать.
9) все довольныи суд рад, что теперь в случае спора он может истребовать из налоговой основание платежа и разрешить спор (например, какого качества должна была быть оказана услуга)

при такой схеме интернет сайт не нужен вообще. отмечать какие то галочки не нужно. Интернет магазин превращается в простую витрину. Условия договора известны еще до осуществления платежа и фискализированы в налоговой. У суда есть достоверный источник информации о сделке.
Как насчет такого же АРІ для массовых выплат? Сейчас приходится ну уж очень изворачиваться с SOAP протоколом и всеми этими сертификатами.
Полностью вас понимаю! Сейчас мы движемся по пути постепенных улучшений — начали с протокола платежей, как наиболее востребованного и популярного. Протокол массовых выплат следующий на очереди. Как только будет готово — обязательно расскажем об этом публично :)
Есть какие-то таймлайны? Месяц-три-полгода-год?
Соориентировать по времени, к сожалению, пока что не могу, но если вы планируете начать новый проект на протоколе выплат, то лучше не откладывать его в ожидании нового API. Как только выйдет новый протокол — мы обязательно выпустим инструкцию по миграции для существующих пользователей.
Ок, спасибо! Будем ждать с нетерпением.

Вот, что о старом протоколе написано в документации:


Неактуальный протокол: работает и поддерживается, но новые пользователи к нему не подключаются. Позволяет принимать платежи через Яндекс.Кассу.

То есть, если я делаю новый магазин, то мне нужно разбираться в новом API несмотря на то, что у меня уже есть наработки для старого протокола?

Не хватает инструкции по миграции со старого протокола на новый API

Новый протокол в первую расчитан на наших новых клиентов. Если вы уже является пользователем Яндекс.Кассы — вы можете обратиться службу технической поддержки и вам заведут магазин на старом протоколе.

Сам я клиентом Кассы не являюсь, я делаю интеграцию с Кассой для организаций. Не уже ли я могу подключить новый магазин по старому протоколу?

Sign up to leave a comment.