Comments 57
Вот бы ещё лёгкий (дешёвый) способ онлайн-чек клиенту послать (и в ОФД данные отправить).
А то по сравнению с так называемыми онлайн-кассами(чеки/ОФД), весь этот экваиринг вообще не проблема :)
ФК где то разбирали и на сколько я помню это флешка с батарейкой, для поддержания непрерывности дат операций. Т.к. на кассе время может сбиться или криво выставлено. Не будет этого накопителя, который работает только в режиме одноразовой записи, в периоды офлайна можно продавать что и как угодно, а перед синхронизацией поправить.
Либо можно банально потерять данные, т.к. касса периодически перепрошивается.
Для моего в общем то мелкого бизнеса, заплатить 24тыр раз в три года это незначительные траты. К тому же в некоторых налоговых режимах их можно учесть в налогах как затраты.
В Украине у нас так. По API в XML посылаются чеки. С 1 января 2022 года для ФЛП обязательно или физически ставить или программно.
В России оно тоже есть, но не от налоговой, а от каких-то операторов посредников и за него надо платить.
Да, именно от налоговой. И бесплатное. Но API как-бы не такое простое. Поэтому у нас тоже есть прослойки или сервисы, которые платные. Ну там интеграция с 1С и все такое.
Хотя налоговая сделала простенькую программку для ПК и для Android, то есть в принципе, предприниматель может бесплатно фискализировать чеки.
Вот сейчас тоже пишу API для других разработчиков и предпринимателей.
Ну как-бы есть еще проблемы. У нас министр IT написал такое API(Checkbox), было 15k клиентов(сейчас это самый большой сервис). 250k чеков в день. Потом под конец года(с 2022 штрафы, поэтому все ринулись регать кассы). Я так понял, что стало где-то в 2 раза больше. И у них тупо не справились сервера! Началось 28-го числа, исправили где-то 2-го числа. А последствия до сих пор. Затраивались чеки, короче был капец.
И в налоговой под конец года иногда кассы не регистрировались. Иногда сервер налоговой ложится.
В налоговой есть вообще 2 API. Первое(Единое окно) — это XML и там формат где-то такой:
<?xml version="1.0" encoding="windows-1251"?>
<CHECK xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="check01.xsd">
<!--Заголовок-->
<CHECKHEAD>
<!--Тип документа (числовий):-->
<!--0-Чек реалізації товарів/послуг, 1-Чек переказу коштів, 2–Чек операції обміну валюти, 3-Чек видачі готівки,
100-Відкриття зміни, 101-Закриття зміни, 102-Початок офлайн сесії, 103-Завершення офлайн сесії-->
<DOCTYPE>0</DOCTYPE>
<!--Розширений тип документа (числовий):-->
<!--0-Касовий чек (реалізація), 1-Видатковий чек (повернення), 2-Чек операції «службове внесення»/«отримання авансу»,
3-Чек операції «отримання підкріплення», 4–Чек операції «службова видача»/«інкасація»...-->
<DOCSUBTYPE>0</DOCSUBTYPE>
<!--Унікальний ідентифікатор документа (GUID)-->
<UID>F32EE0EF-F8EE-46BD-9943-881AF3F982F5</UID>
<!--ЄДРПОУ/ДРФО/№ паспорта продавця (10 символів)-->
<TIN>12345678</TIN>
<!--Податковий номер або Індивідуальний номер платника ПДВ (12 символів)-->
<IPN>123456789012</IPN>
<!--Найменування продавця (256 символів)-->
<ORGNM>ТОВ "ФОЗЗІ-ФУД"</ORGNM>
<!--Найменування точки продажу (256 символів)-->
<POINTNM>магазин "СІЛЬПО"</POINTNM>
<!--Адреса точки продажу (256 символів)-->
<POINTADDR>вул. Дніпровська набережна, 33</POINTADDR>
<!--Дата операції (ddmmyyyy)-->
<ORDERDATE>18112015</ORDERDATE>
<!--Час операції (hhmmss)-->
<ORDERTIME>201543</ORDERTIME>
<!--Локальний номер документа (128 символів)-->
<ORDERNUM>12345678</ORDERNUM>
<!--Локальний номер реєстратора розрахункових операцій (64 символи)-->
<CASHDESKNUM>19</CASHDESKNUM>
<!--Фіскальний номер реєстратора розрахункових операцій (128 символів)-->
<CASHREGISTERNUM>012345678901</CASHREGISTERNUM>
<!--ПІБ касира (128 символів)-->
<CASHIER>Семко А.М.</CASHIER>
<!--Версія формату документа (числовий)-->
<VER>1</VER>
<!--Фіскальний номер документа (128 символів)-->
<ORDERTAXNUM>101234567890123</ORDERTAXNUM>
</CHECKHEAD>
<!--Підсумок по чеку-->
<CHECKTOTAL>
<!--Загальна сума (15.2 цифри)-->
<SUM>417.66</SUM>
</CHECKTOTAL>
<!--Реалізація-->
<CHECKPAY>
<ROW ROWNUM="1">
<!--Код форми оплати (числовий):
0–Готівка, 1–Банківська картка, 2-Попередня оплата, 3-Кредит, ...-->
<PAYFORMCD>0</PAYFORMCD>
<!--Найменування форми оплати (128 символів)-->
<PAYFORMNM>ГОТІВКА</PAYFORMNM>
<!--Загальна сума (15.2 цифри)-->
<SUM>317.66</SUM>
<!--Сума внесених коштів (15.2 цифри)-->
<PROVIDED>400.00</PROVIDED>
<!--Решта (не зазначається, якщо решта відсутня) (15.2 цифри)-->
<REMAINS>82.34</REMAINS>
</ROW>
<ROW ROWNUM="2">
<!--Код форми оплати (числовий):-->
<!--0–Готівка, 1–Банківська картка...-->
<PAYFORMCD>1</PAYFORMCD>
<!--Найменування форми оплати (64 символи)-->
<PAYFORMNM>КАРТКА</PAYFORMNM>
<!--Загальна сума (15.2 цифри)-->
<SUM>100.00</SUM>
</ROW>
</CHECKPAY>
<!--Податки/Збори-->
<CHECKTAX>
<ROW ROWNUM="1">
<!--Код виду податку/збору (числовий):-->
<!--0-ПДВ,1-Акциз,2-ПФ...-->
<TYPE>0</TYPE>
<!--Найменування виду податку/збору (64 символи)-->
<NAME>ПДВ</NAME>
<!--Літерне позначення виду і ставки податку/збору (А,Б,В,Г,...) (1 символ)-->
<LETTER>A</LETTER>
<!--Відсоток податку/збору (15.2 цифри)-->
<PRC>20.00</PRC>
<!--Ознака податку/збору, не включеного у вартість-->
<SIGN>false</SIGN>
<!--Сума для розрахування податку/збору (15.2 цифри)-->
<TURNOVER>2583.78</TURNOVER>
<!--Сума податку/збору (15.2 цифри)-->
<SUM>59.63</SUM>
</ROW>
<ROW ROWNUM="2">
<!--Код виду податку/збору (числовий):-->
<!--0-ПДВ,1-Акциз,2-ПФ...-->
<TYPE>0</TYPE>
<!--Найменування виду податку/збору (64 символи)-->
<NAME>ПДВ</NAME>
<!--Літерне позначення виду і ставки податку/збору (А,Б,В,Г,...) (1 символ)-->
<LETTER>Б</LETTER>
<!--Відсоток податку/збору (15.2 цифри)-->
<PRC>7.00</PRC>
<!--Ознака податку/збору, не включеного у вартість-->
<SIGN>false</SIGN>
<!--Сума для розрахування податку/збору (15.2 цифри)-->
<TURNOVER>63.27</TURNOVER>
<!--Сума податку/збору (15.2 цифри)-->
<SUM>1.43</SUM>
</ROW>
</CHECKTAX>
<!--Продажі-->
<CHECKBODY>
<ROW ROWNUM="1">
<!--Внутрішній код товару (64 символи)-->
<CODE>98765</CODE>
<!--Код товару згідно з УКТЗЕД (15 цифр)-->
<UKTZED>876543</UKTZED>
<!--Найменування товару, послуги або операції (текст)-->
<NAME>Куряче Стегно</NAME>
<!--Код одиниці виміру згідно класифікатора (5 цифр)-->
<UNITCD>25</UNITCD>
<!--Найменування одиниці виміру (64 символи)-->
<UNITNM>кг</UNITNM>
<!--Кількість/об’єм товару (15.3 цифри)-->
<AMOUNT>5.701</AMOUNT>
<!--Ціна за одиницю товару (15.2 цифри)-->
<PRICE>52.30</PRICE>
<!--Літерні позначення видів і ставок податків/зборів (15 символів)-->
<LETTERS>A</LETTERS>
<!--Сума операції (15.2 цифри)-->
<COST>298.16</COST>
</ROW>
<ROW ROWNUM="2">
<CODE>76543456</CODE>
<UKTZED>543210</UKTZED>
<NAME>Пиво</NAME>
<UNITCD>87</UNITCD>
<UNITNM>бут</UNITNM>
<AMOUNT>6</AMOUNT>
<PRICE>16.50</PRICE>
<LETTERS>Д</LETTERS>
<COST>99.00</COST>
</ROW>
<ROW ROWNUM="3">
<CODE>76543123</CODE>
<UKTZED>876543</UKTZED>
<NAME>Сироп від кашлю</NAME>
<UNITCD>87</UNITCD>
<UNITNM>бут</UNITNM>
<AMOUNT>1</AMOUNT>
<PRICE>20.50</PRICE>
<LETTERS>Б</LETTERS>
<COST>20.50</COST>
</ROW>
</CHECKBODY>
</CHECK>А есть API GRPC, там XML, но совсем другой формат. Но в первом(Единое окно), есть нормальная проверка данных.
А в GRPC — ее нет в принципе. Можно отправить отрицательную сумму, итоговая сумма в чеке не проверяется.
А Единое окно — это вообще старое API для физических кассовых аппаратов. То есть на Единое окно отправляются сразу с программных касс и с физических. А GRPC вообще не понятно зачем, если толком не работает.
А еще больший прикол, что эти два API не соединены! Я могу открыть смену в 2-х API сразу, и там вообще маркировка номера чека другая(в GRPC — буквенная, а в Едином окне — цифровая).
Вот прямо сейчас, пока пишу, налоговый сервер упал. Хотя сейчас уже редко падает. Да и там только часть запросов может не обработаться.
Конечно, скоро все наладится, но пока не все ОК
Непонятно почему его не поддерживали раньше приложения для юридических лиц и ИП.
Это Вы сгоряча… кто то поддерживает, кто то нет. Как банк заказчик закажет.
Ну и наверное потому что нет единого стандарта как на QRС так и нет единого «Расчетного Центра Оплаты» (слишком жирный это кусок и есть конкуренция)
Вот «стукнет кулаком по столу» «государство» и прикроет все варианты как с «карта Мир» (локальные Платежные Системы) или СБП (разные системы переводов)
И будем ходить строем и по линейке.
То что Вы привели — это один из вариантов кодирование реквизитов в QRC.
Каждый поставщик услуг придумывает свой вариант кодирование в строке.
Я минимум 5 вариантов видел…
Может эти 5 вариантов и есть. Но тот QR-код, что я привёл работает у большинства.
И при чём тут расчётный центр, если речь про обычные платёжные поручения по безналу?
Никто безнал не отменит.
Может эти 5 вариантов и есть. Но тот QR-код, что я привёл работает у большинства.
Большинство — это кто? Московские ЖЕУ, МосГорводоканал? (условно)
Как не былое единого стандарта, так и нет.
Пол года… Я этого слона уже лет 8 со всех сторон ощупываю. Да и не только в одном «главном» регионе РФ :)
И при чём тут расчётный центр, если речь про обычные платёжные поручения по безналу?
Никто безнал не отменит.
ЭЭэх. выставление реквизитов платежа — это очень маленькая часть «слона» платежей физ лицам юр.лицам.
Например, расчетный Центр берет на себя такие функции как отправка реестров платежей поставщику Услуги в нужном (понятном его ПО формате/протоколе).
Расчетным центром может выступать сам банк или финтех организация.
У нас расчётный центр мы сами. Сами счета генерим, сами обрабатываем выписки из банка. Это любому посильно.
И мы хотим, чтобы QR-коды были везде. Так очень удобно платить.
Приложения банков поддерживают.
Тинькофф, Точка и Модуль уже реализовали
Ну поддержали. От этого ЭТОТ доморощенный вариант с конкретными разделителями полей "|" и с конкретными именами полей не стал стандартом.
Даже глядя вот на пример я вижу его «домрощенность»:
- Длинные имена полей
- Не понятные правила маскирования символов разделителей
- Потенциальные проблемы с кодировкой (UTF8?)
QRC не резиновый… версия 40 QRC — это либо большой физический размер, либо не всякая железка его прочитает.
Типично версия 10, а это всего 119 байт. Всего!
И в космос вон летают аварии случаются. Не летать? И на дорогах ДТП. Не ездить?
Даже если вдруг так случится, что у клиента QR-код не распознается по какой-то причине, ну допустим даже QR-код верный, а приложение Сбера у него, то нет в этом проблемы глобальной. Она локальная. Клиент пойдёт либо руками вводить реквизиты, либо банк сменит, либо картой оплатит. Но зато при этом у остальных клиентов будет счастье.
А когда клиент сразу видит выставленные ему платежи в ДБО на мобильнике и оплачивает их прямо там.
А бумажные квитанции с реквизитами счетов для оплаты и пр. должны умереть IMHO. Это не просто из прошлого века… А из середины прошлого века. И QRC на них это «как зуб во рту прокаженного»
Какая разница где клиент это видит? И при чём тут бумажные квитанции?
У нас клиент видит всё в электронном виде в ЛК или в своей почте. Наводит смартфон на дисплей и платит. Нужно дисплей иметь. Да, тут косяк, что приложения банковские камерой предлагают сканировать.
Но сейчас задам в поддержку вопрос.
Бесплатный сыр только в мышеловке. В Сбере комиссия за безнал от фл на юл такая же, как и при оплате другими способами. В ВТБ тоже комиссия. В ПСБ на премиальных тарифах можно и без комиссии, но там внимание! есть комиссия у юл на входящие платежи от фл. Более того банк отправитель платит Центробанку за каждый платеж из этого банка в другой банк и банк отправитель уж точно платить из своего кармана не будет. Скорее всего ваш случай частный и касается только платежей фл на счёт юл в том же банке.
П.С. Работаю в банковской сфере в ИТ с 2004 года.
Про входящую комиссию тоже дичь. Она есть в виде специфических тарифов 1% на все входящие. Но на любом нормальном тарифе нет комиссий за входящие платежи.
Комиссия за безнал от физика к юрику логически глупа. Физк берёт тогда карту и платит картой. Ну или уходит в другой банк, где это бесплатно.
Ну да, путаю. А комиссию при оплате за квартиру по реквизитам (без договора у ТСЖ), они просто так каждый раз берут. Случайно.
Я написал уже, что банк платит Центробанку за каждый платеж, проходящий через корсчет банка в Центробанке. Бесплатно идут только бюджетные платежи - налоги. Банк не будет перечислять вам бесплатно, а сам при этом платить.
Про входящий платеж перепутал. В ПСБ комиссия за входящий платеж при платеже от ИП в пользу фл.
Сам работал в 2-х средних банках. Там тоже комиссии на платежи фл в пользу юл. Бесплатно только если оба клиента в банке обслуживаются и деньги через корсчет не нужно гнать.
Если физик платит картой, то расчеты идут не через Центробанк, не через корсчет, а через процессинг типа виза, мастеркард. Там банки берут комиссию с получателя (и делятся с процессингом). Это называется эквайринг. Для юл с оборотами до 1 млн в месяц комиссия примерно 2-3%. Для сравнения сбп комиссия максимальная 0,7%
Не знаю зачем платить, если просто дофига банков, которые не берут.
Копейки он платит. У юрика 19р платёжка стоит. Банк платит наверное рубль.
Вы и сейчас путаете. Пишите за входящий, а речь об исходящем.
Есть банки, которые не берут. Их мало. А есть лайфхак. Выводите с ИП на биржу, а с бирже уже себе. :)
Ну ваши два банка брали. Они средние. Пройдитесь по ТОП-30 и больше половины комиссию не берут.
Вижу наша беседа бессмысленна. Вы не воспринимаете информацию даже от людей, знающих кухню изнутри. Вас уже просили привести конкретный перечень банков без комиссии. С удовольствием все их рассмотрят. Но пока ни один не озвучен.
Этих двух крупных банков достаточно?
В СМП тоже нет. Банк немаленький.
Вы получили удовольствие?
И вас в яндексе забанили? «банки, которые не берут комиссию за перевод по реквизитам»
www.sravni.ru/text/2019/4/23/5-kart-s-besplatnym-perevodom-deneg-po-rekvizitam
Тарифы СМП Банка, смотреть п.24
smpbank.ru/upload/iblock/2b3/2b3a00b512014aee87df7b48354185b3.pdf
0,6 % от суммы перевода (мин. 50 рублей – макс. 1 000 рублей)
В тинькове действительно бесплатно на всех тарифах, кроме тарифа ТПС 8.0. Но это скорее исключение из правил. Банк ведёт агрессивную политику в части привлечения клиентов. Но отзывов негативных о них полно в интернете. Не каждый будет в этом банке обслуживаться.
Всегда есть НО почти у всех банков. Естественно на каждом заборе будут кричать про бесплтно, а почему «бесплатно» не будут говорить, пока сами не поймёте, что денежки то утекают в другом месте.
Вот по вашей ссылке есть ещё ВТБ с мультикартой, где написано, что при платежах в 5 тысяч возврат комиссии. Только вот в тарифах (https://www.vtb.ru/-/media/Files/personal/karty/multikarta/paket-uslug_dk-multikarta.pdf п 8.1.1.2) на сайте банка есть мааленькая сноска и в этой сноске ссылка на пункт 5.3, где указано, что это действует только для зарплатных клиентов, а не на всех. Есть правда у них ещё и премиальные тарифы, но там условия существенно больше 5 тысяч и конечно банк просто зарабатывает в этом случае на другом.
В целом везде есть условия (скрытые или нет) по которым банк называет «бесплатно», а по факту ни о какой бесплатности речи не идёт.
Если фразу про мышеловку и сыр переписать как "бесплатных завтраков не бывает, просто за них платит кто-то другой", то это объяснит позиции обоих спорщиков (мне так кажется)
Большинство — это кто? Московские ЖЕУ, МосГорводоканал? (условно)
Как не былое единого стандарта, так и нет.
Вроде бы тот код, что описан — это ГОСТ Р 56042-2014. Не так чтобы единый, но вполне стандарт. Хотя и корявый, предназначенный просто для облегчения заполнения полей платежки.
1 Наименование получателя платежа
Строка от 1 до 160 знаков
Увы. ГОСТ то же пишут люди.
Никто похоже даже не пытался из них распечатать версию 40 QRC и запихнув туда всю эту «колбасу» из данных попробовать отсканировать в разных разрешениях, напечатанную на бумаге.
Мы такие эксперименты проводили. Правда с СБП QRC (где еще логотип внутри).
Но там обычный url кодируется (с ID платежа и минимум доп инфы) и проблем нет.
Ну, да. Понятно что весь этот стандарт — это просто попытка облегчить уже существующий вариант 'заполнить платежку'. Скажем, для чего там нужно одновременно ""Наименование банка получателя платежа" и БИК и корреспондентский счет — не очень понятно.
Не могут. Банк может иметь несколько корсчетов, например открытых для кредитно кассовых офисов даже в другом регионе. При этом БИК будет единый, ибо кко это не филиал и ему отдельный БИК не положен. Просто в повседневной жизни это редко используется (я не встречал), обычно такие корсчета нужны только для работы с наличкой (головной банк через корсчета отправляет средства в кко, а там кассиры едут в местное отделение ЦБ и снимают с этого счета кэш в кассу).
А выкинуть БИК и название, оставив только корсчет? Я так понимаю, несколько банков одним пользоваться не могут?
Ну и вопрос по описанию — банк, который отправляет денег, без указания всего этого в платежке никак не может разобраться, каким именно в данном случае корсчетом пользоваться надо, посмотрев на остальные поля?
[режим нытья] и вот не судьба ввести международные IBAN, утолкав всю нужную информацию в один номер [/режим нытья]
что лучше при ошибке в одной цифре? И не важно почему — бумажка испачкалась, фотокамера глюкнула, программа в мобилке глюкнула, процессор/память в мобилке глюкнул, интернет между мобилкой и банковским сервером глюкнул, антивирус/IDS на входе в банковский сервер глюкнул, процессор/память в банковском сервере глюкнули… а на самом деле я упрощаю и ряд промежуточных шагов уже выкинуть, и всё равно много остаётся — вот по любой этой причине, ошибка в одной цифре коррсчёта или любого другого единственного идентификатора
1) тут же получить ошибку, платёжка кривая, к/с и БИК «не бьются»?
2) отправить деньги неизвестно кому, а потом тратить силы выцарапать их обратно (и то, если ещё вовремя сумеете заметить, что они ушли «на деревню дедушке)?
избыточность данных — это в том числе защита от ошибок
что лучше при ошибке в одной цифре?
Для этих целей уже давным-давно кодирование с обнаружением и исправлением ошибок придумано. И то что соответствующих контрольные суммы (нет, не по алгоритму Луна, а более качественные) в номерах счетов и прочих подобных идентификаторах не используются — это сильно зря.
Там есть контрольные суммы в этих номерах для этого.
У меня таких, все местные конторы, правда их самих не так много осталось.
Только вот реально QR-коды для безнала:
с точки зрения разработчика:
- могут быть вовсе даже не QR а Aztec-code, да и с QR там несколько вариантов кодирования есть.
- текст на русском может быть закодирован любой из существующих кодировок русского языка (и проще сделать 5 раз перекодировку и пробовать частотный анализ)
с точки зрения пользователя:
- то что QR-код на квитанции есть — это еще не значит что после платежа по ней получатель не скажет что не видели платежа, и давайте платежку руками будем смотреть и вообще надо было нормально платить (потому что считают поле назначение платежа надо дословно копировать из квитанции но в QR-коде на этой же квитанции — заполнили криво)
могут быть вовсе даже не QR а Aztec-code, да и с QR там несколько вариантов кодирования есть.
Поясните на что это влияет. Достаточно одного варианта, который приведён. Его пока только Сбер не понимает.
Про текст тоже непонятно. Может и может. Но у нас в UTF-8 и проблем не было.
И с зачислением проблем не было, отлично там назначение платежа подставляется. Главное не превышать допустимый размер, у нас ограничено в 160 символов. И платежи распознаются по номеру договора и плательщику. Так что даже если вдруг будет проблема с кодировкой, даже если номер договора вдруг клиент ручками исправит на неправильный, то для юрлиц и ИП есть ИНН, а для физиков ФИО, которое скорее всего уникально в рамках небольшого количества клиентов малого бизнеса.
Поясните на что это влияет. Достаточно одного варианта, который приведён. Его пока только Сбер не понимает.
Что очень странно, потому что соответствующий стандарт Сбербанк и продвигает. То что описано — чем-то отличается или я как-то не так статью понял?
@itsoft, заметил, что если в Вашем QR-коде поменять порядок следования полей, то он будет нормально работать и в приложении Сбера. Порядок вот такой:
ST00012|Name={Name}|PersonalAcc={PersonalAcc}|BankName={BankName}|BIC={BIC}|CorrespAcc={CorrespAcc}|KPP={KPP}|PayeeINN={PayeeINN}|Purpose={Purpose}|Sum={Sum}|Contract={Contract}
Поясните на что это влияет. Достаточно одного варианта, который приведён. Его пока
Про текст тоже непонятно. Может и может. Но у нас в UTF-8 и проблем не было.
Если мы — организация которая хочет получать оплату — наверно достаточно.
Если мы — мобильное приложение банка через которое оплата то тут начинаются проблемы.
Просто взгляд с чуть другой стороны.
Либо топик стартер не пояснил чем его это решени5 сбера не устраивает, либо вообще не пользуется поиском
А какие банки не берут комиссию за перевод безналом?
А первый — это просто оплата по обычным банковским реквизитам — распознавание реквизитов для платёжного поручения (ГОСТ Р 56042-2014).
… В большинстве нормальных банков платежи по безналу для физиков бесплатные.
Правильно ли я понимаю, что тут нужен специальный договор с банком, типа договора эквайринга?
Второй — это мгновенная оплата типа того же интернет-эквайринга по картам через систему быстрых платежей (СБП) ...
- переводы немоментальные, что резко сужает область применения;
- это не покупка, а перевод, при оплате с кредитного счёта клиент «попадёт» на комиссию (обычно как за снятие наличных) и будет очень недоволен;
- далеко не везде исходящий межбанк бесплатен и с дебетовых счетов.
2. Так не надо оплачивать с кредитного. Вообще лучше кредитных счетов не иметь.
3. См. выше. Достаточно банков где он бесплатный. Не надо кормить жлобские банки.
не могу согласиться ни с одним пунктом
Для наших услуг дата-центра отлично подходит
вот именно, что для вас подходит, и, пожалуй, всё.
кроме коммунальных услуг и хостинга мне не приходит в голову примеров периодических трат (когда деньги нужно отправить к определённой дате).
представляю, делаю заказ в условной пиццерии, отправляю перевод в пятницу вечером, в понедельник он исполняется, после обеда они видят деньги и вечером привозят мне свежую пиццу.
Вообще лучше кредитных счетов не иметь.
почему это?
разумеется, использование кредитов в формате «сниму-ка я 10 тысяч до зарплаты с кредитки, пофиг на комиссии и проценты» или «возьму-ка я вон тот красивый айфон в кредит, ну и что, что он стоит как 4 мои месячные зарплаты» ведёт в никуда.
но это не значит, что на кредитные деньги нужно наложить табу.
конечно, сейчас не те благословенные времена, когда можно было держать деньги по 10% на дебетовом счёте, расплачиваясь везде кредиткой и погашая в грейс (то бишь берём деньги у одного банка в долг без процентов, кладём в другой /или тот же/ под проценты); оно работает и сейчас, но с сегодяшними 3.5% это совсем не интересно.
но всё равно при прочих равных я скорее оплачу кредиткой.
во-первых, всё равно деньги не надо отдавать прямо сейчас (а может и вообще не надо — например, жена может набрать товара в вайлдбериз на 60к, перемерить и вернуть всё — зачем мне за это платить с дебетовой карты?);
во-вторых, по кредиткам зачастую кэшбек больше.
если абстрагироваться от кредиток, есть и другие примеры полезных кредитов. все мои знакомые, что брали квартиры в ипотеку, заплатили за эти квартиры с учётом выплаченных процентов меньше, чем эти квартиры стоят сейчас.
то есть если бы они копили это время на квартиру, им пришлось бы всё это время ютиться в сьёмном жилье (платить деньги за это съёмное жильё), и они, скорее всего, так и не накопили бы на своё.
про кредиты и бизнес отдельный разговор, не буду касаться этой темы.
Достаточно банков где он бесплатный. Не надо кормить жлобские банки.
достаточно. но мне приятнее заплатить с кредитки в грейс и с кэшбеком (и получить моментальное пополнение счёта!), чем платить даже бесплатным банковским переводом.
да, хостер экономит на отказе от эквайринга, но если он не транслирует эту скидку мне, то зачем мне кормить жлобских хостеров? )
Приём платежей по QR-кодам без комиссий