Key topics
Related public pages
If you need the product, API or operations page rather than only the article, start with these VPOS.am sections.
Payment status should not replace delivery status
Order can be paid but not yet picked, not handed to courier, partially cancelled or not delivered.
In delivery, one paid status does not answer the main support question: where is the order and what has already happened. Customer may have prepaid, order may be picked partially, courier may change, delivery may fail or amount may change after item replacement.
Backend should store order id, payment id, delivery id, courier reference, amount, currency, paidAt, delivery status and CRM/ERP status. Payment is not lost when courier changes, and delivery is not treated as completed only because payment succeeded.
- separate paid, packed, handed_to_courier and delivered;
- connect payment request with order id and delivery id;
- do not mark delivered from payment return URL;
- show support-friendly timeline in CRM.
Partial cancellation and replacements should recalculate amount
Delivery orders often change, so payment amount and final order amount can differ.
If some items are unavailable, customer agreed replacement or delivery fee changed, old amount should not remain final business amount automatically. A separate event is needed: adjustment, partial cancellation, partial refund or operator review.
For prepay scenario, store original amount, adjusted amount, refund amount, reason and actor. For pay-on-link after order picking, link should be created with confirmed amount and expiration.
- store original amount and final amount separately;
- partial refund needs reason and affected items;
- do not create several active links for one order;
- manual price change should enter audit log.
Proof of delivery is needed for support and disputes
When customer disputes payment or delivery, team should see payment reference, courier event and refund history together.
Proof of delivery is especially important for delivery: timestamp, delivery status, courier event, customer confirmation or another proof allowed by internal rules. Payment backend should not store unnecessary personal data, but it should keep links to required ids and statuses.
Reconciliation closes day by paid orders, delivered orders, cancelled orders, partial refunds, failed deliveries and provider report. If these statuses live separately, accounting and support will manually rebuild order history across systems.
- save provider reference for payment and refund;
- link delivery proof without excessive personal data;
- separate failed delivery, refund and chargeback;
- reconcile CRM, delivery system, ERP and provider report.
FAQ
Can order be treated as delivered after successful payment?
No. Payment status and delivery status should be separate. Successful payment does not mean picking, handoff to courier or delivery.
How to handle partial item cancellation?
Store adjustment event with affected items, reason, actor and amount. Create partial refund when needed without deleting original payment.
What should be stored for proof of delivery?
Store only necessary ids, timestamp, courier/delivery event reference and status. Excessive personal data should not enter payment log.
