О нас
Услуги
Почему мы
Mono Talks
Контакты
ENG
23 августа 2026
IC++ и blended: как выбрать ценовую модель процессинга
В этом материале разбираем модели ценообразования эквайринга карт, расскажем, в чем разница между типами комиссий и как реально формируется MDR для мерчантов.

Почему IC++ не означает дефолтную экономию и как процессоры зарабатывают на blended комиссии

В этой статье:

  • IC++ раскладывает комиссию на части: interchange, scheme fee, markup провайдера, а blended объединяет все в одну фиксированную ставку.
  • При blended провайдер сам платит за колебания interchange и заинтересован оптимизировать процессинг, при IC++ этот риск и стимул часто переходят на мерчанта.
  • IC++ раскрывает реальную экономию только при большом и разнородном объеме транзакций — на малом однородном потоке разница может не окупать административную нагрузку.

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

Индустрия давно навязала простой ответ на этот вопрос: IC++ прозрачен, значит выгоден, blended непрозрачен, значит невыгоден. Этот ответ повторяется настолько часто, что превратился в аксиому, которую редко кто-то проверяет цифрами. На практике это не всегда так, и разница между моделями раскрывается не в названии, а в том, как именно провайдер обрабатывает транзакции внутри выбранной структуры.

Поэтому, прежде чем требовать конкретную модель, стоит понимать, что именно вы получаете и чем реально рискуете в каждом случае. С этим сегодня и разберемся!

 

В чем отличие IC++ и blended

Модель blended pricing, наверняка знакома большинству мерчантов и чаще всего встречается у стартапов и высокорисковых бизнесов. В этом случае, провайдер берет единую комиссию за транзакцию — например, 2.9% плюс фиксированная часть вроде $0.30 — независимо от того, каким типом карты расплатился покупатель, из какой страны эта карта (чаще всего), и какой это тип транзакции: разовая покупка или рекуррент. Данная комиссия уже включает все издержки платежной системы на процессинг платежей, а также ее собственный заработок, формируя понятную одну цифру для мерчанта. Мерчант в этой модели обычно не знает, из чего в реальности складывается итоговая ставка, которую он платит.

IC++, в свою очередь, раскладывает эту же сумму на три отдельных компонента, где можно точно отследить, как формируется цена. Interchange fee уходит эмитенту карты — банку, который ее выпустил; Scheme fee самой платежной сети — Visa, Mastercard, Amex — за использование инфраструктуры маршрутизации и клиринга. И, наконец, markup — это то, что реально зарабатывает сам платежный провайдер за свою работу: гейт, риск-менеджмент, поддержку, интеграцию. В идеальной картине мира мерчант видит все три строки отдельно по каждой транзакции и понимает, где именно формируется его расход (комиссия PSP), а что из этого фиксировано платежной сетью и не подлежит переговорам в принципе.

Иногда встречается обозначение IC+ (один плюс) — это упрощенная версия, где markup и scheme fee объединены в одну строку, а отдельно показан только interchange. IC++ (два плюса) дает более полную разбивку. Разница кажется незначительной, но на практике именно в этом снижении прозрачности часто прячется дополнительная маржа провайдера.

 

Почему «IC++ дешевле» — не всегда правда

Есть устойчивый миф, что переход на IC++ автоматически снижает издержки, что это дешевле просто потому, что так гарантирует сама модель ценообразования; да и много мелких цифр лучше одной большой. Однако, фактически никакой гарантии нет, а есть лишь потенциал возможной экономии, который базируется на добавлении прозрачности в отчеты. Мерчант получает больше информации о своей комиссии за счет разбивки по статьям, однако она может в сумме быть точно такой же, как и при blended модели. Почему так?

В первую очередь, важно учесть серьезный операционный фактор, что в blended модели провайдер сам несет риск колебаний interchange, потому что именно он платит сети из своего кармана, а мерчанту выставляет фиксированную ставку независимо от того, как реально прошла транзакция. У него есть прямой финансовый интерес процессить транзакции максимально оптимально, потому что любой «даунгрейд» — когда транзакция обрабатывается неоптимально и попадает под более высокий interchange-тир, — бьет по марже самого провайдера. Если провайдер плохо настроил передачу данных или не использует нужные механизмы снижения риска, деньги теряет он сам, и у него есть стимул это исправить.

А вот при IC++ эта логика переворачивается в другую сторону, поскольку interchange списывается напрямую с мерчанта, у провайдера уже не остается столь сильного стимула оптимизировать процессинг — недоквалификация транзакции ничего не стоит ему самому, он просто передает разницу дальше по цепочке. А это на практике случается нередко, по сути являясь рутинной частью механики платежных сетей. Индустрия об этом знает, однако исправить все одним махом не получается, поэтому приходится проводить оптимизацию по ходу. К таким факторам относится наличие или отсутствие 3DS проверки, AVS, правильная разметка подписочных платежей и др.

Совокупно все эти факторы способны поднять реальный interchange на 30–50%, а иногда и больше относительно оптимальной ставки. При blended эту разницу покрывает провайдер, и мерчант о ней даже не знает. При IC++ мерчант технически видит эту сумму построчно, а также прямо оплачивает данную комиссию, что само по себе никак не делает ее меньше. Кроме того, чтобы компенсировать невысокий markup, платежные провайдеры могут в открытую требовать стабильного минимального объема по их каналам или ежемесячные фиксированные комиссии за обслуживание, что в итоге может стоить больше, чем стандартный blended тариф на объеме мерчанта.

