Прием платежей SaaS СНГ в 2026 году упирается не в код биллинга и не в дизайн чекаута. Запрос «прием платежей SaaS СНГ» почти всегда маскирует три отдельные задачи: юрлицо, счет и шлюз, и пока они не собраны в одну цепочку, никакой Checkout не спасет продукт. Упирается все в инфраструктуру. Stripe для SaaS не открывается на паспорт гражданина России, Беларуси, Казахстана, Узбекистана, Кыргызстана, Армении или Украины как на самостоятельную юрисдикцию мерчанта. Платформа требует компанию в поддерживаемой стране, корпоративный счет для выплат и сайт, который выдерживает комплаенс-проверку. Без этой тройки подписка Stripe нерезидент остается красивой идеей в Figma, а не работающим рекуррентным списанием.
Рабочая связка компания Stripe счет, которую мы в Giru собираем под ключ для разработчиков и фаундеров, выглядит так: LLC в США в штате Вайоминг, корпоративный счет Mercury и официальное подключение Stripe. На этой базе запускаются Stripe Billing, Stripe Checkout SaaS, in-app платежи, B2B-инвойсы, пробные периоды, дуннинг и защита от чарджбэков. Mercury для стартапа закрывает долларовый контур. При необходимости рядом ставится Payoneer как второй канал выплат, а PayPal - как альтернативная кнопка на чекауте, а не как замена биллингу.
Эта статья написана как операционный гайд, а не как обзор «платежек для стартапа». Здесь разобрано, как принимать платежи за приложение легально, какие документы готовить до заявки, как проходит KYC, почему VPN и арендованные аккаунты Stripe уничтожают бизнес, чем Вайоминг отличается от маркетинговых мифов про другие штаты, когда британская LTD вообще имеет смысл, как устроены налоги LLC и какие формулировки на сайте чаще всего приводят к заморозке выплат. Если нужно пройти путь целиком, а не собирать его из форумных советов, начните со страницы подключения Stripe.
Почему SaaS из СНГ не может «просто открыть Stripe»
Stripe - это не виджет оплаты. Это лицензированный платежный агрегатор, который несет ответственность перед Visa, Mastercard, American Express и регуляторами за каждого мерчанта. Поэтому вопрос «открыть Stripe для стартапа» для нерезидента из СНГ всегда начинается с юрисдикции, а не с API-ключей.
Прямая регистрация на локальное ИП, ТОО, ООО или физлицо из неподдерживаемой страны отклоняется на онбординге. Система сверяет страну выпуска документа, заявленный адрес бизнеса, банковские реквизиты и цифровой след. Несовпадение любого из этих слоев подсвечивается риск-скорингом. Попытка обойти проверку через VPN, чужой адрес, номинальный аккаунт знакомого в США или «готовый Stripe за процент с оборота» заканчивается не «небольшим риском», а перманентной блокировкой и удержанием средств.
Для SaaS это особенно болезненно. Подписочная выручка выглядит для платежной сети как поток повторяющихся списаний. Если аккаунт нестабилен, заморозка бьет сразу по всем активным подписчикам: карты перестают списываться, доступ к продукту приходится закрывать или оставлять бесплатно, поддержка тонет в тикетах, а повторный запуск биллинга на чистой инфраструктуре занимает недели. Именно поэтому платежи с подписок из СНГ нельзя строить на серой схеме «пока работает».
Легальный путь один: компания в поддерживаемой юрисдикции, корпоративный счет, прозрачный бенефициар, сайт с политиками и официальная верификация. Это не обход Stripe. Это единственный способ, которым Stripe вообще готов работать с нерезидентом.
Связка, которая работает в 2026 году
Практическая архитектура для большинства B2B и B2C SaaS из СНГ с аудиторией в США, Европе, Канаде, Австралии и на Ближнем Востоке состоит из четырех слоев.
Первый слой - юридический. Wyoming LLC дает американское юрлицо, которое понимают банки, Stripe, корпоративные закупщики и бухгалтеры. Giru регистрирует LLC только в Вайоминге. Это сознательный выбор под нерезидента, цифровые продукты и платежную инфраструктуру, а не «штат, про который чаще пишут в англоязычных блогах».
Второй слой - банковский. Mercury открывает корпоративный долларовый счет на эту LLC без визита в США и без депозита, который требуют классические банки. Реквизиты Mercury Stripe принимает как стандартную связку. Параллельно можно держать Payoneer, если часть клиентов, подрядчиков или площадок удобнее сажать на отдельный мультивалютный контур.
Третий слой - платежный. Stripe принимает карты, поднимает подписки через Stripe Billing, отдает готовый Stripe Checkout SaaS, выставляет инвойсы, проводит in-app платежи через Payment Intents и дает антифрод Radar. При необходимости на чекаут добавляется PayPal как второй метод, чтобы не терять покупателей, которые принципиально не вводят карту на незнакомом сайте.
Четвертый слой - операционный. Сайт или лендинг с описанием продукта, Terms of Service, Privacy Policy, Refund и Cancellation Policy, контакты поддержки, корректный MCC, настроенный дуннинг, понятная логика триалов и резервный канал расходов. Для рекламы, облака и зарубежных подписок, которые не принимают карты банков СНГ, используется иностранная карта грузинского банка-партнера. На данный момент Giru выпускает именно грузинские карты, а не «карты любой удобной страны».
Эта связка не требует венчурного раунда, офиса в Делавэре, которого у вас нет и который вам не нужен, и не требует «престижа британской прописки». Она требует последовательности и документов.
Почему именно Вайоминг и почему не другие штаты
Для SaaS-нерезидента штат инкорпорации - это не сувенир на сертификате. Это ежегодная стоимость владения, налоговая логика на уровне штата, приватность бенефициара, скорость получения документов и то, насколько спокойно банк с платежным шлюзом читают ваш пакет.
Вайоминг для этой задачи подходит лучше всего по совокупности практических причин.
В штате нет налога на прибыль LLC для нерезидента без источника дохода внутри США. Нет налога на франшизу, который в других штатах превращает «дешевую компанию» в дорогую уже на второй год. Нет требования публиковать бенефициара в открытом реестре штата. Registered Agent закрывает юридический адрес. Один участник-нерезидент может владеть компанией на 100%. Operating Agreement не подается государству, но банки и Stripe его регулярно просят, поэтому документ готовится сразу. Annual Report предсказуем и не привязан к обороту.
Срок инкорпорации при стандартной обработке - обычно от 3 до 5 рабочих дней на уровне штата, а полный пакет с EIN занимает в среднем от 5 до 10 рабочих дней. Это не рекламный слоган «компания за сутки». Это реалистичный календарь, в который еще нужно заложить банк и Stripe.
Giru не регистрирует LLC в Делавэре и не предлагает Делавэр как «более серьезный» вариант для приема платежей. Для венчурной C-Corp с опционами, SAFE и советом директоров разговор про штат может быть другим. Для SaaS-фаундера из СНГ, которому нужны Stripe, Mercury, подписки и инвойсы, Делавэр не является рабочей рекомендацией: он не ускоряет верификацию шлюза, не делает биллинг «более белым» и не заменяет Вайоминг в глазах комплаенса Mercury. Платежная инфраструктура смотрит на EIN, бенефициара, сайт и банковский след, а не на миф о том, что «настоящие стартапы регистрируются только в одном штате».
C-Corp тоже не нужна большинству команд на этом этапе. LLC работает как pass-through: сама компания не платит федеральный налог на прибыль как отдельный субъект, если нет Effectively Connected Income. C-Corp создает корпоративный налог и потенциальное двойное налогообложение при дивидендах. Она оправдана, когда в капитализацию заходят институциональные фонды. Если вы продаете доступ к продукту по подписке, а не собираете Series A, Wyoming LLC - правильный контур.
Как устроена регистрация LLC под платежи, а не «для галочки»
Регистрация компании ради сертификата в PDF и регистрация компании под Stripe - разные задачи. Во втором случае каждый документ сразу пишется так, чтобы его приняли банк и платежный шлюз.
Сначала проверяется название. Оно должно быть уникальным в реестре Вайоминга и содержать LLC либо Limited Liability Company. Для SaaS лучше выбирать имя, которое можно связать с продуктом или холдингом, а не случайный набор слов из генератора. Стоит иметь 2-3 варианта: популярные комбинации в digital-нишах часто уже заняты.
Затем назначается Registered Agent с адресом в штате. Нерезидент не может исполнять эту роль сам. Адрес агента становится юридическим адресом компании. Дешевый агент с формальным адресом, который потом не проходит банковскую проверку, экономит десятки долларов и стоит недель на переоформлении.
Дальше подаются Articles of Organization. В них указываются название, адрес агента, организатор и модель управления: member-managed или manager-managed. Для соло-фаундера обычно достаточно member-managed. Если есть операционный менеджер, который не является участником, структура должна совпадать с тем, что вы потом напишете в Operating Agreement и в анкете банка.
После подтверждения штата готовится Operating Agreement. Формально Вайоминг его не требует. Фактически Mercury и Stripe без него регулярно задают дополнительные вопросы. В соглашении фиксируются доли, права участников, порядок распределения прибыли, кто подписывает договоры и что происходит при выходе партнера. Для компании с несколькими фаундерами это еще и предохранитель от корпоративного конфликта, который банк интерпретирует как непрозрачность владения.
Отдельным контуром идет описание бизнес-модели. Не «software» и не «IT consulting». Нужна конкретная формула: какой продукт, кому продается, как приходят клиенты, какая валюта, какой средний чек, есть ли триал, есть ли рефанды, где хостится сервис, кто оказывает поддержку. Именно это описание потом копируется в анкеты Mercury и Stripe. Расхождение между тремя версиями - классический красный флаг.
Если нужно собрать пакет так, чтобы его не пришлось переписывать после первого отказа банка, это делается через консультацию и подготовку документов. На практике именно формулировки, а не отсутствие печати, валят заявки нерезидентов.
EIN: без него нет ни банка, ни Stripe
EIN, Employer Identification Number, - это федеральный идентификатор налогоплательщика, который присваивает IRS. Без EIN нельзя открыть корпоративный счет, нельзя пройти KYB в Stripe, нельзя корректно сдавать информационную отчетность. Для нерезидента без SSN заявка идет по форме SS-4 факсом или почтой, а не через мгновенную онлайн-форму, доступную гражданам США.
Реалистичный срок - от 3 до 10 рабочих дней в зависимости от загрузки IRS. Ошибки в названии компании, адресе, ответственном лице или в причине получения номера отбрасывают заявку назад. Получать EIN «на всякий случай» до регистрации компании нельзя: номер выдается уже существующему юрлицу.
На руки вы получаете EIN Letter. Банки ждут CP 575 либо 147C. Скриншот из кабинета или пересказ номера в мессенджере не заменяет письмо IRS. Этот документ нужно хранить так же бережно, как сертификат о регистрации: его будут запрашивать повторно при смене банка, подключении PayPal и при усиленном финмониторинге.
SSN учредителю не нужен. ITIN тоже не нужен для самой инкорпорации и для владения LLC. Он появляется в повестке только если у участника лично возникает обязанность подавать 1040-NR, например при Effectively Connected Income. Для типичного SaaS без офиса, склада и сотрудников в США это не стартовое требование.
Сайт, лендинг и юридические страницы: это часть платежной инфраструктуры
Комплаенс Stripe и Mercury смотрит на сайт раньше, чем на ваш GitHub. Если продукта еще нет в продакшене, нужен хотя бы рабочий лендинг на собственном домене с корпоративной почтой. Регистрация Stripe-аккаунта на Gmail и «сайт скоро будет» повышает вероятность ручной проверки и отказа. Не публикуйте «Coming soon» без политик и без описания тарифа: для андеррайтера это пустая оболочка, а не SaaS.
Минимальный набор страниц для SaaS:
- описание продукта простым языком: что делает сервис, для кого, какие ограничения тарифов;
- цены или хотя бы диапазон тарифов и валюта;
- Terms of Service;
- Privacy Policy;
- Refund Policy и правила отмены подписки;
- контакты поддержки: email на домене компании, желательно форма или чат;
- юридические реквизиты: название LLC, адрес Registered Agent, если вы его публикуете, ссылка на компанию как на продавца.
Terms of Service должны закрывать предмет услуги, лицензию на использование софта, ограничения ответственности, применимое право, запрещенные сценарии использования, автопродление подписки и порядок расторжения. Для SaaS критичен блок про автоматическое списание: клиент должен понимать, когда кончается триал, что будет списано, как отменить подписку и сохранится ли доступ в grace period.
Privacy Policy описывает, какие данные вы собираете, зачем, с какими процессорами делитесь, где храните, как долго держите и какие права есть у пользователя. Если вы работаете с европейскими клиентами, логика GDPR должна быть не «скопированным шаблоном из генератора», а согласованной с реальной архитектурой: аналитика, пиксели, чат поддержки, Stripe как процессор платежей, хостинг, почтовые сервисы.
Refund Policy для цифрового продукта и подписки - отдельный риск-фактор. Stripe оценивает, можно ли клиенту понятным способом отменить автопродление и вернуть деньги в оговоренных случаях. Размытая фраза «возвраты не предусмотрены» при годовой предоплате повышает и чарджбэки, и вопросы андеррайтера. Честная политика с коротким окном возврата на первом списании и без возврата за уже использованный период обычно выглядит для комплаенса лучше, чем абсолютный запрет.
Если лендинга еще нет, его можно собрать через сервис создания лендингов так, чтобы страница одновременно продавала продукт и закрывала чек-лист платежного шлюза. Если юридические тексты нужно написать под вашу модель, а не вставить шаблон, это задача подготовки документов.
Отдельный практический совет: не публикуйте на сайте обещания, которых нет в биллинге. Если написано «отмена в один клик», кнопка должна существовать в кабинете или в Customer Portal. Если написано «14 дней гарантии», дуннинг и refund-логика должны это исполнять. Расхождение маркетинга и фактических списаний - одна из самых частых причин споров по подпискам.
Mercury для стартапа: зачем именно этот счет
Классический американский банк для нерезидента без ITIN, без визита и без шестизначного депозита - это лотерея с плохими шансами. Mercury изначально заточен под LLC и стартапы: онлайн-онбординг, нет платы за обслуживание в базовом контуре, виртуальные карты, командный доступ, API, прямая совместимость со Stripe.
Заявка требует Certificate of Formation, Operating Agreement, EIN Letter, паспорт бенефициара, proof of address не старше трех месяцев, описание бизнеса и ссылку на сайт. Корпоративный email на домене компании обязателен по смыслу, даже если формально поле это не кричит красным. Личный Gmail в заявке LLC выглядит как отсутствие операционной реальности.
KYC проверяет личность. KYB проверяет компанию: структуру владения, ожидаемые обороты, географию клиентов, источник первых денег на счете, соответствие сайта заявленной деятельности. Для SaaS вероятность одобрения выше, чем для крипты, форекса и гемблинга, но только если описание конкретное. «We provide cloud solutions for global clients» - это не описание. «B2B SaaS для команд маркетинга: аналитика рекламных кабинетов по подписке 49-199 долларов в месяц, клиенты в США и ЕС, триал 14 дней, списания через Stripe» - это описание.
Срок без дозапросов - обычно от 2 до 7 рабочих дней, в более широкой практике от 3 до 10. Дозапрос по source of funds, расхождению адресов или слишком агрессивному прогнозу оборота растягивает процесс до двух-трех недель. Повторная заявка после отказа всегда тяжелее первой. Поэтому пре-скоринг пакета до отправки экономит не «нервы», а календарь запуска.
После активации сразу настраиваются виртуальные карты под облако, рекламу и подписки, раздельные роли для бухгалтера, лимиты и привязка к Stripe. Mercury продолжает мониторить операции после открытия. Первый крупный входящий платеж, не похожий на заявленный средний чек, или серия переводов «на личную карту основателя без инвойса» может вызвать запрос. Это стандарт, а не наезд. Ответ нужен быстрый, с договором, инвойсом или пояснением подписки.
Типичные причины отказа и последующей заморозки мы отдельно разбирали в материале про красные флаги Mercury. Короткий список для SaaS: нет сайта, VPN при логине из трех стран за день, описание «консалтинг» при факте подписочного софта, резкий скачок оборота в 20 раз без причины, платежи в санкционные контуры, попытка провести личные траты основателя как операционку компании без следа.
Подробный процесс заявки - в гайде по открытию Mercury. Сопровождение заявки - на странице Mercury.
Payoneer как второй контур, а не замена Mercury
Mercury закрывает долларовый операционный счет LLC и выплаты Stripe. Payoneer полезен, когда часть денег приходит с площадок, подрядчиков или клиентов, которым удобнее локальные реквизиты Payoneer, либо когда нужен запасной канал вывода. Это не «вместо банка», а рядом с банком.
Для чистого SaaS с картами через Stripe Payoneer не обязателен на старте. Он становится практичным, если вы одновременно продаете через маркетплейсы, биржи или выставляете счета клиентам, которые не хотят платить картой. Корпоративный Payoneer все равно привязывается к той же зарубежной компании и проходит свой KYC/KYB. Мешать личный Payoneer основателя с корпоративным Stripe - плохая гигиена: комплаенс любит одну понятную структуру, а не переток денег между личным и корпоративным контуром без договоров.
Как открыть Stripe для стартапа: онбординг без самодеятельности
Регистрация Stripe - это заявка на мерчант-аккаунт. Система оценивает риск до первой транзакции. Для LLC США Stripe процесс такой.
Выбирается страна аккаунта - США, потому что компания американская. Указывается тип бизнеса и MCC. Для SaaS обычно берут категории software / digital services, а не «consulting», если вы продаете доступ к продукту. Неверный MCC - частая причина ручной проверки: заявлен консалтинг, а на сайте тарифы подписки и кнопка Start free trial.
Вносятся данные компании: legal name как в Articles, EIN, адрес Registered Agent, URL сайта, телефон, корпоративная почта. Бенефициары с долей от 25% проходят KYC: паспорт, дата рождения, адрес, иногда селфи или видеопроверка. Если фаундеров трое по 33%, проходят все трое. Прятать партнера, чтобы «не светить», нельзя: расхождение с Operating Agreement всплывает.
Привязывается банковский счет Mercury. Выплаты физическому лицу на личную карту нерезидента в этом контуре не являются целью. Stripe должен понимать, куда уходит коммерческая выручка.
Дальше загружается или проверяется сайт. Автосканер ищет Terms, Privacy, Refund, Contacts, описание продукта и признаки запрещенных ниш. Если страницы нет в футере или она отдает 404, заявка чаще уходит человеку.
Верификация занимает от 3 до 10 рабочих дней при полном пакете. High-risk ниша, пустой сайт, несовпадение имен, слишком смелый объем в анкете - дольше. Первые выплаты могут идти с задержкой, пока аккаунт не наберет историю. Это нормально. Rolling reserve иногда включают точечно, если риск чарджбэков по модели высокий: длинные годовые подписки, инфопродукт, обещания результата.
Stripe Atlas мы не используем как обязательный путь. Он удобен тем, кто хочет все в одном кабинете Stripe, но ограничивает гибкость по банку и параллельным шлюзам. Независимая LLC в Вайоминге оставляет вам право выбрать Mercury, добавить PayPal, сменить агента и не быть привязанным к одному вендору.
Пошаговая механика заявки также разобрана в инструкции по открытию Stripe и в гайде по документам для регистрации Stripe. Здесь фокус другой: как эта заявка стыкуется с подписочным SaaS.
Stripe Billing: сердце подписочного продукта
Разовый Payment Link можно запустить за час. SaaS на этом не живет. Нужен рекуррентный движок, который умеет тарифы, апгрейды, даунгрейды, прорейтинг, купоны, паузу, несколько подписок на одного кастомера, usage-based надстройки и историю инвойсов. Stripe Billing закрывает это нативно.
Базовая модель: Product в каталоге Stripe, Price к продукту, Subscription на кастомера. Для трех тарифов Starter / Pro / Business заводятся три Price, лучше сразу в нужных интервалах: month и year. Годовая цена обычно содержит скидку. Скидку лучше делать отдельным Price, а не ручной корректировкой, чтобы отчетность и дуннинг не разъехались.
Прорейтинг при смене тарифа в середине цикла должен быть включен осознанно. Если клиент переходит с 49 на 149 долларов на 12-й день месяца, Stripe может добрать разницу за остаток периода. Если прорейтинг выключен, клиент либо переплачивает, либо недоплачивает, и поддержка начинает жить в таблицах. Для B2B это выглядит как незрелый продукт.
Купоны и trials лучше настраивать как свойства подписки, а не как «менеджер пришлет промокод в Telegram и потом руками заведет клиента». Ручной биллинг на старте кажется гибким и убивает масштабирование: через полгода никто не помнит, кому дали три месяца бесплатно и почему карта не привязана.
Customer Portal стоит включить сразу. Пользователь сам меняет карту, скачивает инвойсы, отменяет автопродление. Это снижает нагрузку на поддержку и одновременно улучшает картину для чарджбэков: у клиента был понятный self-service, а не «отписка только через письмо основателю».
Вебхуки обязательны. Минимум: invoice.paid, invoice.payment_failed, customer.subscription.updated, customer.subscription.deleted, charge.dispute.created. Без вебхуков продукт не узнает, что подписка умерла, и будет либо дарить доступ, либо внезапно закрывать его без письма. Оба варианта вредят метрикам и репутации мерчанта.
Пробные периоды: как не превратить триал в генератор чарджбэков
Триал - сильный продуктвый рычаг и одновременно риск для платежного профиля. Stripe позволяет card-required trial и card-optional trial. Для комплаенса и для снижения фрода почти всегда лучше требовать карту на старте. Иначе вы получаете поток одноразовых почт, а когда начинаете списывать, ловите decline и споры «я не подписывался».
Правила, которые стоит прописать и в продукте, и в Terms:
- длительность триала в днях;
- будет ли списание в последний день триала или на следующий;
- придет ли письмо-напоминание за 1-3 дня;
- можно ли отменить в один клик до списания;
- что происходит с данными после отмены;
- есть ли второй триал на тот же email или карту.
Повторные триалы на одну карту - классический abuse. Radar и собственные правила должны это резать. Иначе вы субсидируете вечных триальщиков и одновременно учите платежную сеть, что по вашему MCC много неуспешных и спорных операций.
Для B2B иногда разумнее не классический триал, а пилот по инвойсу: 14-30 дней доступа по договору, затем годовая или месячная подписка. Это лучше стыкуется с закупками корпораций и снижает card-not-present риск. Stripe Invoicing закрывает этот сценарий без отказа от Billing.
Еще одна ошибка: списывать первую оплату тихо, без чека и без письма. Даже если юридически клиент согласился с автопродлением, для эмитента карты «неузнаваемое списание от неизвестного дескриптора» выглядит как фрод. Настройте понятный statement descriptor, письма invoice.paid и бренд, который клиент узнает в банковской выписке.
Дуннинг: деньги, которые вы уже заработали, но еще не получили
Значимая доля churn в SaaS - не «продукт не подошел», а карта истекла, банк отклонил, не хватило лимита, 3-D Secure не прошел, эмитент счел повторяющееся списание подозрительным. Без дуннинга вы теряете MRR, который клиент был готов платить.
Рабочий дуннинг в Stripe Billing включает smart retries, серию писем, статус past_due, ограниченный grace period и только потом cancel. Для B2B с чеком от нескольких сотен долларов grace period особенно важен: корпоративная карта может не пройти в пятницу вечером, а в понедельник финансы обновят лимит.
Письма должны быть конкретными: какая сумма, какая дата, какая карта, какая ссылка обновить метод оплаты. Тон - сервисный, не обвиняющий. Параллельно в продукте показывается баннер «оплата не прошла, доступ сохранится до такой-то даты». Внезапное отключение без предупреждения провоцирует и отток, и чарджбэк «услуга не оказана», даже если формально клиент был в просрочке.
Отдельно следите за soft decline и hard decline. Soft имеет смысл ретраить. Hard - истекшая карта, украденная карта, клиент отозвал мандат - ретраить бессмысленно, нужно просить новый метод оплаты. Слепое долбление одной и той же карты ухудшает ваш authorization rate в глазах сетей.
Дуннинг - это не «еще одна галка в Stripe». Это процесс, который должен быть согласован с Customer Success. Если менеджер обещает клиенту паузу на месяц, а Billing продолжает ретраить и затем банит аккаунт, вы сами создаете спор.
Stripe Checkout, Elements и оплата внутри приложения
Как принимать платежи за приложение технически - отдельный выбор, который влияет на PCI, конверсию и комплаенс.
Stripe Checkout - hosted-страница. Клиент уходит на домен Stripe, вводит карту, возвращается. Для PCI это самый спокойный путь: вы не касаетесь карточных данных. Для SaaS Checkout хорошо работает на лендинге, в смене тарифа, в оплате инвойса. Минус - меньше контроля над UX.
Payment Element / Elements позволяет встроить форму на свой домен. Конверсия часто выше, бренд цельный, можно добавить Link, кошельки, локальные методы. PCI-нагрузка все еще снижена, если вы не храните PAN, но появляется обязанность корректно подключить скрипты, CSP и не логировать поля карты.
Payment Intents - правильный примитив для разовых и in-app сценариев, включая мобильные клиенты. Для подписки поверх все равно живет Subscription object. Не нужно изобретать свой рекуррент через cron и сохраненный токен «потому что так проще». Свой рекуррент без Billing почти всегда хуже в ретраях, налогах, инвойсах и спорах.
Внутри мобильного приложения есть развилка. Если продаете цифровой контент или функции, которые Apple и Google считают digital goods, их магазины могут требовать In-App Purchase. Stripe в этом контуре не заменяет правила стора. Если продаете B2B-доступ, физический сопутствующий товар или подписку, которая по гайдлайнам может идти через внешний веб-чекаут, Stripe Checkout или Payment Element на вашем домене остаются рабочим путем. Этот выбор нужно фиксировать до онбординга: в анкете Stripe и на сайте должно быть видно, где именно клиент платит.
3-D Secure для рекуррента настраивается политикой. Слишком мягко - больше фрода и чарджбэков. Слишком жестко - падает конверсия европейских карт. Для первого платежа по новой карте 3DS обычно оправдан. Для последующих списаний по уже аутентифицированной подписке сети допускают merchant-initiated transaction. Ломать эту логику самодельными правилами не стоит.
B2B-инвойсы: когда карта перестает быть основным методом
Корпоративный клиент часто не может оплатить SaaS картой сотрудника. Ему нужен инвойс, net 15 / net 30, реквизиты LLC, иногда purchase order, иногда отдельный договор. Stripe Invoicing закрывает базовый контур: выставляете счет, клиент платит картой, ACH или по ссылке, статус счета синкается с подпиской.
Для более тяжелого B2B имеет смысл держать шаблон договора, описание SLA, порядок приема работ и реквизиты компании в одном пакете. Это не «бюрократия ради бюрократии». Это доказательства для чарджбэка и для банка, когда на счет приходит крупный wire, не похожий на ежедневные списания по 49 долларов.
Не смешивайте личные Payoneer-реквизиты основателя и инвойсы LLC. Покупатель должен платить тому юрлицу, которое указано в Terms и в Stripe. Иначе вы сами создаете расхождение, которое комплаенс читает как транзитный счет.
Если клиент в ЕС просит VAT-номер, это уже налоговый, а не платежный вопрос. Американская LLC не становится автоматически плательщиком британского или европейского НДС. Для продаж цифровых услуг физлицам в отдельных юрисдикциях могут возникать пороги. Этот контур нужно проектировать с бухгалтером, а не рисовать «VAT 20%» на инвойсе, потому что так выглядит солиднее.
PCI DSS: что реально нужно SaaS, а что нет
PCI DSS пугает команды, потому что звучит как сертификация банка. Для большинства SaaS, которые принимают карту через Stripe Checkout или Elements и не хранят PAN, CVV и полные треки, задача другая: соблюдать SAQ A или SAQ A-EP, не логировать карточные данные, не снимать скрины форм оплаты, закрыть HTTPS, не проксировать карту через свой бэкенд «для удобства».
Практический минимум:
- TLS на всем сайте, без смешанного контента на чекауте;
- форма оплаты только через Stripe.js / Checkout, без собственных input name="card_number";
- запрет писать номера карт в тикеты поддержки и в CRM;
- ограничение доступа в Stripe Dashboard по ролям и 2FA;
- вебхуки с проверкой подписи;
- политика хранения персональных данных, согласованная с Privacy Policy;
- отсутствие тестовых ключей на проде и продовых ключей в публичном репозитории.
Если кто-то из команды предлагает «сохранить карту у нас, так надежнее, чем токен Stripe», это не надежнее. Это расширение PCI-периметра до уровня, который стартап не потянет. Токенизация Stripe существует именно для того, чтобы вы не стали хранилищем карт.
Сопровождение требований PCI на сайте входит в контур подключения Stripe. Это не замена QSA-аудита для гигантского эквайера, а практическая гигиена, без которой андеррайтинг и безопасность расходятся.
Антифрод: Radar, свои правила и здравый смысл
Stripe Radar смотрит сотни сигналов: IP, BIN карты, страна эмитента, скорость ввода, устройство, история email, совпадение биллинг-страны и доставки, сумма относительно среднего чека. Для SaaS с триалом отдельный риск - card testing, когда боты проверяют украденные карты мелкими списаниями или серией попыток на Checkout.
Базовые правила, которые стоит включить в первые недели:
- лимит попыток оплаты с одного IP и одного email;
- блок или review на карты из стран вне вашей целевой географии;
- review на первый платеж выше определенного порога с новой карты;
- запрет многократных триалов на один fingerprint карты;
- блок prepaid и некоторых BIN, если они дают у вас аномальный dispute rate;
- allowlist для известных корпоративных клиентов.
Слишком злые правила душат конверсию. Слишком добрые растят chargeback rate. Visa и Mastercard держат программы мониторинга. Превышение порога споров - это уже не «неприятный клиент», а риск штрафов и разрыва с эквайером. Для подписок особенно опасны friendly fraud: человек сам оформил триал, забыл, увидел списание через месяц и нажал dispute в приложении банка, потому что так быстрее, чем искать кнопку отмены.
Ответ на фрод - не только Radar. Это продуктовые решения: понятный дескриптор, письма, портал отмены, честный триал, 3DS на первом платеже, ручная проверка крупных годовых оплат. Если вы продаете годовой план за 2000 долларов с лендинга без звонка и без верификации домена почты, вы приглашаете и фрод, и рефанды.
Чарджбэки: как спорить так, чтобы не убить аккаунт
Чарджбэк по подписке чаще всего приходит с reason code в духе «услуги не оказаны», «не узнаю транзакцию», «подписку отменили, а списание продолжалось». Выигрыш в споре зависит от доказательств, которые вы собрали в момент продажи, а не в момент паники.
Нужны: IP и timestamp согласия с Terms, версия Terms, email подтверждения, логин в продукт, факты использования, история писем о предстоящем списании, факт доступного self-service cancel, переписка с поддержкой. Если клиент 40 дней пользовался кабинетом, а потом сказал «я не подписывался», это защита. Если у вас нет логов согласия, это проигрыш.
Срок ответа на dispute в Stripe короткий. Пропуск срока - автоматический проигрыш. Уведомления должны падать не только основателю в личную почту, но и в канал команды.
Даже выигранный чарджбэк остается в статистике. Поэтому стратегия «пусть диспутят, мы будем отбивать» не работает на объеме. Стратегия - не допускать сюрпризов в выписке, давать отмену, быстро рефандить очевидные случаи в первые дни и спорить только там, где использование доказано.
Логика доказательной базы похожа на ту, что мы разбирали для споров PayPal. Платформы разные, принцип один: комплаенс и эмитент верят документам и логам, а не эмоции «клиент токсичный».
Refund лучше чарджбэка. Если человек пишет на второй день триала, что ошибся картой, верните деньги. Если пишет через пять месяцев после активного использования, смотрите Terms и логи. Автоматический «мы никогда не возвращаем» повышает dispute rate.
Stripe vs PayPal для SaaS: что брать основным, что запасным
Сравнение нужно не для религиозного выбора, а для чекаута.
Stripe выигрывает как основной шлюз для SaaS. Billing, портал клиента, вебхуки, Radar, Connect на будущее, инвойсы, налоговые инструменты, тонкая работа с подписками, нормальный developer experience. Комиссия порядка 2,9% + фиксированная ставка за карту США, международные карты дороже, конвертация отдельно. Для продукта с тарифами, триалами и апгрейдами альтернативы по гибкости на старте обычно нет.
PayPal выигрывает как второй метод оплаты. У части аудитории, особенно B2C и возрастной, выше доверие к знакомому бренду. Человек не хочет светить карту. Кнопка PayPal снижает брошенный чекаут. Но подписочный движок PayPal беднее, споры часто лояльнее к покупателю, заморозки для нерезидентов привычнее, кастомная логика апгрейда тяжелее. Делать PayPal единственным биллингом SaaS в 2026 году - значит переносить продуктовую сложность на свою команду.
Практическая схема: Stripe Billing как source of truth по подпискам, PayPal как payment method там, где это уместно, либо отдельный PayPal-план с упрощенной тарифной сеткой. Не держите две независимые системы подписок, которые ничего не знают друг о друге. Иначе один и тот же клиент будет «активен» в продукте после отмены в одном шлюзе.
High-risk ниши PayPal переваривает хуже. Инфобизнес, коучинг, резкие скачки оборота, несовпадение сайта и MCC - типичный путь к холду. Stripe тоже не благотворительность, но для software-as-a-service при внятном сайте шансы устойчивее. Подробное сравнение есть в материале Stripe vs PayPal для SaaS. Подключение PayPal как дополнительного канала - на странице PayPal.
Комиссии нельзя сравнивать только по «2,9%». Смотрите международные карты, конвертацию, chargeback fee, стоимость неуспешных ретраев, резервы. Для европейского клиента, который платит в евро на долларовый аккаунт, итоговая цена денег может съесть маржу дешевого тарифа.
Когда британская LTD может быть альтернативой
Базовый совет Giru для приема карт и подписок из СНГ - американская LLC в Вайоминге. Британская LTD не лучше «по статусу» и не открывается «за 24-48 часов под ключ со счетом и Stripe». Такие обещания - маркетинг. Companies House может внести компанию за 1-3 рабочих дня при чистой подаче, но UTR, юридический адрес, банк и платежный шлюз занимают отдельное время. Полный цикл чаще измеряется неделями, а банковский контур для нерезидента в UK обычно тяжелее, чем Mercury для Wyoming LLC.
LTD имеет смысл рассматривать, когда экономика и клиенты завязаны на Великобританию и Европу сильнее, чем на США. Практический налоговый якорь - порог VAT £80,000: пока облагаемый оборот за скользящие 12 месяцев не превысил эту сумму, обязательной регистрации VAT нет. Это не «нулевые налоги навсегда» и не освобождение от Corporation Tax. Это порог НДС. Corporation Tax считается от прибыли отдельно. Путать эти две вещи нельзя.
LTD удобнее, если европейские B2B-клиенты хотят счет от британской компании, если вам нужен контракт в английском праве с понятной для EU-закупщика формой, если американский банкинг по какой-то причине недоступен, если продукт заточен под UK-рынок. Stripe UK LTD поддерживает. Но счет, сопоставимый по удобству с Mercury, нерезиденту часто приходится собирать через другие финтех-реквизиты, и срок верификации обычно длиннее.
Не выбирайте LTD потому что «звучит солидно для инвесторов». Инвесторам, если они вообще появятся, нужна чистая капитализация и понятный governance, а не юрисдикция как украшение в шапке сайта. Не выбирайте LTD, надеясь обойти комплаенс Stripe: шлюз проверяет бенефициара так же. Не выбирайте LTD, если единственная цель - подписки в долларах для американского SMB. Для этого штатная связка Вайоминг + Mercury + Stripe короче.
Сравнение юрисдикций - в материале LLC или LTD. Порог НДС подробно разобран в гайде по VAT £80,000. Если после этого разговора UK все еще выглядит уместнее, структуру нужно собирать отдельно, а не «вместо Вайоминга на всякий случай».
Налоги и отчетность: платежи прошли, обязательства остались
Подключить Stripe не значит «налоги решены». LLC в Вайоминге при отсутствии ECI обычно не платит налог штата и не платит федеральный корпоративный налог как C-Corp, но информационная отчетность остается.
Компания с иностранным владельцем подает pro forma 1120 и форму 5472. Штраф за 5472 исчисляется тысячами долларов за каждый год и каждый несданный отчет, даже при нулевой прибыли. В 5472 попадают reportable transactions между LLC и бенефициаром: вклады, выводы, оплата услуг основателю, займы. Вести это «в голове» нельзя.
Stripe как агрегатор может сформировать 1099-K по порогу оборота. Это валовый объем, не прибыль. Сверять его с выручкой, рефандами и комиссиями нужно в учете, иначе вы сами не поймете, сколько компании можно распределить.
Sales tax в штатах США для SaaS - отдельная сложность. Правила зависят от штата, от того, считается ли ваш софт tangible, от экономического nexus по выручке или числу транзакций. Stripe Tax помогает считать и коллекционировать налог, но не заменяет квалификацию, нужен ли он вам. Включать налог «на всякий случай во всех штатах» так же опасно, как не включать его там, где nexus уже возник.
В стране налогового резидентства фаундера действуют свои CFC-правила и обязанности декларировать иностранную компанию. США не отменяют Россию, Казахстан, Беларусь, Узбекистан, Грузию или Сербию как налоговое резидентство физического лица. Этот слой нужно закрывать с локальным консультантом. Мы можем выстроить американский контур и учет компании, но не подменяем personal tax advice во всех странах СНГ сразу.
Бухгалтерский контур с первого года дешевле штрафа. Логика учета зарубежной компании разобрана в материале про bookkeeping, дедлайны - в календаре корпоративной отчетности.
Иностранная карта: операционные расходы, которые не проходят с карт СНГ
Даже после запуска Stripe основателю нужно платить за AWS, Google Cloud, домены, Figma, рекламу, антифрод-сервисы, почту. Карты банков СНГ эти платежи часто не проводят. Корпоративные карты Mercury закрывают часть этого контура, если счет уже живой. На старте и для личных рабочих расходов, которые еще не сидят на LLC, нужна иностранная карта.
Giru оформляет карты грузинского банка-партнера: Visa или Mastercard, личный или корпоративный формат, удаленный KYC, доставка курьером. Другие страны выпуска в текущем контуре услуг не предлагаем. Не нужно искать «карту любой европейской страны через Telegram». Нужна понятная агентская модель Introducer, пре-скоринг документов и пластик, который доезжает.
Срок выпуска и доставки обычно 2-4 недели. Карту не стоит закладывать как единственный способ оплаты рекламы «завтра». Сначала документы, потом банк, потом курьер.
Карта не заменяет Stripe. Она не принимает платежи клиентов. Она тратит. Путать эквайринг и расходную карту - частая ошибка в консультациях: «мне нужна карта, чтобы принимать оплату за подписку». Принимать оплату за подписку будет Stripe на LLC. Карта нужна, чтобы сам бизнес мог платить поставщикам.
Что нельзя делать: VPN, аренда аккаунтов, чужие компании
Короткий запретительный блок, потому что именно сюда люди приходят после форумов.
Нельзя регистрировать Stripe через VPN «как будто вы в США». Платформа смотрит устройство, IP-историю, язык браузера, таймзону, совпадение с паспортом бенефициара и банком. Несовпадение - сигнал фрода. Блокировка в таких кейсах часто без выплаты остатка. Апелляции почти не работают, потому что нарушение условий было сознательным.
Нельзя покупать, арендовать, «брать в управление» чужой Stripe. Аккаунт именной. Бенефициар, банк, сайт, трафик и поддержка должны совпадать. Арендованный аккаунт - это чужой мерчант, через которого вы гоните свою выручку. Для сетей это выглядят как laundering of merchant activity. Заканчивается холдом, blacklist и иногда проблемами уже у той компании, которую вам «сдали в аренду». Восстановить репутацию бенефициара после такого сложнее, чем сразу открыть свою LLC.
Нельзя брать номинального директора и думать, что банку можно не раскрывать реального владельца. Раскрытие UBO перед банком и Stripe обязательно. Конфиденциальность в реестре штата и сокрытие бенефициара от финмониторинга - разные вещи. Про легальную приватность можно читать в материале про бенефициара.
Нельзя создавать второй Stripe сразу после блокировки на тех же данных «под другим доменом». Связка идет по компании, паспорту, банку, устройству. Второй аккаунт без устранения причины усиливает подозрение.
Нельзя питать надежду, что «небольшой оборот проскочит». Комплаенс не порог честности. Он бинарный по качеству схемы.
Легальная схема всегда длиннее серой на старте и всегда короче серой после первой заморозки.
Типичные причины блокировок Stripe и Mercury у SaaS
Большинство заморозок, которые мы разбираем, не связаны с «Stripe ненавидит СНГ». Они связаны с расхождениями.
Сайт обещает AI-агентство и криптосигналы, а в Stripe стоит software subscription. MCC, лендинг и фактические списания должны говорить одно и то же.
На сайте нет Refund Policy, а годовой тариф списывается сразу. Эмитенты встают на сторону держателя карты.
Трафик куплен серыми инсталл-сетями, карты из стран, которых нет в вашей целевой аудитории, много попыток с одного BIN. Radar и сети видят carding.
Основатель логинится в Dashboard из пяти стран за двое суток через VPN, одновременно бухгалтеру открыт полный доступ с личного hotmail. Это выглядит как компрометация.
Выручка резко выросла после запуска рекламы, а в анкете был «ожидаемый оборот 2 000 долларов в месяц». Сам рост не запрещен. Запрещено молчать. Напишите в поддержку, приложите скрины кампаний, обновите forecast.
Клиенты из одной компании платят десятью личными картами сотрудников в обход бухгалтерии, а затем дружно делают chargeback. Нужны инвойсы, корпоративный метод оплаты, лимиты.
Вывод всего баланса на карту основателя в день поступления без описания распределения. Для Mercury это выглядит как транзит. Оставляйте операционный остаток, подписывайте resolution на distribution, храните назначение платежа.
Продукт обещает гарантированный доход, «сигналы», «арбитраж», медицинские диагнозы, кредитные repair-услуги. Это уже не нейтральный SaaS. Часть таких ниш Stripe не обслуживает или обслуживает как high-risk с резервом. Честнее выяснить это до инкорпорации, чем после.
Сайт на конструкторе с чужими отзывами, стоковыми лицами команды и юридическим адресом, который гуглится как mass registered agent без любого цифрового следа компании. Цифровой след не обязан быть из TechCrunch. Достаточно домена с историей, LinkedIn продукта, рабочей поддержки и согласованных реквизитов.
Если заморозка уже случилась, не пишите в чаты «как обойти». Соберите письмо комплаенса, документы, логи транзакций, описание продукта и идите по официальной апелляции. Мы сопровождаем такие кейсы только в легальном контуре и только если бизнес реален.
Реалистичный календарь запуска
Неделя 1. Бриф по продукту, тарифам, географии клиентов, бенефициарам. Проверка названия. Сбор паспортов и proof of address. Старт текстов для лендинга, Terms, Privacy, Refund. Подача Articles of Organization в Вайоминге.
Неделя 2. Компания в реестре. Подача SS-4 на EIN. Operating Agreement. Лендинг на домене, корпоративная почта, политики в футере. Подготовка business description для банка.
Неделя 3. EIN получен. Заявка в Mercury. Ответы на KYC. Параллельно черновик анкеты Stripe, выбор MCC, схема Billing.
Неделя 4. Счет активен. Заявка Stripe, привязка реквизитов, проверка сайта. Тестовые платежи. Настройка продуктов, цен, триала, вебхуков, Customer Portal, базового Radar, писем дуннинга.
Неделя 5. Первые живые карты. Возможный ручной запрос Stripe по сайту. Ответ в тот же день. Включение боевых выплат. Наблюдение за authorization rate и decline.
Это не гарантия «всем за 21 день». IRS, банк и шлюз имеют право замедлиться. Это карта, по которой видно, почему нельзя начинать с Stripe, не имея компании, и почему нельзя запускать платную рекламу на биллинг, которого еще нет. Параллелить разработку продукта и юридический контур можно и нужно: пока пишется кабинет, компания уже может получать EIN, а тексты политик уже могут жить на домене. Нельзя параллелить только одно - серую схему и «потом как-нибудь легализуем»: после первой блокировки легализация дороже и дольше, чем старт в правильном порядке.
Полный пакет под ключ: регистрация LLC, счет Mercury, Stripe. Документы и формулировки - консалтинг. Страница продукта - лендинг.
Сколько это стоит по смыслу, а не по мифу
Прямые государственные пошлины Вайоминга и год Registered Agent - фиксированные и умеренные относительно оборота даже маленького SaaS. Mercury в базовом режиме не берет плату за обслуживание. Stripe берет комиссию с транзакций, а не абонентскую «за право подключиться».
Дороже всего ошибки: отказ Mercury, повторный EIN, пустой сайт, блокировка Stripe за VPN, чарджбэки из-за кривого триала, штраф 5472. Именно поэтому связку дешевле собирать как один процесс. Разовая экономия на «сам подам через конструктор за 50 долларов» часто заканчивается месяцем простоя продукта.
Точные пакеты и состав работ смотрите на страницах услуг: там живет офер, а не в блоге. Блог объясняет, за что вы платите временем и риском, если делаете это вразнобой.
Кейс 1. B2B-аналитика из Казахстана
Трое фаундеров, продукт для email-аналитики, тарифы 49-199 долларов, аудитория США и Германия, триал 14 дней. Они начали с вопроса «какой API у Stripe», а не с юрисдикции. После консультации зарегистрировали Wyoming LLC, получили EIN, открыли Mercury, опубликовали лендинг с политиками, указали всех троих бенефициаров. Stripe Billing подняли с тремя Price, Customer Portal и письмом за 3 дня до конца триала. Radar резал повторные триалы. Первый живой платеж из Германии вызвал запрос скриншотов продукта. Ответили за сутки. До первой органической оплаты прошел чуть больше месяца. Серая схема «аккаунт знакомого в Калифорнии» даже не рассматривалась: при обороте через полгода это взорвалось бы на KYC знакомого.
Кейс 2. Мобильное приложение с подпиской и веб-чекаутом
Соло-разработчик из Беларуси хотел принимать платежи внутри iOS по Stripe. Часть функций стор считает digital goods. Ему объяснили развилку: стор-комиссия versus внешний чекаут там, где правила Apple позволяют, плюс веб-тариф для десктопа. Юридически продавец - LLC, в приложении указаны Terms и управление подпиской. На сайте - отдельный Stripe Checkout SaaS для годовых планов, которые команды покупают с корпоративных карт. PayPal добавили только на веб, потому что в мобильном контуре он давал лишние споры. Грузинская карта понадобилась основателю для Apple Developer Program и облака, пока корпоративные карты Mercury еще выпускались.
Кейс 3. Когда UK LTD обсуждали и не взяли
Продукт продавал доступ американским клиникам и биллился в долларах. Фаундер хотел LTD, потому что «европейская компания лучше смотрится в договоре». Клиенты были в США, закупки шли в USD, нужен был ACH и карты. LTD не давала ему ни порога VAT как практической выгоды, ни ускорения. Банковский контур был бы длиннее. Выбрали Вайоминг. LTD оставили как возможный второй контур на тот день, когда появится отдельная европейская линейка и осмысленный оборот под VAT. Не «для престижа».
Чек-лист перед первой боевой картой
- LLC в Вайоминге активна, название совпадает во всех документах.
- EIN Letter на руках.
- Operating Agreement подписан всеми участниками.
- Mercury открыт, логины без VPN-скачков по странам.
- Сайт открывается, политики в футере, контакты живые.
- В Terms есть триал, автопродление, отмена, применимое право.
- Stripe: верные legal name, EIN, MCC, бенефициары, банк.
- Billing: продукты, цены, налоги если нужны, вебхуки, портал, дуннинг.
- Radar: базовые правила, не «все блокировать».
- Дескриптор в выписке узнаваем.
- 2FA на Stripe и банке.
- Понятно, кто отвечает на dispute и на запрос комплаенса в течение рабочего дня.
- Нет арендованных аккаунтов, нет VPN как метода регистрации, нет чужих паспортов.
- Понятен контур 5472 на конец года.
Если пункта нет, это не «запустим, допилим». Это причина ручной проверки.
Как выглядит пакет KYC глазами сотрудника банка и Stripe
Когда заявка нерезидента попадает человеку, а не только алгоритму, проверяющий не читает ваш README. Он за 8-15 минут пытается ответить на пять вопросов. Кто этот человек. Существует ли компания. Чем она зарабатывает. Откуда возьмутся первые деньги. Не является ли это оболочкой для чужого трафика.
Паспорт должен читаться, быть в сроке и совпадать с латиницей в Articles и в банке. Расхождение «Alexey» и «Aleksei» без пояснения тормозит. Proof of address не старше трех месяцев: коммуналка, банковская выписка, налоговый документ. Скрин из Госуслуг без перевода и без даты часто отправляют назад. Если фаундер живет не в стране гражданства, это нужно одной фразой объяснить: резидентство, виза, долгосрочная аренда.
По компании смотрят цепочку: Certificate of Formation, EIN Letter, Operating Agreement, адрес агента, доли. Если в соглашении два участника 50/50, а в Stripe указан один, пакет считается ложным. Если агентский адрес совпадает с тысячами других LLC, это нормально для Вайоминга, но тогда цифровой след продукта должен быть сильнее: домен, сайт, почта, описание.
По бизнесу смотрят сайт как витрину риска. Есть продукт или только «скоро запустим». Есть цены или только «свяжитесь с нами». Есть способ отменить подписку или только форма «мы вам ответим». Есть запрещенные обещания дохода, медицины, оружия, крипты. Сотрудник кликает Checkout, если кнопка есть. Если кнопка ведет в никуда, заявка выглядит неготовой.
По деньгам смотрят source of funds на пополнение Mercury и прогноз оборота. «Первый месяц 200 000 долларов с холодного Facebook» без истории продукта вызывает усиленную проверку. Честный прогноз «первые 90 дней 3-8 тысяч, затем рост с контента и outbound» выглядит взрослее. Если на счет компании кладете личные накопления основателя, подготовьте короткое пояснение: зарплата, продажа прошлого бизнеса, дивиденды другой компании, а не «деньги от друга наличными».
Полный список того, что банки обычно просят, собран в материале про комплаенс-документы. Для SaaS к этому списку добавляются скрины тарифов, схема триала и пример инвойса. Если формулировки нужно собрать так, чтобы три сервиса видели одну историю, это делается на консультации по документам.
Первый месяц транзакций: как не напугать финмониторинг своим же запуском
Одобренный аккаунт - не финиш. Первые 30 дней Stripe и банк учатся на ваших реальных операциях. Задача этого месяца - дать чистый, объяснимый след, а не поставить рекорд выручки любой ценой.
Начните с собственных тестовых платежей боевой картой основателя только если понимаете, что это будет выглядеть как связанная сторона. Лучше несколько платежей дружественных бета-клиентов из целевой географии с реальным использованием продукта. Не гоняйте одну карту десять раз по 1 доллару. Не принимайте «просто проверь, проходит ли» карты из случайных стран.
Включите выплаты на Mercury по обычному расписанию. Не пытайтесь в первый же день вывести все. Не дробьте выводы на множество мелких переводов «чтобы не светиться»: дробление само по себе сигнал. Один-два понятных distribution или перевод на операционные расходы с назначением выглядят спокойнее.
Если запускаете рекламу, держите гео в рамках анкеты. Кампания «весь мир, оптимизация на покупку» в первую неделю часто привозит ворованные карты. Ограничьте страны, включите 3DS на первый платеж, смотрите долю decline. Резкий всплеск неуспешных авторизаций с одного BIN - повод остановить связку объявлений, а не увеличивать бюджет.
Отвечайте на in-app сообщения и почту. Пустой inbox при живых списаниях выглядит как мерчант, который не оказывает услугу. Для чарджбэка «service not received» это подарок покупателю.
Зафиксируйте внутренний журнал: дата запуска тарифа, дата первой рекламы, список крупных клиентов, кто имеет доступ в Dashboard. Когда придет запрос «поясните рост», вы не будете восстанавливать историю по памяти.
Usage-based, гибридные тарифы и почему их нельзя включать молча
Многие SaaS из СНГ начинают с трех фиксированных планов, а через полгода хотят брать деньги за API-вызовы, места в команде, гигабайты или количество обработанных документов. Stripe Billing это умеет: metered price, billing thresholds, invoicing за фактическое потребление.
Комплаенс и клиент должны понимать формулу заранее. Если на лендинге написано «49 долларов в месяц», а в конце месяца прилетает 400 из-за usage без предупреждения, вы получите и отток, и споры. Правильная витрина показывает базу плюс пример расчета. В продукте нужен счетчик потребления до конца цикла, а не сюрприз в инвойсе.
Гибрид «база + usage» для андеррайтера нормален, если это по-прежнему software. Он становится подозрительным, когда usage маскирует другую деятельность: перевод денег, торговлю трафиком, перепродажу доступов к чужим кабинетам. Если ваш «SaaS» по факту реселлит чужие API с наценкой, это нужно честно описать. Иначе MCC и сайт расходятся.
Не переключайте всю базу с фиксированной цены на metered одним релизом без писем и без дедлайна. Для Stripe это новые Price objects и, часто, новая подписка. Для клиента это смена оферты. Для спора это вопрос, соглашался ли он с новой ценой.
Мультивалютность, локальные методы и где конвертация съедает маржу
Stripe позволяет принимать доллары, евро, фунты и десятки других валют на один аккаунт США. Для европейского SMB цена в евро на Checkout повышает конверсию. Для американского клиента доллар остается базой. Не заставляйте всех платить в USD, если половина аудитории в ЕС и банки режут «подозрительную валютную операцию».
Решение, в какой валюте хранить баланс и в какой выводить на Mercury, влияет на итоговые деньги. Двойная конвертация - сначала карта в валюту аккаунта, потом аккаунт в доллар счета - незаметна в демо и заметна в P&L. Имеет смысл принимать евро как евро, если доля ЕС устойчивая, и конвертировать осознанно, а не «как получится».
Локальные методы вроде SEPA Debit, iDEAL, ACH полезны для B2B и для Европы, но у каждого свой профиль риска и срок. SEPA Debit удобен клиенту и медленнее в спорах. ACH дешевле карты и дольше клирится. Не включайте все методы мира в первую неделю. Включите карты, стабилизируйте dispute rate, затем добавляйте метод под конкретный рынок.
Presentment currency и settlement currency нужно задокументировать для бухгалтера. Иначе 1099-K, выписка Mercury и ваша CRM разойдутся на курсовой разнице, и вы будете объяснять банку «пропавшие» суммы, которых не было.
Письма, дескриптор и узнаваемость списания
Дружественный фрод часто рождается не из злобы, а из того, что человек не узнал платеж в приложении банка. Дескриптор Stripe по умолчанию может быть юридическим именем LLC, которое не совпадает с брендом продукта. Клиент видит «WYOMING LABS LLC», хотя покупал «CloudBoard». Настройка statement descriptor и statement descriptor suffix - обязательный шаг, не косметика.
Письмо о создании подписки, письмо за 2-3 дня до конца триала, чек об успешной оплате, письмо о неуспешной оплате со ссылкой обновить карту, подтверждение отмены - это минимальный набор. Тон короткий, сумма, дата, бренд, ссылка в кабинет. Не прячьте кнопку отмены в пятом пункте меню, если в рекламе обещали «без обязательств».
Для годовых планов добавьте напоминание за 14 дней до продления. Для команд - письмо не только владельцу карты, но и admin workspace. Корпоративные клиенты часто теряют сотрудника, который привязал карту, и узнают о списании, когда карта уже закрыта и пошел чарджбэк.
Поддержка должна иметь скрипт: как сделать refund, как поставить паузу, как сменить Price, как выдать credit note. Если каждый тикет эскалируется к основателю в Stripe Dashboard, вы не успеете к dispute deadline.
Возврат, кредит, пауза, отмена: четыре разных инструмента
Refund возвращает деньги на карту и влияет на выручку и иногда на риск-профиль, если рефандов слишком много. Его место - ошибка списания, дубль, явный фрод, первые дни, когда продукт не открылся.
Credit уменьшает будущие инвойсы, не гоняя деньги назад через сети. Его место - жест справедливости: простой сервиса, обещанный бонусный месяц, частичная компенсация.
Пауза сохраняет кастомера и останавливает списания на оговоренный срок. Ее место - сезонный B2B, отпуск основателя на стороне клиента, временный бюджетный стоп. Пауза должна иметь дату конца, иначе подписка умирает тихо.
Отмена прекращает автопродление. Ее место - осознанный отказ. После отмены сразу письмо: когда кончится доступ, что будет с данными, как вернуться. Молчаливая отмена без письма провоцирует человека написать в банк, а не вам.
Путать эти четыре действия в команде опасно. Менеджер обещает «поставим на паузу», инженер делает cancel, биллинг делает refund, клиент все равно идет в чарджбэк, потому что в выписке уже висит списание. Одно правило в Help Center важнее десяти личных договоренностей в Slack.
Корпоративные закупки, PO и почему B2B SaaS ломает card-first модель
Когда средний чек переваливает за несколько сотен долларов в месяц, появляется закупка. Клиенту нужен вендор в их форме: W-9, банковские реквизиты, security questionnaire, SOC-подобные ответы, DPA. Американская LLC с EIN закрывает W-9. Mercury дает реквизиты. Политики сайта закрывают часть security-вопросов про данные карт: «мы не храним PAN, процессор Stripe».
Не обещайте SOC 2, которого нет, чтобы закрыть сделку. Ложь в security questionnaire потом всплывает и в чарджбэке, и в расторжении. Честный ответ «мы стартап, карты токенизирует Stripe, данные в таком-то регионе, 2FA включен» проходит у части SMB. Enterprise все равно попросит больше. Это продуктовый фильтр, не платежный.
Purchase order не заменяет подписку в Stripe. Свяжите номер PO с Subscription metadata. Иначе через год никто не поймет, какой инвойс какому тендеру принадлежит, а банк спросит крупный входящий платеж.
Иногда корпорация платит wire на Mercury в обход Stripe. Это допустимо, если вы вручную отметили инвойс оплаченным и не держите параллельно активный авточардж той же суммы. Двойное списание - идеальный dispute.
Доступы, подрядчики и внутренний комплаенс маленькой команды
У стартапа из трех человек часто один пароль от всего. Для платежного контура это недопустимо. Stripe Dashboard - роли с минимальными правами. Бухгалтеру - read и invoices, не change bank. Маркетологу - не нужен Dashboard вообще, ему нужна аналитика продукта. Подрядчику на две недели - отдельный пользователь, который удаляется в день окончания акта.
2FA обязателен. Backup codes лежат не в том же Notion, где расписаны все секреты. API-ключи - в секретах CI, не в .env в репозитории. Restricted keys вместо secret key там, где хватает узких прав.
Ведите список, кто может сделать refund выше определенной суммы. Крупный возврат без правила - способ как для ошибки, так и для внутреннего фрода.
Когда фаундер уезжает и логинится из новой страны, предупредите банк не обязательно письмом каждый раз, но не используйте VPN-сервисы с датацентрами в нетипичных странах. Постоянный домашний IP плюс мобильный офис выглядят нормально. Прыжки «Нидерланды, Сингапур, США» за три часа - нет.
Что именно спрашивает живой underwriter у SaaS
По нашей практике ручные вопросы после первых платежей почти всегда из одного списка. Покажите продукт в работе. Поясните, почему столько платежей из страны X. Подтвердите, что вы оказываете услугу сами, а не агрегируете чужих продавцов. Пришлите политику отмены. Пришлите договор с крупным клиентом. Поясните связанность плательщика и бенефициара, если основатель сам себе крутит тестовые списания.
Ответ пишется спокойно, без агрессии «вы мешаете бизнесу». Короткие абзацы, скрины, ссылки, даты. Если чего-то нет, скажите, когда будет, и не присылайте чужие шаблоны с другим названием компании. Сотрудник это видит.
Не меняйте URL сайта посреди проверки. Не закрывайте лендинг на пароль в день, когда ждете апрув. Не переименовывайте юрлицо в Stripe, не завершив процедуру в штате.
Если запрос пришел от Mercury, а не от Stripe, все равно отвечайте в том же фактическом контуре. Истории «банку сказали консалтинг, шлюзу сказали SaaS» живут недолго: выписки все равно покажут descriptor Stripe.
Реклама, пиксели и платежный риск
Маркетинг думает о CAC, комплаенс думает о качестве карт. Связки, которые хорошо льют на триал, иногда льют и на stolen cards. Особенно это касается серых арбитражных связок, мотивационного трафика и обещаний «сделай деньги с нашего инструмента».
Креатив должен совпадать с сайтом. Если реклама обещает «гарантированный профит», а продукт - аналитика таблиц, вы получаете и претензии рекламных кабинетов, и чарджбэки, и вопрос Stripe про misrepresentation.
Пиксель Meta и Google на странице оплаты требует аккуратности с персональными данными и с Privacy Policy. Не передавайте в рекламные платформы параметры, которых нет в политике. Не логируйте card metadata в события аналитики.
Оплачивать рекламу лучше корпоративной картой Mercury или грузинской картой, а не личной картой, которая завтра умрет. Смешение личного и корпоративного рекламного кабинета потом мешает доказать source of funds и принадлежность трафика компании.
Масштабирование: от первых тысяч MRR к сумме, на которую смотрят сети
До примерно небольших тысяч долларов в месяц вас чаще судят по форме: документы, сайт, отсутствие фрода. Дальше начинают судить по метрикам. Dispute rate, refund rate, authorization rate, доля 3-D Secure, концентрация BIN, доля предоплаченных карт, скорость роста.
Если вы выросли за счет одного агентства, которое привело пачку сомнительных клиентов, остановитесь и почистите. Лучше потерять плохой MRR, чем весь мерчант. Если выросли за счет outbound в целевые компании, приложите это к запросу банка как объяснение.
На этом уровне появляется соблазн второго Stripe «на всякий случай». Второй аккаунт на ту же LLC без деловой причины выглядит как обход лимитов. Второй аккаунт оправдан при второй юрисдикции и отдельном бизнесе, а не как теневая копия.
Пора пересмотреть Radar: то, что было нормально на 20 платежах, слабо на 2000. Пора нанять или назначить человека, у которого в календаре стоит «разбор споров и failed payments». Пора закрыть 5472 и учет комиссий так, чтобы вы понимали юнит-экономику после эквайринга, а не до.
Связка компания Stripe счет при росте не меняется по форме. Меняется дисциплина. Вайоминг остается Вайомингом. Mercury остается операционным счетом. Stripe остается биллингом. Добавляются процессы, а не серые запасные кабинеты.
Как не запутаться в интеграциях: практическая схема для разработки
Архитектура, которая спокойно живет с комплаенсом, обычно такая. Клиент создается в вашей БД и в Stripe Customer с одним email. Checkout Session или Payment Element создает Subscription. Вебхук обновляет статус доступа. Продукт не считает «оплачено», пока не пришел invoice.paid или эквивалент для trial. Идемпотентность вебхуков обязательна: Stripe шлет повторно.
Не храните полный ответ с карточными полями. Не пишите в логи payment_method в открытом виде сверх того, что дает токен. Не стройте свой retry поверх Billing smart retries без причины: два ретрая одновременно портят и клиента, и метрики.
Для мобильного клиента не протаскивайте secret key. На бэкенде создается PaymentIntent или Checkout Session, в приложение отдается клиентский секрет. Для подписок из веба проще Checkout. Для кастомного кабинета - Element.
Тестовый режим и боевой не смешиваются. Отдельные webhook endpoints. Отдельные продукты. Ошибка «забыли переключить ключ» выглядит для вас как баг, а для клиента как списание без услуги либо услуга без списания. Второй случай потом бьет по выручке, первый - по чарджбэкам.
Документируйте внутренне, какой Price id соответствует какому тарифу на сайте. Через год маркетинговых экспериментов без этой таблицы Billing превращается в археологию.
Данные клиентов, поддержка и то, что нельзя писать в тикетах
Поддержка не должна просить CVV, полный номер карты, селфи с картой, пароль от банка. Для обновления метода оплаты есть Customer Portal и Checkout. Если клиент прислал фото карты, удалите вложение, скажите не делать так, дайте ссылку на портал.
В тикете достаточно последних 4 цифр, если они вообще нужны, бренда карты и даты списания. Все остальное - в Dashboard. Это и PCI-гигиена, и защита от утечки helpdesk.
Храните переписку. Для спора «я просил отменить» письмо в поддержке ценнее воспоминаний менеджера. Срок хранения согласуйте с Privacy Policy и не обещайте «удалим все мгновенно», если бэкапы живут 30 дней.
Если клиент угрожает чарджбэком, не отвечайте эмоционально. Предложите портал отмены, refund по политике, эскалацию. Запись этого диалога потом идет в evidence.
Когда продукт еще не SaaS, а вы уже хотите Stripe
Часть команд из СНГ называет SaaS лендинг курса, Telegram-бота с рассылкой или таблицу с доступами. Stripe может принять это как digital service, но риск-профиль ближе к инфопродукту: высокий чек, слабая доказуемость «услуги», много возвратов после просмотра.
Если это ваш случай, усильте витрину: что именно получает человек, на какой срок, как отменить, как доказать оказание. Снизьте годовую предоплату на старте. Требуйте карту на триале. Не покупайте прогрев через серые базы. И честно решите, нужен ли вам вообще рекуррент или хватит разовых платежей и инвойсов.
Если продукт действительно софт с кабинетом, логами использования и командами, подчеркивайте это на сайте. Комплаенсу проще одобрить «workspace software» с скринами, чем «платформу роста» без продукта.
Параллельный PayPal: как добавить, не раздвоив биллинг
Когда Stripe уже живет, PayPal добавляют как метод, а не как вторую вселенную тарифов. Идеально, если статус подписки все равно мастер в Stripe или в вашей БД, а PayPal только проводит money movement. На практике у PayPal свои подписки. Значит, нужен слой в продукте, который считает source of truth.
Минимальное правило: один кастомер не должен иметь активный Stripe Subscription и активный PayPal Recurring на один и тот же план. Иначе вы сами себе устроите двойное списание и двойной спор.
Верификация PayPal Business на ту же Wyoming LLC требует свой пакет: компания, сайт, банк или баланс, бенефициар. Заморозки PayPal разбирались нами отдельно, логика похожа: расхождение сайта и транзакций, резкий оборот, споры. Не переносите на PayPal ниши, которые только что едва прошли в Stripe.
Если клиент «платит только PayPal», иногда честнее выставить инвойс и принять PayPal как разовую оплату счета, не включая авторекуррент. Для B2B это часто достаточный компромисс.
Что делать, если часть фаундеров в разных странах
KYC это переживает, если доли прозрачны и все проходят идентификацию. Сложнее операционка: кто логинится в банк, из каких стран, кто подписывает. Зафиксируйте в Operating Agreement, кто manager для банковских действий. Дайте второму фаундеру роль, а не общий пароль.
Если один из участников не может предоставить proof of address, это решается до подачи, а не в день дозапроса. Не записывайте человека как 10% «чтобы не светить», если он фактически контролирует продукт и счет. Банк спрашивает control, не только юридический процент.
Смена состава после открытия счета - нормальная корпоративная процедура, но ее нужно отразить в документах и иногда заново пройти KYC. Молчаливая смена бенефициара при живых выплатах - красный флаг.
Годовой цикл обслуживания LLC, который забывают после апрува Stripe
Платежный запуск опьяняет, а штат и IRS не исчезают. Нужно помнить Annual Report Вайоминга к годовщине компании, продление Registered Agent, 5472/1120, учет reportable transactions, хранение выписок Mercury и экспортов Stripe, обновление политик сайта при смене тарифов.
Пропуск Annual Report ведет к штрафу и затем к administrative dissolution. Растворенная компания с живым Stripe - юридический и банковский кризис: вы принимаете деньги на юрлицо, которого штат больше не считает active. Это чинится reinstatement, но лучше не чинить, а не ломать.
Сменился адрес бенефициара - обновите его в банке при следующем осмысленном касании, не ждите, пока комплаенс сам найдет расхождение. Сменился домен - обновите URL в Stripe до того, как старый начнет отдавать парковку.
Этот контур скучный и именно он отличает «приняли платежи» от «работаем годами». Помощь по документам и структуре - на странице консультаций, регистрационные действия - на странице LLC.
Частые ошибки команд, которые уже умеют писать код
Инженеры часто делают идеальный биллинг на тестовых ключах и игнорируют legal name. Stripe сверяет компанию, а не ваш npm-пакет.
Продукт ставит lifetime-тариф «заплати раз и пользуйся вечно», а в MCC и в анкете - подписка. Lifetime для платежных сетей ближе к предоплате за неопределенный срок и хуже по чарджбэкам. Если очень нужно, лимитируйте объем, срок поддержки и не делайте это единственным оффером в первую неделю жизни аккаунта.
Маркетинг запускает перфоманс на гео, которого не было в анкете. Карты Нигерии, Пакистана, Бразилии при «мы продаем только в EU» выглядят как утечка. Либо честно расширяйте гео и правила Radar, либо не лейте туда трафик.
Фаундер лично рефандит друзьям из Dashboard без причины в CRM. Через полгода это невозможно объяснить банку.
В команде один Stripe-логин на всех. Уволенный подрядчик с full access - готовый инцидент.
Тестовые платежи боевой картой на 1 доллар десятками раз с разных BIN. Это card testing на самом себе, плюс мусор в статистике.
Обещание «отмени когда хочешь» при годовой предоплате без пропорционального возврата. Юридически можно. По спорам - дорого. Либо честно пишите non-refundable annual, либо давайте прорейтинг.
Как жить после запуска: операционка, которая сохраняет аккаунт
Раз в месяц смотрите dispute rate, refund rate, authorization rate, долю 3DS, долю иностранных карт, топ стран decline. Если споры растут, сначала продукт и коммуникации, потом «новые правила Radar».
Раз в квартал сверяйте описание бизнеса в Stripe, Mercury и на сайте. Запустили новый модуль «marketplace для подрядчиков» - это уже не тот же MCC и, возможно, уже Connect. Молча гонять чужие выплаты через свой мерчант нельзя.
Храните документы компании в одном месте: сертификат, Operating Agreement, EIN, паспорта, политики с датами версий, скрины онбординга. Комплаенс любит пакет за один заход.
Не выводите 100% остатка в день выплаты. Операционный буфер снижает вопросы и спасает, если прилетит резерв или рефанд.
Говорите с бухгалтером до распределения прибыли, а не после того, как деньги уже на личной карте.
Если продукт вырос в маркетплейс, читайте про Stripe Connect заранее. Standard, Express и Custom по-разному делят KYC продавцов. Платформа из СНГ с американской LLC может это тянуть, но это другой проект, не «галка в Billing».
Как разговаривать с клиентом и с комплаенсом одним языком
Самая дорогая привычка технических команд - держать три разных текста про один и тот же продукт. На сайте написано одно, в анкете банка другое, в письме клиенту третье. Для роста это выглядит как гибкость. Для финмониторинга это выглядит как несогласованная деятельность.
Соберите одну карточку продукта на одну страницу во внутреннем Notion или любом другом месте, куда смотрит вся команда. Название бренда и legal name LLC. Одно предложение, что делает софт. Кто покупатель. Какие тарифы и валюта. Есть ли триал и сколько дней. Есть ли годовая предоплата. Как отменить. Кто платит: карта, инвойс, ACH. Откуда трафик. Какие страны. Кто бенефициары и доли. Этот текст копируется в Mercury, в Stripe, в Terms, в ответы поддержки и в рекламные пояснения без творческой переписи каждый раз.
Когда продукт меняется, меняется карточка, затем сайт, затем шлюз. Не наоборот. Нельзя сначала начать списывать за новый модуль «маркетплейс подрядчиков», а через месяц вспомнить, что MCC и анкета все еще про обычный SaaS. Сначала квалификация, потом биллинг.
Та же дисциплина нужна в клиентских формулировках. Если в рекламе «без карты», а Checkout требует карту, вы получите и претензии, и плохие отзывы, и споры. Если в онбординге «отмена в любой момент с возвратом», а в Terms non-refundable annual, первый же внятный покупатель пойдет в банк. Платежная инфраструктура не прощает расхождения сильнее, чем баг в API: баг чинится релизом, а замороженные выплаты не чинятся хотфиксом.
Для фаундера из СНГ это особенно важно, потому что часть коммуникации идет на русском внутри команды, а наружу - на английском. Перевод «мы помогаем зарабатывать» в «guaranteed income tool» может случайно перевести вас в запрещенную или high-risk категорию. Перед публикацией английского лендинга проверьте не только грамматику, но и комплаенс-смысл обещаний. Если нужна страница, которая одновременно продает и проходит скан шлюза, это как раз задача лендинга под продукт, а не случайного шаблона с биржи.
И последнее в этом контуре: назначьте одного человека, у которого есть право менять публичные обещания про деньги. Не маркетолог в одиночку, не разработчик в одиночку, не подрядчик на перфоманс. Обещание про списание, триал, возврат и автопродление - это платежный риск компании. Его меняют сознательно, вместе с Billing и Terms, в один день.
FAQ
Можно ли открыть Stripe для стартапа из СНГ без иностранной компании? Нет. Stripe для SaaS в поддерживаемой модели привязан к юрисдикции мерчанта. Локальное ИП или ООО из неподдерживаемой страны не проходит онбординг. Рабочий путь - Wyoming LLC, счет и официальная верификация. Обходы через VPN и чужие кабинеты мы не делаем и не советуем.
Почему Giru регистрирует LLC только в Вайоминге? Потому что для нерезидента с цифровым продуктом это оптимальный баланс налогов штата, приватности, стоимости ежегодного поддержания и совместимости с Mercury и Stripe. Мы не регистрируем компанию в Делавэре «для солидности»: это не ускоряет эквайринг и не заменяет документы, сайт и KYC.
Нужен ли SSN, ITIN или визит в США? Нет. EIN получают без SSN. Банк и Stripe верифицируют нерезидента по паспорту, адресу и документам компании. Личный визит в США не требуется.
Сколько занимает связка компания, Mercury и Stripe? Ориентир - от 3 до 5 недель при полном пакете: 5-10 рабочих дней на LLC и EIN, 2-10 рабочих дней на Mercury, 3-10 рабочих дней на Stripe. Сроки последовательные частично перекрываются, но не складываются в «двое суток». IRS и комплаенс не работают как конструктор сайтов.
Можно ли подключить Stripe без сайта? Формально нужна витрина продукта. На практике без лендинга с политиками верификация чаще проваливается или уходит в ручной запрос. Соберите страницу заранее, хотя бы через лендинг.
Что будет, если зарегистрировать Stripe через VPN? Несоответствие геолокации, документов и банка почти гарантированно приводит к блокировке. Средства могут заморозить на долгий срок. Второй аккаунт на тех же данных ситуацию ухудшает. Используйте легальную компанию, а не смену IP.
Можно ли купить или арендовать готовый Stripe? Нет. Это чужой мерчант-аккаунт. Выручка вашего SaaS через чужое юрлицо нарушает правила платформы и AML-логику. Риск - холд, blacklist, потеря клиентов. Открывайте свой контур.
Чем Stripe лучше PayPal как основной шлюз для подписок? Stripe Billing, портал, вебхуки, антифрод и инвойсы заточены под SaaS. PayPal полезен как вторая кнопка и хуже как единственный рекуррентный движок. Споры PayPal часто тяжелее для продавца. Имеет смысл держать PayPal рядом, а не вместо Stripe.
Когда вместо LLC брать британскую LTD? Когда клиенты и договоры действительно завязаны на UK/EU и вам важен порог VAT £80,000, а не когда хочется «европейскую вывеску». LTD не престижнее Вайоминга для Stripe и не собирается за 24-48 часов вместе со счетом. Для долларового SaaS на США обычно короче Wyoming + Mercury.
Как принимать платежи за приложение: в сторе или через Stripe? Зависит от правил Apple и Google и от того, что именно вы продаете. Цифровые фичи внутри мобильного приложения часто требуют In-App Purchase. Веб-кабинет, B2B-тарифы и сценарии, которые сторы допускают как внешнюю оплату, можно закрывать Stripe Checkout или Payment Element. Юридический продавец все равно LLC, а не личная карта разработчика.
Что такое дуннинг и можно ли без него? Дуннинг - серия повторных списаний и писем, когда карта не проходит. Без него вы теряете MRR и провоцируете внезапные отключения, которые превращаются в чарджбэки. В Stripe Billing это настраивается штатно, это не кастомная наука.
Нужна ли PCI-сертификация «как у банка»? Если карта вводится на Checkout или в Element Stripe, и вы не храните PAN, вам нужна гигиена SAQ и запрет на логирование карт, а не строительство собственного эквайера. Не принимайте номера карт в Telegram и не пишите их в Notion.
Что будет, если не подать форму 5472? Фиксированный крупный штраф независимо от прибыли. Информационная обязанность появляется из-за иностранного владельца американской компании, а не из-за факта успеха продукта.
Mercury отказал. Можно сразу идти в другой финтех? Можно, но сначала исправьте причину: описание, сайт, расхождение документов. Тот же пакет без изменений часто получит тот же ответ. Payoneer не является автоматической заменой Mercury для выплат Stripe, хотя как второй контур полезен.
Нужна ли грузинская карта, если уже есть Mercury? Корпоративные карты Mercury закрывают часть расходов. Грузинская карта нужна, когда счет еще не открыт, когда конкретный сервис не принимает Mercury, или когда нужен личный иностранный пластик. Сейчас мы выпускаем карты грузинского банка-партнера.
Можно ли несколько продуктов на одном Stripe? Да, если они принадлежат одной LLC и близки по MCC и риск-профилю. Разные вселенные вроде «B2B SaaS» и «ставки на спорт» на одном мерчанте смешивать нельзя. Иначе проблема одного оффера уронит выплаты второго.
Что делать при запросе документов после первых платежей? Ответить быстро полным пакетом: сайт, политики, паспорта, EIN, Operating Agreement, скрины продукта, объяснение трафика. Неполный ответ продлевает холд. Игнорировать запрос - путь к disable.
Нужно ли раскрывать всех фаундеров? Всех, кто от 25% доли, и фактически всех, кто контролирует компанию, если банк спросит. Прятать партнера нельзя. Доли должны совпадать с Operating Agreement.
Можно ли начать на личном PayPal, а потом «переехать»? Личный PayPal не заменяет корпоративный биллинг SaaS и плохо переносит рост. Переезд подписок между шлюзами - отдельный проект с риском потерять мандаты карт. Лучше сразу корпоративная связка. Если PayPal нужен, открывайте бизнес-аккаунт на ту же компанию.
Что важнее на старте: идеальный код биллинга или документы? Документы. Идеальный код на заблокированном мерчанте не списывает ничего. Рабочий Billing на чистой LLC, счете и политиках можно итерировать. Обратный порядок в 2026 году по-прежнему самая дорогая ошибка разработчиков из СНГ.
Что делать дальше
Если продукт уже пишется, а платежей еще нет, не ждите релиза, чтобы «потом заняться юрлицом». Регистрация, EIN, банк, сайт и верификация живут своей длительностью. Их нужно запускать параллельно с полировкой онбординга.
Соберите одну нитку: компания в Вайоминге, Mercury, Stripe. Добавьте Payoneer и PayPal, если это нужно вашей воронке, а не потому что «у всех так». Закройте тексты через документы и витрину через лендинг. Для расходных операций, которые не проходят с карт СНГ, оформите грузинскую карту.
Giru проводит эту связку как один комплаенс-процесс: формулировки для банка и шлюза совпадают, бенефициар раскрыт, сайт выдерживает скан, биллинг поднимается на вашем юрлице, без VPN и без чужого кабинета. Для SaaS-разработчика это разница между «мы принимаем карты» и «мы надеемся, что аккаунт проживется до следующего спринта». Если вы запускаете подписки сейчас, а не «когда-нибудь после релиза», начните с инфраструктуры в том же спринте, в котором закрываете онбординг пользователя: юридический контур не ускоряется дедлайном продукта, и чем раньше он запущен, тем спокойнее первый боевой платеж.
