Shorten checkout without pretending every payment flow is the same.
Shape a four-step checkout, switch desktop and mobile, then compare what Checkout Sentinel can actually observe in the module-owned, native and unknown third-party paths. The lab creates no order and contacts no gateway.
- 0.7.1
- exact engineering candidate
- PS 8 + 9
- rendered on both live demos
- 320 px
- smallest tested checkout width
- 14 / 14
- required rendered scenarios passed
“One-page checkout” describes the layout, not the compatibility boundary.
Replace · module-owned
- Shopper experience
- Four progressive sections, merchant brand controls and module-owned field behavior.
- Sentinel coverage
- Owned browser and server stages where explicitly instrumented.
- Decision
- Best fit when the merchant is willing to own and stage-test the replacement flow.
Restyle · native checkout
- Shopper experience
- Keeps the native checkout lifecycle and applies the supported visual layer.
- Sentinel coverage
- Partial; only supported native hooks and observation points are visible.
- Decision
- Use when preserving native behavior matters more than full owned-stage evidence.
Unknown third-party OPC
- Shopper experience
- Owned by another module, theme override or gateway customization.
- Sentinel coverage
- Unknown until the exact stack and return paths are tested.
- Decision
- Do not rely on a universal firewall claim; request a compatibility review first.
Shape the checkout, then inspect the coverage truth.
Change the preview exactly like a merchant would. This deterministic lab saves nothing, submits no order and never contacts a gateway.
Contact
- 1. Contact
- 2. Delivery address
Complete the previous preview step to continue.
- 3. Shipping method
Complete the previous preview step to continue.
- 4. Payment
Complete the previous preview step to continue.
Owned coverage
Explicit Checkout Pro stages can be observed by browser and server evidence.
Observe-only · fail-open · no payment mutation
Open the incident evidence lab below ↓Investigate checkout risk without touching a payment.
Switch between deterministic evidence fixtures, inspect the funnel and walk an incident through human review. Every outcome follows Sentinel’s verified observe-only boundary.
Open, acknowledged or recovering
Last 24 hours · not unique customers
Authoritative order-created signals
Passive same-origin events only
Observed checkout progression
- 128Checkout enteredBrowser100% · of entered flows
- 122Address readyBrowser95% · of entered flows
- 117Delivery readyBrowser91% · of entered flows
- 114Payment options renderedBrowser89% · of entered flows
- 108Payment option selectedBrowser84% · of entered flows
- 104Payment submit intentBrowser81% · of entered flows
- 96Order createdServer75% · of entered flows
- 94Confirmation renderedBrowser73% · of entered flows
This lab sends no event, reads no checkout, estimates no lost revenue and does not diagnose a gateway. Scenario numbers are fictional; the coverage boundary and operator workflow mirror the Sentinel embedded in NP Checkout Pro 0.7.1.
What this experience proves
You can inspect the product’s actual decision surface before applying: bounded checkout stages, grouped incidents, confidence, sanitized component hints, safe next checks and a human-controlled state audit.
Follow the shopper surface, merchant workspace and local evidence path.
1. Reduce the shopper’s visible decision load
Contact, address, delivery and payment remain in one progressive surface, while the order summary and trust cues stay available.
Continue in the complete product room →
2. Configure checkout and coverage in one workspace
Readiness, checkout mode, appearance, conversion, fields and Sentinel share six accessible sections and preserve the active view after saves.
Continue in the complete product room →
3. Investigate local evidence without automatic blame
Coverage, funnel stages, incident state and retention stay distinct from cause attribution and payment decisions.
Continue in the complete product room →
Sentinel observes evidence. It does not decide whether money moves.
The 0.7.1 design is local, minimized, observe-only and fail-open. It excludes card data and gateway payloads, cannot approve, decline, block or repair a payment, and does not turn unknown third-party checkout behavior into owned coverage.
A pretty checkout is not ready until the exact store stack completes these tests.
- 01
Create both guest and logged-in orders with saved and new addresses.
- 02
Exercise taxes, countries, states, carriers, free shipping, vouchers and cart quantity changes.
- 03
Run every enabled payment module through success, cancel, failure and return paths.
- 04
Check the exact theme at desktop, 390 px and 320 px with sticky elements enabled.
- 05
Confirm validation errors preserve entered values, focus and readable field associations.
- 06
Disable Sentinel storage and confirm checkout still proceeds because monitoring is fail-open.
PrestaShop one-page checkout FAQ
Is Checkout Sentinel a separate plugin?
No. In 0.7.1 Sentinel is built into NP Checkout Pro and shares the same merchant workspace, lifecycle and release package. The old standalone draft is not a second public product.
Will it fully observe any third-party checkout?
No. Full stage coverage is limited to the module-owned replacement checkout. Native/restyle mode is partially observed. Unknown third-party one-page checkout, theme and gateway flows remain partial or unknown until explicitly tested.
Can Sentinel block or modify a payment?
No. It is observe-only and fail-open. It does not approve, decline, disable, repair or alter checkout, order or gateway behavior.
Does checkout evidence leave my PrestaShop server?
The released design stores minimized evidence locally and has no external telemetry endpoint. It excludes card data, gateway payloads and direct customer profile fields from the event schema.
Is version 0.7.1 already approved on PrestaShop Addons?
No. The engineering package passed internal static, runtime and browser gates, but the real Addons Product Key, official Validator, clean lifecycle rerun and final gateway matrix are still required.
Bring the exact theme and payment-module list—not a generic “works with PrestaShop” assumption.
NP Checkout Pro remains a gated pilot until the Addons Product Key, exact-package Validator pass, clean lifecycle rerun and named gateway matrix are complete. The compatibility review is the honest next step.