Банковский маркетплейс — витрина товаров и услуг внутри интернет-банка и мобильного приложения, а не отдельный агрегатор вроде витрины сравнений. Клиент выбирает страховку, связь, билеты или рассрочку там же, где лежат карта и счёт, и платит в контуре банка. Self Cube собирает такую витрину как модуль экосистемы, а не как баннер на чужой сайт. Имеет смысл отличать его от «банка для селлеров маркетплейсов»: здесь банк держит полку для своего клиента, а не расчётный счёт магазина. Если оплата уводит человека из приложения, это уже не встроенный маркетплейс.

Клиент не уходит платить на сторону, банк зарабатывает на нефинансовых и околофинансовых услугах и держит частоту входа в приложение — не только «проверить баланс». Экосистема в канале ДБО снижает отток в чужие сервисы и даёт данные для персональной полки. Имеет смысл считать не только комиссию с заказа, но и стоимость удержания клиента в канале. Если витрина живёт отдельно от карты и счёта, эффект обычно слабый: человек всё равно уходит. Встроенная оплата и рекомендации по транзакциям как раз это связывают.

Не только товары. На полке рядом стоят страхование, связь, путешествия, билеты, подписки, сертификаты, рассрочка и банковские продукты. Ассортимент собирают под сценарий клиента, а не под один тип SKU. Имеет смысл заранее решить, что банк готов продавать как принципал, что — как витрина партнёра, и какие данные партнёру вообще видны. Если смешать это без кабинета и правил, комплаенс и поддержка разъедутся. Self Cube как раз разделяет витрину, оплату в контуре банка и кабинет партнёра.

Оплата идёт картой и счётом клиента в контуре банка, без обязательной кассы партнёра как отдельного шага и без выгрузки ядра клиента наружу. Партнёр видит ассортимент, акции, конверсию и продажи, а не полный профиль и транзакционную историю. Имеет смысл проверить, где хранится платёжный сценарий и кто является мерчантом. Если клиент вводит реквизиты на чужом домене, это уже не встроенная оплата. Для банка это ещё и вопрос частоты мошенничества: чем короче путь, тем меньше точек подмены.

Клиент подтверждает покупку теми же картой и счётом, которыми уже пользуется в ДБО. Отдельный эквайринг партнёра как обязательный шаг не нужен — иначе человек снова уходит из приложения. Рассрочка и банковские продукты на этой же полке могут закрываться тем же контуром, а не второй кассой. Имеет смысл заранее описать возвраты, отмены и спорные операции: они должны идти по банковским правилам, а не по «как получится у партнёра». Если этого контура нет, витрина выглядит красиво, а поддержка тонет в ручных сверках.

Полка собирается по транзакционному поведению и профилю клиента, а не как случайный баннер «всем одно и то же». Интеллектуальный слой смотрит, чем человек уже пользуется, и предлагает смежные услуги в том же приложении. Имеет смысл ограничить, какие события можно использовать для рекомендации и как клиент это отключает. Если рекомендации строят только по кликам баннера, персонализации нет. Связь с реальными операциями как раз отличает банковскую витрину от обычной рекламной сетки.

Кабинет партнёра показывает ассортимент, акции, конверсию и продажи по его полке. Ядро клиента, полный профиль и чужие продукты банка туда не отдают. Это условие, без которого маркетплейс превращается в выгрузку базы. Имеет смысл отдельно прописать, какие агрегаты можно отдать для сверки и с какой задержкой. Если партнёр требует сырые транзакции «для аналитики», это уже другой договор и другой риск. Self Cube держит границу: партнёр управляет витриной, банк — клиентом.

Готовые коннекторы к электронной коммерции, логистике, страхованию и телекому сокращают срок до недель, а не до отдельного года на витрину с нуля. Срок растёт, если у партнёра нет стабильного каталога, цен и статуса заказа по API. Имеет смысл на входе проверить не «логотип готов», а контракт: ассортимент, оплата, возвраты, кабинет. Баннер без API в контур не берут — это не интеграция. Пилот лучше начинать с одной категории, где поток и сверка понятны.