COD protection and order-history data sharing

Release notice: This page describes the upcoming Smart COD Free 1.9.5 and PRO 1.7.4 releases. Installed older versions continue their existing cancellation-only collection. After updating, an existing opt-in also enables the lifecycle collection described below, without another activation step. Stores with sharing disabled remain disabled.

This optional service is off by default in both Smart COD Free and PRO. It operates after a store administrator explicitly activates sharing in WooCommerce → Settings → Payments → Cash on Delivery. The receiving service is api.woosmartcod.com.

What changes in the new release, and why

Previously, collection focused on eligible cancelled COD orders with shipment or fulfilment evidence. The expanded scope also records future physical COD orders when they are created and follows their subsequent outcomes. Successful outcomes provide context for cancellation history and support a configurable successful-history allowance in the same store. The data also supports cross-store machine-learning development and training, subject to server-side eligibility review. Collecting data does not mean an ML score is already deciding checkout availability.

Which orders are collected

While the sharing setting is enabled, new physical COD orders are recorded at checkout creation. Later changes include completed, cancelled, refunded, reopened and other reported statuses.
A tracking code and a 24-hour wait are not required for this new lifecycle collection. A COD order cancelled minutes after creation may therefore be recorded.
Orders paid by other methods, virtual-only orders and recognized separate deposit-payment child orders are excluded.
The existing filtered cancellation relay remains for eligible historical and future cancellation evidence. We do not import all historical creations or completed orders. An older order first observed after activation is marked as a late observation, not represented as an original checkout snapshot.
Transmission runs in small signed background batches with acknowledgments, retries and duplicate protection. The plugin itself does not call courier APIs.

Collection is not an automatic COD restriction

A cancellation alone does not prove refusal or non-delivery, and not every collected cancellation is a qualifying negative match. The current Free/PRO rule checks only directly matching email or phone history from the same installation. It does not use other stores’ records to restrict COD.

Qualifying cancellation evidence retains the existing shipment/fulfilment checks: tracking, physical-order completion before cancellation, or a transition from a shipped/fulfilled status. A lower-confidence fallback without tracking is available only when no recognized tracking integration is present, at least 24 hours elapsed between creation and cancellation, and the known previous status is a fulfilment-stage status. These are alternative evidence paths: tracking and 24 hours are not two mandatory conditions for every order.

The minimum successful COD rate is configurable from 50% to 100%, with a default of 90%. At 90%, 9 successful and 1 qualifying failed order keep COD available under this history rule. Choosing 100% means a qualifying failure cannot be overridden by successful history. Pending orders do not count. Other COD restrictions still apply.

WooCommerce completed is a merchant-reported outcome, not automatic courier confirmation. Reopened, refunded or inactive lifecycle completions are not current successes. Because older completion counts are cumulative snapshots, they are not added to new individual completion rows: a conservative maximum avoids counting the same orders twice. The rate reflects known eligible history, not a claim that every historical delivery has been individually imported.

A service timeout or invalid response does not itself hide COD; the store’s other rules remain authoritative.

Information transmitted

Registration includes a generated installation identifier, shop domain, plugin/version, operating country and public signing key. Lifecycle events include a pseudonymized order reference, creation context and subsequent status revisions; currency and monetary amounts; timestamps and local hour/day; shipping method; item count; guest/registered status; hashed email, phone and postcode identifiers; and courier/tracking where available. The compatibility cancellation relay may additionally carry hashed city/region identifiers, elapsed order time, shipment evidence and a capped count of earlier completed, tracked COD orders.

Checkout protection requests send the installation identifier, operating country, hashed available email/phone identifiers and the selected successful-history policy. In the new release, the server returns only its decision, a decision reference and the applied policy metadata, not customer-history counts. The service records aggregate operational statistics and pseudonymized supporting evidence for actual denials, including the policy and counts used. This is separate from storing every raw checkout lookup as a new order event. Free and PRO do not include a customer-facing decision audit screen.

Raw customer names, email addresses, phone numbers, postal addresses, product names, payment-card details, account passwords and WooCommerce order IDs are not transmitted for this feature. Tracking codes, when available, are operational shipment identifiers and are not described as anonymous data.

How information is used and secured

Same-store COD protection uses qualifying history and successful outcomes. Cross-store ML training uses eligible production observations and subsequent outcomes, with the history that was known at the time of the order. An old cancellation without an original creation snapshot is not fabricated into a prospective training example. Merchant cancellation is not automatically labelled as confirmed non-delivery.

Transport uses HTTPS and signed requests; event ingestion also checks request nonces to reject replay. Customer identity tokens receive an additional secret-keyed transformation before central storage. Initial creation context and subsequent event revisions are retained separately so retries do not create duplicate orders and changes can be traced.

Pseudonymized data can still be personal data. Store owners must assess the appropriate legal basis and customer-facing information for their own processing; enabling a merchant setting is not, by itself, the shoppers’ consent.

Activation, upgrades and stopping sharing

There is one sharing setting for new and existing installations. An enabled setting remains enabled after updating and applies to the lifecycle collection described here, without a separate activation or upgrade notice. A disabled setting remains disabled. The settings and this page explain collection and checkout rules; the administrator can switch sharing off at any time.

Turning sharing off stops future capture, transmission and remote checkout checks and cancels pending scheduled sharing jobs. It does not delete orders in WooCommerce or automatically erase records previously received by the service. If sharing resumes, affected snapshots spanning the gap are excluded from the prospective training cohort.

For retention, access or deletion enquiries, contact info@woosmartcod.com with enough information to identify the shop and request safely. Review the Privacy Policy and Terms and Conditions. This page explains product behaviour and does not replace legal advice or the merchant’s privacy notice.