Онлайн-оплата в клиентском портале: закрыть счёт в один клик

Вторник, 09:40. У сотрудника, который отвечает за дебиторку, в почте лежат четыре почти одинаковых письма: «Пришлите, пожалуйста, счёт ещё раз», «Реквизиты не поменялись?», «Оплату отправил, платёжка во вложении», «К какому коммерческому предложению относится этот счёт?» Каждое письмо порождает одну и ту же работу: кто-то ищет счёт и выгружает PDF, кто-то открывает выписку и сверяет сумму, кто-то вручную ставит отметку «оплачено». Три экрана, три человека и, как правило, полдня задержки на один счёт. На стороне клиента этот же счёт выглядит одной строкой: сумма к оплате и дата.

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

Почему кнопка оплаты должна стоять рядом со счётом?

Вкладка Счета в клиентском портале показывает выставленные, отправленные, частично оплаченные и оплаченные счета в хронологическом порядке. Список информирует, но не завершает дело. Клиент видит строку «не оплачен 20 дней», решает заплатить — и, если рядом нет действия, намерение уходит в другой канал: он открывает банковское приложение, ищет реквизиты, пишет вашей команде, а затем забывает. Значительная часть просрочки возникает не из решения не платить, а из лишних шагов между намерением и действием.

Та же логика работает и вне портала: одноразовая платёжная ссылка, отправленная прямо в переписке, сокращает дистанцию точно так же. Разница — в сроке жизни. Ссылка создаётся под одну операцию и истекает, портал же остаётся постоянным адресом. Через три месяца клиент возвращается и находит старый счёт, его статус оплаты и сам документ в одном месте.

Функция Скачивание PDF счёта закрывает картину: клиент выгружает каждый свой счёт документом, который формируется только под его запись. Так и просьба «пришлите копию», и вопрос «куда платить» решаются на одном экране. Кнопка оплаты рядом со счётом — это не вопрос оформления, а операционное решение, которое сокращает срок поступления денег.

Из чего на самом деле состоит «оплата в один клик»?

Клиент видит один клик. За ним стоит минимум шесть шагов. Первый — идентификация: в сценарии Вход без пароля (Magic Link) клиент вводит адрес почты, переходит по одноразовой ссылке и попадает в портал. Пароля нет — значит, нет и оплаты, брошенной из-за забытого пароля. Второй — видимость: клиент видит только выставленные документы, привязанные к его собственной записи. Третий — фиксация суммы: списывается не значение, пришедшее из браузера, а остаток, прочитанный на сервере.

Четвёртый шаг — передача провайдеру, пятый — подтверждение карты, шестой — возврат ответа. Если вы работаете с крупными корпоративными заказчиками, для которых идентификация должна идти через корпоративный каталог, объединение аутентификации через единый вход — отдельная задача. В портале задача обратная: дать клиенту защищённое окно, не заставляя его заводить учётную запись.

Когда шесть шагов ощущаются как один клик, клиент ждёт того же и от остальных действий в портале. Тот, кто оплатил счёт за две секунды, хочет за две секунды подтвердить и визит; поэтому сценарий Подтверждение и перенос записи построен по той же логике и попадает в ту же карточку, что и внешние ссылки на онлайн-запись, которые пишут бронь прямо в CRM. Ценность самообслуживания не в одной операции, а в том, что все рутинные операции завершаются в одном месте.

Какие решения принять до включения приёма платежей?

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

Ни один из этих вопросов не решается по универсальному списку «лучших провайдеров», потому что все они договорные. Чтобы сравнить платёжные шлюзы при построении инфраструктуры приёма оплаты, нужны ваши собственные цифры: оборот, средний чек и частота возвратов. Ставки и сроки зачисления читайте в договоре с провайдером, а порядок отражения в учёте согласуйте с бухгалтером.

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

Какой способ оплаты подходит какой ситуации?

Один способ не подходит всем счетам. Таблица ниже показывает, где каждый маршрут оправдан в процессе, построенном вокруг портала, и во что он обходится операционно. Любые пороги вокруг неё задавайте по своему среднему чеку и своей доле возвратов — цифры из чужой практики здесь не работают.

Способ	Когда подходит	Операционная цена
Оплата картой внутри портала	Повторяющиеся счета среднего размера; клиент уже пользуется порталом	Комиссия; возвраты идут через провайдера
Платёжная ссылка	Клиент ещё не в портале; разовая оплата из переписки или письма	Срок жизни ссылки и контроль ведутся отдельно
Банковский перевод	Крупные корпоративные счета	Ручная сверка и сопоставление платёжек
Оплата по QR-коду	Выезд, доставка, оплата на месте и в торговой точке	Поддержание печатных материалов в актуальном виде
Рекуррентное списание	Подписки и договоры на обслуживание	Срок действия карты и работа с неудавшимися списаниями

QR-маршрут особенно выручает в поле: команда, которая знает, как сделать QR-код для меню, оплаты или визитки, закрывает оплату прямо в момент передачи работы. Но если адрес за кодом не привязан к записи счёта в портале, выигранную скорость вы отдадите обратно на сверке.

Что должно измениться в записи при подтверждении оплаты?

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

