SMART COD PRO · Included in every PRO plan
An additional risk signal, under your control.
Combine delivery history and order context with an available validated model. You set the threshold and the checkout action.
How it works
An extra layer of context, with an explicit policy.
Checkout rules describe known cases. Delivery history adds recorded outcomes. ML can add an available model’s risk assessment using the supported history and order context. These are separate layers: you do not have to replace your shipping, product or fee rules to configure an ML response.
You set the minimum risk score and the action to take when that threshold is reached. A higher score means higher assessed risk. It is not the model’s confidence percentage or a promise about whether this particular order will be collected.
ML · AN ADDITIONAL CAPABILITY
One more estimate. The decision stays yours.
An available, validated model combines history and order context. You decide when a risk estimate changes checkout.
Delivery historyEvidence from your store and the eligible network.
Order contextCart, shipping and available checkout context.
Your own policy
Choose the threshold and protection action.
Hide COD · collect a deposit · verify emailThe explanation in your audit See whether ML was used and how it contributed to the decision. Your rules and history-based protection operate independently.
How ML risk assessment worksYou enable history-based protection. *ML policies require an available, validated model; inclusion does not promise active scoring for every store.
Your checkout, your rules
Choose a practical checkout response.
The response can hide COD, request a separately configured deposit or require email verification. Choose the level of friction that fits your store’s policy. If you use a deposit, its ML amount is configured separately from history-based and ordinary deposit rules.
An ML policy requires an available, validated model. PRO’s inclusion of ML controls does not mean that active scoring is available for every store. The decision audit records model availability, status and the score or factors when available, so an unavailable model is not confused with a low-risk result.
In practice
Example scenarios
Illustrative rules and amounts. You choose the values that fit your store.
| When this happens | Your chosen result |
|---|---|
| Threshold 80; an available score is 79 | The ML threshold is not met. Other rules and history can still apply. |
| Threshold 80; an available score is 80 or above | The configured ML action can apply, subject to the overall decision priority. |
| No validated model or score is available | The audit records availability; a missing score is not presented as a successful low-risk prediction. |
What the customer experiences
The customer sees the configured checkout response, such as a deposit request or the remaining payment methods. The merchant can read the audit to understand whether ML contributed, a normal rule matched, or delivery history determined the action.
Settings & setup
Set it up in your store
Set the threshold and action in the ML settings, then review recorded decisions. Start by understanding the available model status and the reasons in the audit. The rule and history settings remain independently configurable.
Questions about this feature
Does PRO need ML to hide COD or calculate fees?
No. Checkout-condition rules, fees and ordinary deposit rules work independently of model availability.
Where can I see whether ML actually contributed?
In the decision audit, alongside the applied action, model status and available score or factors.