Возврат не должен быть ручной заметкой в заказе
Refund - это отдельная платежная операция со статусом, суммой, правами доступа и журналом.
После запуска онлайн-оплаты бизнес почти сразу сталкивается с возвратами: отмена заказа, недоступный товар, частичная отгрузка, ошибка клиента или спор. Если возврат оформляется вручную без связи с исходным платежом, поддержка и бухгалтерия быстро теряют контроль.
Правильный refund flow начинается с проверки исходной оплаты: существует ли payment id, был ли платеж successful, какая сумма уже возвращена и разрешен ли возврат пользователю, который его инициирует. AEB в требованиях к vPOS отдельно указывает хранение информации о транзакциях и товарах/услугах минимум один год; для refund flow это практический минимум аудита, даже если выбран другой провайдер.
- возврат связан с исходным order id и payment id;
- инициатор и причина фиксируются в audit log;
- сумма не превышает доступный остаток;
- CRM/ERP получает отдельный refund status.
Частичный возврат требует отдельной модели
Partial refund нельзя проектировать как простой переход заказа из paid в refunded.
При частичном возврате заказ может оставаться частично оплаченным, частично выполненным или закрытым с корректировкой. Поэтому статус заказа и статус платежа нельзя смешивать в одно поле.
Backend должен хранить исходную сумму, сумму всех успешных возвратов и доступный остаток. Повторная попытка возврата должна быть idempotent, чтобы один запрос не вернул деньги дважды. Это особенно важно для CRM/ERP: order может остаться fulfilled, а payment перейти в partial_refunded.
- original_amount;
- refunded_amount;
- available_to_refund;
- refund_attempt_id;
- refund status: pending, succeeded, failed.
Фискализация и учет после возврата
Если после оплаты создается чек, refund flow должен учитывать корректировку фискального и учетного слоя.
Если бизнес фискализирует онлайн-оплаты, возврат может требовать отдельного фискального действия или корректировки. В Армении электронная фискализация регулируется через электронные кассовые аппараты/HDM, поэтому payment refund и fiscal correction нельзя смешивать в одну кнопку без статусов и журнала.
Лучше делать фискальную обработку асинхронной: платежный возврат может завершиться быстрее, чем фискальная корректировка. При этом менеджер должен видеть оба статуса и понимать, где требуется retry или ручной разбор.
- payment refund status отдельно от fiscal correction status;
- очередь и retries для фискальных событий;
- аудит ручных корректировок;
- сверка с банковским отчетом и ERP.
FAQ
Можно ли сделать возврат прямо из CRM?
Да, если CRM вызывает backend endpoint с проверкой прав, суммы и исходного платежа, а не меняет статус заказа вручную без платежной операции.
Почему partial refund сложнее полного возврата?
Потому что нужно считать уже возвращенную сумму, остаток, статус заказа, фискальную корректировку и возможные повторные попытки.
Нужен ли audit log для возвратов?
Да. Возврат влияет на деньги, учет и поддержку, поэтому нужно знать кто, когда, почему и на какую сумму инициировал операцию.
Источники
- Armeconombank - VPOS conditionsОфициальные условия vPOS, включая требования к хранению транзакционной информации.
- Stripe Docs - RefundsОфициальная документация с базовой моделью full/partial refunds и статусами возврата.
- State Revenue Committee of ArmeniaОфициальный сайт налоговой службы Армении для проверки актуальных требований по HDM/фискализации.
