KHDSShip Doctor
Redacted evidence example
Back to product ↗

CASE 001 Real sample report

We examined
our own checkout.

This is a redacted demonstration run on KHDS Ship Doctor’s real payment and download path on 8 September 2026. It shows what the method can prove, what remains unverified and why the verdict is not automatically “safe”. No customer information or secrets are included.

Verdict⚠ SHIP WITH CONDITIONS
Score84 / 100 · B
ConfidenceMedium
Findings0 critical · 0 high · 2 medium · 2 low

System identity

What was examined

  • The public Ship Doctor product page and free prompt builder.
  • The server-created Stripe Checkout session.
  • The signed Stripe webhook and fulfilment path.
  • The payment-protected private ZIP download.
  • The customer and owner email notifications.

Verified evidence

What the examiner could prove

  • Price is controlled on the server.
    store.data.ts:117–125 defines the Ship Doctor service and £49 price; the browser supplies only the service slug.
  • Checkout uses Stripe’s hosted payment flow.
    store.service.ts:1225–1245 creates a one-payment Checkout session and requires Stripe to return a valid URL.
  • Webhook authenticity is enforced.
    store.service.ts:1502–1513 rejects events that fail Stripe signature verification.
  • Fulfilment requires a paid session.
    store.service.ts:960–975 ignores unpaid sessions and prevents duplicate delivery records.
  • The ZIP is not publicly served.
    store.service.ts:1076–1088 retrieves the session from Stripe again, checks both payment status and product identity, then reads the private asset.
  • Downloads avoid public caching.
    store.controller.ts:35–41 returns the ZIP with private, no-store.

Findings

What still stops an unconditional verdict

MEDIUM · The complete live customer journey is not yet verified.The checkout endpoint and access controls passed controlled tests, but no genuine customer payment has yet proved payment → webhook → email → download as one complete production path. Deduction: 10 points for an unverified critical path.
MEDIUM · Customer email recovery is operational rather than self-service.Email results are recorded, but a failed delivery currently requires owner attention. A buyer can still download from the success page, which contains the immediate impact. Deduction: 4 points.
LOW · The purchase URL is a reusable bearer link.Anyone given the private Stripe session link can download the product. This is stated to the customer and is common for downloadable products, but deliberate sharing cannot be technically prevented. Deduction: 1 point.
LOW · A downloaded ZIP cannot be revoked after a refund.Once a digital file is on a buyer’s computer it cannot be recalled. Refund and dispute handling therefore remains a commercial process. Deduction: 1 point.

Critical paths

Status

  • Free prompt: verified in browser code and available without upload.
  • Checkout creation: verified server-side.
  • Unpaid download rejection: verified.
  • Paid download: implemented; no real buyer run yet.
  • Email delivery: implemented and recorded; live customer receipt unverified.

Launch conditions

What must happen next

  1. Observe the first genuine payment from checkout through webhook processing.
  2. Confirm the buyer receives the email and can download the correct ZIP.
  3. If email fails, resend the private link and record the cause.
  4. Re-run VERIFY mode and replace unverified statuses with fresh evidence.
Want this examination for your project?

Create one starter prompt free, or install the reusable four-mode toolkit for £49.

Open Ship Doctor →