Денежный сертификат: остаток, доплата и связанный возврат

Сначала определите единицу сертификата

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

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

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

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

Сохраните три независимые связи

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

Вторая связь соединяет конкретное использование с конкретной покупкой. Она показывает, сколько стоимости этой покупки покрыто сертификатом. Третья соединяет ту же покупку с дополнительной оплатой другим способом. Сумма покупки служит основанием сверки, а не ещё одним денежным поступлением.

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

Учебный пример: 500 номинала и покупка на 650

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

Позже оформляется покупка на 650. По выбранному и подтверждённому распределению 400 покрываются сертификатом, ещё 250 — банковской картой. Проверка покупки: 400 + 250 = 650. Остаток сертификата: 500 − 400 = 100.

Новых внешних денег при второй покупке получено 250. За оба этапа их 500 + 250 = 750. Нельзя сложить первоначальные 500 с полной стоимостью последующей покупки 650 и показать поступление 1 150: часть 400 тогда будет посчитана повторно.

Контрольное равенство после покупки: 750 полученных денег соответствуют 650 покрытой стоимости покупки и 100 оставшегося номинала. Это сверка данного учебного потока при указанных ограничениях, не формула бухгалтерской выручки или прибыли.

Восстановление номинала требует своего основания

В продолжении примера уполномоченно согласован возврат части покупки на 100 именно на исходный сертификат. Предположим, что выбранный рабочий способ технически поддерживает этот результат и он подтверждён. Это программно-независимый сценарий журнала, а не обещание операции в конкретной кассе.

Остаток становится 100 + 100 = 200. Чистое использование сертификата по покупке равно 400 − 100 = 300. Чистая стоимость покупки после корректировки — 650 − 100 = 550; её покрывают 300 сертификатом и прежние 250 картой.

Нового внешнего поступления или денежной выплаты клиенту в этом действии нет. За всю историю по-прежнему получено 750: теперь это 550 чистой стоимости покупки и 200 доступного номинала. Исходное использование 400 сохраняется вместе со связанным восстановлением 100.

Не превращайте это равенство в универсальный порядок возврата. В актуальной инструкции Square для POS/Dashboard gift-card refund недоступен для split-tender transactions. Возможность в другом интерфейсе или API нужно проверять отдельно. Square US Support: возвраты на gift cards.

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

Square документирует автоматическое создание REDEEM после завершения платежа через Payments API и REFUND при соответствующем возврате через Refunds API. При собственном процессинге обязанности приложения отличаются. Поэтому нельзя одновременно принять автоматическое движение и добавить второе ручное списание той же суммы. Square: Gift Cards API и активности.

Отдельный Square-сценарий частичной оплаты использует фактически одобренную сумму, дополнительные платежи и завершение заказа через PayOrder после покрытия остатка. Он относится к Web Payments SDK и связанным API. Это не подтверждение одинакового поведения любого терминала. Square: partial payments с Square gift cards.

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

Возврат покупки сертификата является другим случаем

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

Square отдельно предупреждает: возврат платежа за покупку сертификата через Refunds API автоматически не уменьшает его баланс. Это отличается от возврата на сертификат. Ограничения интеграции Orders API.

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

Какие данные нужны сотруднику

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

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

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

Приёмочный чек-лист

1. Финансирование 500 связано с отдельным подтверждённым основанием.
2. Покупка 650 покрыта ровно частями 400 и 250.
3. После покупки доступны 100, новых внешних денег получено 250.
4. Неуспешная или неизвестная доплата не скрывается общим успехом покупки.
5. Подтверждённое восстановление 100 даёт номинал 200, а не денежную выплату.
6. Повтор исходного события не создаёт второго движения сертификата.
7. Возврат его первоначальной покупки проверяется отдельно от возврата на него.
8. Конкретный канал поддерживает выбранный сценарий; ограничения POS и API не смешиваются.

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

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

Использование сертификата является новой оплатой деньгами?

Оно покрывает часть покупки ранее предоставленным номиналом. В примере новые внешние деньги при покупке составляют только 250; финансовая классификация устанавливается отдельно.

Возврат на сертификат означает, что клиенту перечислили деньги?

Нет. В рассмотренном случае увеличился доступный номинал. Денежная выплата потребовала бы отдельного основания и подтверждения.

Достаточно вручную исправить итоговый баланс?

Нет. Сначала найдите пропущенное или ошибочное движение. Разрешённая корректировка должна объяснять причину и сохранять связь с исходной операцией.

Источники

• Square: Gift Cards API.
• Square: partial payments.
• Square US Support: refunds to gift cards.

Проверено 9 октября 2026 года. Суммы и программно-независимый сценарий возврата учебные.