PromptPay и Merchant QR для тайской компании

Фраза «нам нужен PromptPay для компании» может означать несколько разных вещей. Одной компании достаточно принимать переводы на корпоративный счёт по понятному идентификатору. Другой нужен QR на кассе, где сотрудник видит подтверждение оплаты. Третьей нужен динамический код под каждый заказ и выгрузка, которую можно свести с учётной системой. Если начать с картинки QR, а не с процесса, эти сценарии легко перепутать.

Corporate PromptPay — это корпоративное расширение инфраструктуры PromptPay. В материалах Банка Таиланда для юридических лиц описана привязка 13-значного регистрационного номера компании к сберегательному или текущему счёту; для организаций без такого регистрационного номера может использоваться 13-значный налоговый идентификатор. После регистрации плательщик может отправить деньги компании, используя этот идентификатор вместо номера банковского счёта. Это удобный адрес получателя для перевода, но сам по себе он ещё не определяет, как кассир будет подтверждать оплату или как бухгалтерия свяжет её с конкретным заказом.

Thai QR Payment — более широкая платёжная рамка, в которой QR может предъявлять магазин или покупатель. Для обычной торговой точки особенно важен режим, когда продавец показывает код клиенту. Стандарт Банка Таиланда допускает статический QR, который остаётся одинаковым и может быть напечатан, и динамический QR, который создаётся заново для конкретной операции. Банки упаковывают это в разные продукты: приложение для торговой точки, QR на терминале, отдельный торговый кабинет или интеграцию. Название на сайте банка не всегда совпадает с тем, как предприниматель называет весь процесс.

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

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

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

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

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

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

Подключение начинается не с QR-кода, а с корпоративного банковского отношения. Банку нужно понимать, какое юрлицо получает деньги, какой счёт используется, кто вправе действовать от имени компании и соответствует ли заявленный способ приёма платежей профилю бизнеса. Для Corporate PromptPay Банк Таиланда описывает базовый набор: подтверждение счёта, документы подписанта или представителя, регистрационные документы компании, налоговые данные при наличии и доверенность, если действует представитель. При этом сам регулятор прямо допускает, что банк может запросить дополнительные документы.

Торговый продукт добавляет собственную проверку. Например, на странице Bangkok Bank для QR-платежей через терминал, проверенной 6 октября 2026 года, среди документов юридического лица перечислены регистрационное свидетельство Министерства торговли не старше трёх месяцев, коммерческая регистрация, документ уполномоченного подписанта, регистрация по НДС и отдельное решение, если средства должны зачисляться на счёт другого юридического лица. Это хороший пример механики подключения, но не единый список для всех банков и не правило, которое автоматически применяется к любой компании.

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

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

У статического QR одна сильная сторона: он почти ничего не требует от продавца. Код можно распечатать и оставить на кассе, а клиент сканирует его своим банковским приложением. По стандарту Банка Таиланда такой код остаётся одинаковым. В зависимости от продукта покупателю может потребоваться самому ввести сумму, поэтому кассир всё равно должен сопоставить фактическое поступление с тем, что было продано.

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

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

Срок окончательного зачисления и формат отчёта нельзя выводить из слова PromptPay. На странице Bangkok Bank по QR через терминал, проверенной 6 октября 2026 года, указано прямое зачисление средств на счёт и возможность отслеживать их в отчёте через веб-портал. Другой банк или другой торговый продукт может описывать процесс иначе. Поэтому до запуска лучше пройти полный тестовый путь: от того, какое имя получателя видит покупатель, до того, как операция выглядит в отчёте и банковской выписке.

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

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

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

Статический QR работает хуже всего именно там, где множество платежей похожи друг на друга. Две оплаты по 990 бат с разницей в три минуты можно различить по времени, но при большом потоке такой метод быстро становится ненадёжным. Динамический QR с суммой и доступным идентификатором операции уменьшает количество догадок, а для онлайн-заказов или нескольких касс иногда становится главным условием автоматизированной сверки.

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

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

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

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

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

QR-платёж отвечает на денежный вопрос: была ли проведена конкретная операция и поступили ли средства по банковскому или торговому каналу. Документы продажи отвечают на другой вопрос: что компания продала, кому, на какую сумму и какой документ должна выдать или сохранить в своей учётной системе. Смешивать эти уровни удобно только до первой сверки или налоговой проверки.

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

У Налогового департамента Таиланда существует отдельная система e-Tax Invoice & e-Receipt и технические требования к электронным налоговым документам. Сам факт оплаты через Thai QR не превращает запись в банковском приложении в такой документ. И наоборот, правильно оформленный налоговый документ не подтверждает, что деньги действительно зачислены: это проверяется по платёжной системе и счёту.

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

Банковские условия, требования к торговому подключению и налоговые документы меняются и зависят от статуса конкретной компании. Общая схема помогает разделить роли систем, но окончательный набор документов нужно сверять по выбранному банку, регистрации по НДС и действующим правилам на дату операции.

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

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

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

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