В основном, «дешевизна» модели IC++ в глазах мерчантов обосновывается тем, что мерчант сможет увидеть реальный markup платежной системы, а не догадываться сколько зарабатывает PSP внутри одной общей цифры. Именно это знание можно использовать в переговорах о снижении комиссий, так как только данный пункт реально поддается манипуляциям. Провайдер, с которым у мерчанта слабая переговорная позиция — например, из-за небольшого объема или узкой ниши с повышенным риском — вполне может выставить крупный markup. Однако, в таких индустриях оправдано повышение комиссии и в открытую и мерчанты, долго работающие в рынке, про это знают. Прозрачность в этом смысле полезна, так как дает увидеть переплату, но не гарантирует, что ее не будет.

 

Частые ошибки мерчантов в этом процессе

Вооружившись этим знанием, мерчанты часто могут ориентироваться на получение определенной модели прайса, допуская ряд ошибок. Это например:

  • Приоритет модели ценообразование, а не качества провайдера. Форма ценообразования вторична по отношению к уровню самого процессинга, от которого будет зависеть общий процент одобрения транзакций, а следовательно, прибыльность бизнеса. Оптимизированный IC++ у сильного, технологически зрелого провайдера почти всегда выгоднее blended, однако, такие провайдеры доступны не всем и слепая гонка за отчетными данными не имеет практического смысла для бизнеса.
  • Игнорирование объема и профиля транзакций. IC++ раскрывает свое реальное преимущество на масштабе и при разнородном миксе карт — когда через мерчанта проходит много разных типов карт, разных стран, разных сценариев 3DS и типов транзакций вперемешку (что типично для цифровых подписок). Именно тогда построчная детализация показывает, где конкретно теряются деньги, а на низком объеме и однородном потоке разница между моделями может быть статистически низкой, а административная нагрузка на разбор построчных отчетов — не окупится вовсе.
  • Сравнение markup без учета дополнительных фикс-платежей. Если вместе с IC++ появляется ежемесячная плату за обслуживание счета, минимальные объемные требования или отдельная плату за доступ к детализированной отчетности — сравнивать нужно полную стоимость владения реалистично, а не изолированный процент markup, который выглядит привлекательно только на бумаге.
  • Игнорирование сезонности и волатильности interchange. Ставки interchange не статичны — они периодически пересматриваются платежными сетями; при blended эта волатильность незаметна, тогда как при IC++ она сразу появляется у мерчанта. Это не является сразу негативным фактором, однако лишает простоты финансовое планирование, поскольку всегда нужно понимать, что, что расходы на процессинг могут быть не такими предсказуемыми месяц к месяцу.

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

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

IC++ требует от PSP более зрелой технической инфраструктуры: построчную разбивку per-transaction по каждому типу карты, каждой стране, каждому тиру, с постоянным обновлением по мере изменения ставок платежных сетей. Не каждый провайдер, особенно менее крупный и технологически развитый, готов инвестировать в такую инфраструктуру ради сегмента мерчантов, которые в моменте не приносят достаточного дохода. Кроме того, IC++ делает провайдера более уязвимым перед конкуренцией на markup — раз мерчант видит эту цифру отдельно, ее проще сравнивать между провайдерами и требовать снижения на переговорах, тогда как внутри blended-ставки конкурентное давление размывается за общей цифрой, которую сложнее сопоставить один в один между разными предложениями.

Поэтому IC++ исторически доступна для мерчантов с большим объемом и переговорной силой: крупный игрок может продавить у провайдера не только саму модель ценообразования, но и адекватный markup внутри нее, опираясь на объем и наличие альтернативных предложений от ряда конкурентов.

 

Что с этим делать мерчанту

Главный практический вывод — не гнаться за формой ради формы и не воспринимать название модели как самостоятельный показатель выгоды. Прежде чем требовать IC++ у провайдера, стоит трезво оценить достаточен ли объем и достаточно ли разнороден транзакционный поток, чтобы построчная прозрачность была практически полезна. Готова ли у мерчанта финансовая и риск-команда — регулярно анализировать построчные отчеты, выявлять пробелы, а также реагировать на них.

Blended — не обязательно плохой или устаревший выбор для небольшого и однородного бизнеса, где административная простота и предсказуемость расходов важнее точечной экономии на interchange, которую все равно не будут учитывать. А IC++ — не автоматическая победа, если markup непрозрачен или у мерчанта просто нет ресурса извлекать пользу из детализации, которую он получает.

Форма для связи
*
*
*
Сообщение отправлено Мы свяжемся с Вами в течение одного рабочего дня
Закрыть
Еще больше интересного
Платежные системы
Новости финтеха
Интервью
Запрос услуг
Сотрудничество и реклама
Вся информация на нашем сайте предназначена исключительно для ознакомительного пользования и не является консультацией. Администрация сайта оставляет за собой право вносить изменения в текст и изображения на свое усмотрение, а также удалять информацию из публикации. Мы делаем все возможное, чтобы информация на этом сайте была как можно более полной и точной. Администрация сайта monoup.com не несет никакой ответственности за любой ущерб, который может быть причинен в любой форме за счет использования, неполноты или неправильности информации, размещенной на этом сайте.
Информация и любой материал на этом сайте может быть изменен без предварительного уведомления пользователей.