Operating COD and Bank Transfer with a Reviewable Payment Record

Turn COD and manual transfer from scattered messages into explicit states, references, private proof, review, and audit.

Shop Tek EditorialUpdated 2026-08-08

A payment method is an operating contract

Adding a checkout label is easy; operating it safely requires an explicit contract between shopper, merchant, and staff. Cash on delivery needs a stored collection amount, confirmation rule, dispatch boundary, delivery event, and refusal response. A bank transfer must stay pending until the merchant sees funds in the account. A shopper reference or screenshot supports review, but it is not automatic evidence that money settled.

Show only what the merchant can fulfill

COD appears when the store enables it and the order remains within its configured cap. Manual transfer appears only after the merchant publishes an account or clear instructions. CliQ is a Jordan-only choice when a usable merchant alias exists. Cards, wallets, carriers, and invoice providers must not appear because an interface exists in source code; public availability means the account, approval, monitoring, support, and operating runbook are live.

Give every order one reference

The order number connects shopper status, bank activity, and the merchant desk. Ask the shopper to use it in the transfer narrative, then retain the bank reference separately when one exists. Names and phone numbers are poor reconciliation keys because they repeat and change. Resubmitting the same reference should be idempotent and must not create a second payment.

Review transfers explicitly

The shopper submits a reference or a private proof file. The server validates MIME and size, stores the object outside public paths, records a checksum, and exposes it only to an authorized finance role. Staff checks the actual bank account for amount, currency, and reference. Approval updates payment and order state in one transaction and adds a shopper-visible event. Rejection keeps payment pending and requests a clear correction.

Set an expiry window

An open transfer can reserve stock indefinitely and pollute order queues. Configure a reasonable window and run a scheduled task that marks overdue submissions expired. Do not delete evidence or decision history as part of expiry. Data retention determines object lifetime, while the audit ledger preserves the fact that a submission and review occurred.

Operate COD separately

The driver collects the exact amount snapshotted on the order in its currency. Delivery records collection and completion. Refusal creates a traceable stock correction and contributes to customer risk. Calling before dispatch can reduce refusal for high-value or higher-risk orders, but that decision should be recorded instead of living only in a phone conversation.

Separate receipts from statutory invoices

An order receipt can show lines, configured tax, shipping, COD fee, currency, and business identity captured at purchase. Calling it a statutory tax invoice requires the approved jurisdiction workflow. When that integration is unavailable, provide a clear receipt and an approved external invoicing process instead of implying compliance.

Test the boundaries

  • COD below and above its cap.
  • Transfer with reference only, proof only, and corrected proof after rejection.
  • Repeated approval that never duplicates settlement.
  • Expiry racing with merchant review.
  • Unauthorized staff unable to view proof or approve payment.
  • Another tenant denied even when it knows the record identifier.
  • Refund currency and amount matching the original order snapshot.

The goal is not the largest payment logo collection. It is a smaller set of visible methods that the merchant can execute, explain, reconcile, and refund without side-channel messages or invisible decisions.

Shop Tek Editorial

A product team reviewing catalog, order, payment, inventory, and delivery workflows for regional commerce.

Back to Shop Tek Blog