The company-controlled checkout route and production DNS are live.
W/ FOUNDERS · LAUNCH FRIDAY · WACK-FOUNDERS-0001
YOUR FIRST TRANSACTION
IS AN ARCHITECTURE EVENT.
Leave with a reversible payment-boundary decision and a first-transaction operating runway—not a badge, a launch blessing, or a shortcut to a validation answer.
$0 REVENUE DOES NOT MEAN ZERO PAYMENT ARCHITECTURE.
Safety and authority boundary
W/ Founders is independent practitioner education using a fictional company and fictional facts. It is not PCI SSC guidance, not an assessment, not a compliance result, not an SAQ-selection or eligibility decision, not legal or investment advice, not launch approval, not provider certification or endorsement, and not direction from a compliance-accepting entity. It does not authorize testing. Never enter account data, credentials, provider secrets, client evidence, restricted architecture, customer information, investor information, or identifying startup facts.
Fictional pressure case
Launch Friday at Signal Cart
CAN WE LAUNCH?
Signal Cart is a fictional pre-revenue software company preparing to accept its first subscription payment. The application uses provider-hosted payment fields inside a company-controlled checkout page. A public callback updates subscription state. Two founders have production access. No customer transaction has completed, but the payment path is deployed and can be enabled with one configuration change.
At 09:00 Friday, the board asks whether the team can launch at 17:00. The evidence packet contains a provider badge, a pitch deck diagram, a staging test, and an incomplete responsibility spreadsheet.Provider-hosted fields are embedded in the checkout page; the provider receives entered payment data directly.
The checkout page, script policy, deployment pipeline, and production configuration remain company-controlled.
A public callback hostname terminates at a company-managed gateway and invokes company application code.
Two founders hold production administrator roles; one role can change checkout configuration and callback secrets.
A feature flag can expose checkout to customers without a new deployment.
Live provider credentials and callback configuration are present in the production environment.
Only staging transaction behavior has been exercised end to end.
The provider assurance packet names a hosted-field service, but the customer responsibility row is incomplete for script and callback operation.
The founders assert that PCI DSS begins after the first successful customer payment.
The current external scan and penetration-test populations do not identify the callback termination.
Support wants a session-replay script added to the checkout shell before launch to diagnose abandonment.
Two-path architecture
Where data moves is only half the story.
The second path asks what can change, deploy, administer, expose, or prove the security of that movement.
Customer
Product engineering
Provider + relationship owner
Payments engineering
Product engineering
Platform owner
Engineering
Security + operations
Capability-state runway
Deployed is a fact. Enabled is a fact. Effective is another fact.
Do not let one launch date flatten four different states into one confident sentence.
What exact event makes the route available to a customer?
Which deployed configuration and service mode define the current provider relationship?
Which hostname, gateway, code revision, secret, and test population describe it?
What can each role change, invoke, approve, export, or cause another system to do?
Which expected events and failures are observable before the first customer arrives?
Who can act, with what access and retained evidence, during a payment failure?
Which required operating histories cannot exist until time and occurrences accumulate?
What can the script observe or influence, and which prior boundary claims must reopen?
16:31
Late change injection
The Thursday Replay Request
Support asks engineering to add a third-party session-replay script to the company-controlled checkout shell before launch so founders can diagnose abandonment.
Which exact boundary statement can remain true after this script is enabled, and what evidence supports it?
- checkout script inventory
- account-data and security-influence map
- provider integration constraints
- content and script policy
- software and provider inventory
- testing population
- change evidence
- launch decision
45-minute founder room
No lecture. Six timed decisions.
A bounded launch decision record, capability-state ledger, two-path boundary map, provider responsibility brief, first-transaction evidence runway, and explicit reopening triggers.
- 5MIN01 · PHASE-01
Name the decision
Write the exact decision requested, the deadline, who can make it, and what the room cannot conclude.
- 7MIN02 · PHASE-02
Separate capability states
Classify each payment-relevant capability as proposed, present, production-capable, or effective. Preserve disagreements.
- 8MIN03 · PHASE-03
Trace two paths
Map where payment data moves and what identities, code, public endpoints, providers, and deployment systems can influence its security.
- 8MIN04 · PHASE-04
Assign retained work
Separate provider performance from customer configuration, operation, evidence, testing, change, incident, and reporting responsibilities.
- 7MIN05 · PHASE-05
Build the evidence runway
Name what must exist before launch, at first transaction, after each occurrence, and only after an operating period.
- 10MIN06 · PHASE-06
Inject change and decide
Introduce the session-replay request, reopen affected facts and claims, then record one bounded decision with conditions, owners, limitations, and triggers.
DEVICE-LOCAL PILOT CONTROL
Run the room. Capture the fracture.
Evaluate the material—not the founder. Do not enter a real company, provider, customer, architecture, credential, or assessment. Nothing is submitted or stored by the site.
Six phases. One decision record.
Check a phase only after the group attempts it. Completion is not success; the retained observation explains what actually happened.
Where did the method need its author?
Bounded decision states
The room does not issue “compliant.”
Proceed with bounded conditions
The accountable business owner can proceed only with named conditions, owners, timing, and reopening triggers; this is not a compliance result.
Hold for facts
A material factual uncertainty prevents a responsible business decision until it is resolved.
Change the boundary
The current architecture creates obligations or uncertainty the team elects to redesign before launch.
Escalate validation direction
The team needs direction from its compliance-accepting entity and qualified professional; the room cannot supply it.
Portable field kit
Run Launch Friday without the website.
Every file uses the same fictional facts and authority boundary. The canonical JSON is included for inspectability—not as an automated decision engine.
Reviewed route
Five deeper reads behind the room.
Expansion gate
Pilot evidence first. Program expansion second.
Scott Norton records an exact-digest practitioner disposition, then one real founder, incubator, or accelerator partner runs the fictional 45-minute room. Preserve the first fracture, smallest repair, and second-reader retest before commissioning slides, a campaign, credentials, or a broader startup program.