1. Start with real supplier packages
Each package has a supplier identifier, destination, data type, data allowance, validity and wholesale cost. Those fields are normalized into our catalog so a specific package can be traced from the storefront to fulfillment.
2. Keep fixed data separate from daily/FUP plans
A package that offers “1GB per day” is not the same product as a package with 5GB total data. The catalog engine classifies them separately so a daily package cannot silently replace a fixed-data starter.
3. Apply minimum usefulness rules
The starter pool only includes packages that meet the configured minimum data allowance and validity. This prevents the headline price from being backed by an impractically tiny product.
4. Apply the wholesale ceiling
Only packages whose current wholesale cost fits the starter ceiling can qualify for the $5 slot. If the supplier cost rises beyond that guardrail, the engine looks for another eligible package. If none exists, the $5 starter should disappear rather than sell at an unsafe margin.
5. Choose the strongest eligible starter
Among eligible packages, the engine favors more total data and useful validity rather than simply selecting the cheapest wholesale line.
6. Price larger packages separately
Upgrades are priced from the supplier cost using minimum gross-profit and target-margin rules. That is why a 10GB or 20GB plan does not automatically cost a fixed multiple of $5.
7. Re-check before fulfillment
When live ordering is enabled, the order flow can submit the expected supplier cost with the package request. If the supplier price changed after the latest catalog sync, the order can be stopped instead of being fulfilled at an unexpected cost.
Until live API credentials and scheduled sync are configured, the storefront uses the latest imported supplier price-list snapshot. The data and wholesale figures are real for that snapshot, but they are not guaranteed to be live minute-by-minute.
