Ключевые темы
Связанные публичные страницы
Если нужен не только разбор, а страница продукта, API или операционного сценария, начните с этих разделов VPOS.am.
Payment status не должен заменять delivery status
Заказ может быть оплачен, но еще не собран, не передан курьеру, частично отменен или не доставлен.
В доставке один paid status не отвечает на главный вопрос поддержки: где заказ и что уже выполнено. Клиент мог оплатить заранее, заказ мог быть собран частично, курьер мог смениться, доставка могла не состояться или сумма могла измениться после замены товара.
Backend должен хранить order id, payment id, delivery id, courier reference, amount, currency, paidAt, delivery status and CRM/ERP status. Тогда оплата не теряется при смене курьера, а доставка не считается выполненной только из-за оплаты.
- разделять paid, packed, handed_to_courier и delivered;
- связывать payment request с order id и delivery id;
- не выдавать delivered по return URL оплаты;
- показывать support-friendly timeline в CRM.
Partial cancellation и замены должны пересчитывать сумму
В доставке часто меняется состав заказа, поэтому payment amount и final order amount могут отличаться.
Если часть товаров недоступна, клиент согласовал замену или изменилась delivery fee, нельзя просто оставить старую сумму как final business amount. Нужно отдельное событие: adjustment, partial cancellation, partial refund или operator review.
Для prepay-сценария полезно хранить original amount, adjusted amount, refund amount, reason and actor. Для pay-on-link после сборки заказа ссылка должна создаваться уже с подтвержденной суммой и сроком действия.
- хранить original amount и final amount отдельно;
- partial refund должен иметь reason и affected items;
- не создавать несколько активных ссылок на один заказ;
- manual price change должен попадать в audit log.
Proof of delivery нужен для поддержки и disputes
Когда клиент спорит с оплатой или доставкой, команда должна видеть payment reference, courier event и refund history вместе.
Для доставки особенно важен proof of delivery: timestamp, delivery status, courier event, customer confirmation или другой разрешенный внутренними правилами proof. Платежный backend не должен хранить лишние персональные данные, но должен иметь ссылки на нужные ids и статусы.
Сверка закрывает день по paid orders, delivered orders, cancelled orders, partial refunds, failed deliveries and provider report. Если эти статусы живут отдельно, бухгалтерия и поддержка будут вручную собирать историю заказа из разных систем.
- сохранять provider reference для оплаты и возврата;
- link delivery proof without excessive personal data;
- разделять failed delivery, refund и chargeback;
- сверять CRM, delivery system, ERP и provider report.
FAQ
Можно ли считать заказ доставленным после успешной оплаты?
Нет. Payment status и delivery status должны быть разными. Успешная оплата не означает сборку, передачу курьеру или доставку.
Как обрабатывать частичную отмену товара?
Сохранить adjustment event с affected items, reason, actor и суммой. При необходимости создать partial refund, не удаляя исходную оплату.
Что хранить для proof of delivery?
Хранить минимально нужные ids, timestamp, courier/delivery event reference и status. Лишние персональные данные не должны попадать в платежный лог.