Второй выигрыш — прослеживаемость. Журнал активности фиксирует просмотры, сообщения, запросы правок и оплаты по одному, а Мгновенные уведомления доходят до команды в момент события, причём двойной клик не порождает два уведомления. Той же дисциплины ждите и от платежей: если одна операция придёт дважды, запись не должна закрыться дважды, а остаток — уменьшиться дважды.

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

Как показывать в портале частичную оплату и рассрочку?

В жизни счета не всегда закрываются одним платежом. Поэтому список счетов в портале несёт статус «частично оплачен» как отдельный. Когда клиент вносит часть суммы, на экране он должен видеть остаток, а не сухое «не оплачен». Любой порог вокруг этого — минимальный первый взнос, граница для рассрочки — считайте от своего среднего чека, а не от чужого правила.

Решающим здесь оказывается место расчёта. В поведении Частичное принятие предложения клиент может принять только выбранные позиции, и сумма принятого пересчитывается на сервере. В приёме оплаты нужно то же правило: остаток считается на сервере, потому что за прошедшее время мог прийти другой платёж, пройти возврат или примениться скидка.

Как только частичная оплата разрешена, у вас появляется и ценовой рычаг для управления поведением. Связка скидки за раннюю оплату с надбавкой за отсрочку заметно влияет на клиента, который видит в портале, что сумма зависит от даты платежа. Но отражать скидку в самом счёте или отдельной записью — вопрос с учётными последствиями; согласуйте эту часть с бухгалтером до запуска.

Кто отвечает за неудавшиеся платежи, возвраты и споры?

Чаще всего в платёжном сценарии не продумывают именно отказ. Одну карту отклонят из-за лимита, другую — из-за незавершённого подтверждения, третью — по риск-правилам банка-эмитента. Клиент видит «оплата не прошла» и в большинстве случаев не пробует снова. Поэтому неудавшаяся операция не должна быть тихим событием: она должна дойти до команды, записаться в карточку и через разумный интервал вернуться клиенту напоминанием.

Возвраты — отдельная тема. Возврат отправляет деньги обратно и проходит на стороне провайдера; спор инициирует банк клиента, и у него свои сроки и требования к доказательствам. Решите заранее, как каждый из них отражается на статусе счёта в портале. Оставить возвращённый счёт в статусе «оплачен» — значит через три месяца получить расхождение, которое никто не распутает.

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

Как выстроить безопасность оплаты и договорную рамку в портале?

Безопасность на стороне портала держится на двух слоях. Первый — сессия: в поведении Безопасный доступ сессия открывается отдельным токеном на 24 часа и никогда не переходит в обычный доступ к API; по истечении срока клиент запрашивает новую ссылку. Постоянный пароль не создаётся вообще, поэтому и красть нечего. Второй слой — сам экран входа: Вход без утечек не раскрывает, зарегистрирован ли введённый адрес, ответ одинаков в любом случае, и через портал нельзя перебрать вашу клиентскую базу.

По карточным данным правило простое: данные карты не хранятся у вас, они вводятся на платёжной странице провайдера. Это переносит и поверхность атаки, и нагрузку по соответствию требованиям на провайдера. К той же дисциплине относится поведение Только утверждённые документы: черновики предложений, а также черновые и аннулированные счета в портал не попадают — клиент видит только утверждённое и действительно оплачиваемое.

Договорная часть — это уже право, а не продукт. Какие сведения и в какой момент вы обязаны раскрыть покупателю при дистанционной продаже, определяется опубликованными вами условиями; аналог договора дистанционной продажи и его состав должен быть на месте и актуален ещё до открытия платёжного экрана. Поведение Электронная подпись закрепляет в записи имя подписавшего, время и IP-адрес и даёт сильный доказательственный след, но какой именно вид подписи требуется конкретному документу — вопрос к вашему юристу.

По каким показателям судить, что оплата в портале работает?

После включения приёма платежей мерить нужно не клики, а срок поступления денег. Большинству команд хватает четырёх показателей. Средний срок оплаты — сколько дней проходит от выставления счёта до зачисления. Доля портала — какая часть поступлений пришла через портал. Доля первых 48 часов — сколько счетов закрывается в первые двое суток после просмотра. И доля неудавшихся операций вместе с тем, какая их часть закрывается со второй попытки.

Вместе эти четыре цифры отделяют инфраструктурную проблему от поведенческой. Высокая доля отказов указывает на платёжный стек; низкая доля портала при своевременных поступлениях — только на привычку канала. Если вы хотите распознавать медленных плательщиков заранее, оценка риска неплатежа по прошлому поведению клиента экономит больше сил, чем сплошное увеличение частоты напоминаний.

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

Частые вопросы

Нужен ли клиенту аккаунт, чтобы оплатить?

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

Что будет со счётом, если подтверждение не придёт?

Запись останется открытой. Статус счёта меняет подтверждение провайдера, а не то, что клиент увидел на экране. Пока подтверждения нет, счёт остаётся неоплаченным и не уходит из списка на взыскание.

Можно ли переложить комиссию на клиента?

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

Отслеживает ли портал клиентов, которые платят переводом?

Статус счёта в портале виден, но сопоставление перевода — это сверка с банковской выпиской. Как только совпадение записано в карточку, клиент видит статус «оплачен»; если сверка задерживается, он видит неоплаченный счёт, который уже оплатил, и напишет вам.