NTN ECOMM common mistakes
NTN ECOMM · Understand the traps and how to avoid them.
Classifies a business model as a reseller/retailer whenever the storefront shows stock levels and accepts payment, even when the operator never takes title to the goods.
Candidates key off surface features of the website (catalog, cart, checkout) instead of the commercial structure behind it, so a marketplace, drop-ship, or consignment operation gets labelled as first-party retail.
What to do instead
Before answering, identify three things for the scenario: who holds inventory risk and takes title, who is merchant of record for the customer charge, and who sets the price. Title + pricing control + merchant of record = reseller; third-party sellers + platform fee = marketplace.
Concludes that a store is PCI DSS compliant because checkout is served over HTTPS with a valid TLS certificate.
Encryption in transit is the most visible security control, so it gets conflated with the full standard, which also covers storage of cardholder data, access control, network segmentation, logging, and validation via the correct SAQ type.
What to do instead
Separate the two ideas explicitly: TLS protects data in transit and is one PCI DSS requirement among many. Then determine scope from the integration method - hosted payment page or tokenisation (SAQ A/A-EP) versus direct card data handling (SAQ D) - and answer on that basis.
Reports ROAS as ROI when asked which campaign is actually profitable, e.g. citing '400% ROI' for a campaign with 4:1 revenue-to-ad-spend.
Both metrics compare revenue to spend and the colloquial use of 'return' blurs them; candidates also forget that ROI must absorb cost of goods, shipping, and fees, not just media spend.
What to do instead
Write the formulas down before answering: ROAS = revenue / ad spend (a ratio, no COGS); ROI = (gross profit − total cost) / total cost (a percentage, COGS included). If a question says 'profitable' or 'net', it wants ROI.
Sets a target-margin price using cost × (1 + margin %), producing a price that yields a lower margin than requested.
Markup and margin use the same numbers against different bases (cost vs price), and the markup formula is the one people memorise first, so it gets applied to a margin target.
What to do instead
Attach the base to the formula: margin % = (price − cost) / price, so price = cost / (1 − margin %); markup % = (price − cost) / cost. Sanity-check with a $100 cost and 40% target: margin gives $166.67, markup gives $140.
Marks an order as paid, and releases it to fulfilment, as soon as the gateway returns an authorisation approval.
Most gateway dashboards surface 'approved' at the front of the flow, so authorisation is mistaken for settlement; the later capture and settlement steps are invisible unless you look for them.
What to do instead
Track the payment lifecycle as distinct states - authorised, captured, settled, refunded, reversed. Only a successful capture collects funds, and only settlement clears them; an authorisation can expire, be partially captured, or be voided.
Auto-cancels any order where AVS fails or the CVV check mismatches, treating it as confirmed fraud.
These checks return pass/fail-looking results, so they read as verdicts rather than weighted risk signals; the cost of false declines and lost good customers is not visible in the fraud console.
What to do instead
Treat AVS and CVV as inputs to a scored rule set with review thresholds: hard-block only on high-risk combinations (e.g. repeated failures plus mismatched billing country plus expedited shipping), and route the ambiguous middle band to manual review rather than auto-cancel.
Assumes units are reserved against stock as soon as a shopper adds to cart, then answers overselling and availability questions on that assumption.
Cart reservation is a policy choice, not a platform default, and many storefronts hold no inventory until order confirmation, so the mental model silently introduces a guarantee that does not exist.
What to do instead
Check whether the scenario states a reservation policy. Absent one, assume no reservation until order placement, treat concurrent checkouts as an oversell risk, and look for the standard mitigations: real-time stock decrement at confirmation, safety buffer stock, or short reservation windows.
Quotes a delivery promise by adding carrier transit time to the order date while ignoring cut-off time, handling time, and non-shipping days.
The carrier's published transit days are the most concrete number in the scenario, so they dominate the calculation and the warehouse-side lead time gets dropped.
What to do instead
Build the promise in sequence: order placed → cut-off met? → pick/pack handling days (business days only) → carrier transit days → delivery. Then state the promise date explicitly and flag any weekend or holiday that pushes it.
Interprets a CSAT score of 4.2 on a 5-point scale as '4.2%', or converts it directly into an NPS figure.
Both are called 'customer satisfaction scores', but one is a mean on a bounded rating scale and the other is a promoter-minus-detractor difference ranging from −100 to +100; the shared label invites a straight comparison.
What to do instead
Convert CSAT to a percentage of respondents at or above the satisfaction threshold (e.g. 4–5 of 5) and keep NPS as % promoters − % detractors. Never average an NPS-style question the same way as a satisfaction rating; state which scale the scenario uses before computing.
Computes cart abandonment rate as abandoned carts divided by completed orders, producing figures well above 100%.
The visible data export lists completed orders and open carts separately, and it feels natural to compare the 'lost' group to the 'won' group rather than to all carts started.
What to do instead
Fix the denominator first: abandonment rate = abandoned carts / (completed orders + abandoned carts). Anything above 100% signals the wrong base. Confirm how a 'cart' is defined too - a single session versus a persistent multi-session basket changes the number materially.