01
Customer browser
experience
Product engineeringW/ BUILDERS · WACK-BUILDERS-0001 · PUBLIC PILOT
YOUR CODE WORKS.
CAN IT EXPLAIN ITSELF?
Start with a working payment feature. Finish with an architecture another engineer, security owner, and assessor can reconstruct without asking what the diagram forgot.
W/✓
Program authority statePractitioner reviewed / 2026-09-16
CHANGESET 8F2CMove callback to edge gateway
$
wack explain-change --payment-boundary- 01FLOWpublic termination changed
- 02INVENTORYhostname + gateway added
- 03IDENTITYnew execution role
- 04TESTexternal population reopened
- 05EVIDENCErelease proof required
- 06CLAIMprior boundary no longer current
W/→ONE COMMIT. SIX GOVERNED CONSEQUENCES.
Build safely. Claim carefully.
W/ Builders is independent practitioner education and a fictional pilot. It is not PCI SSC guidance, not official training, not a provider certification, not an eligibility decision, not a PCI DSS assessment, not a compliance result, and not permission to test a real system. It does not substitute for assessor judgment or compliance-accepting-entity direction. Use only fictional or explicitly sanitized environments. Never enter account data, credentials, provider secrets, client evidence, restricted architecture, or targets the participant is not authorized to test.
The W/ Builders method
Five moves from feature to defensible system.
The output of each move becomes an input to the next. If the records disagree, the build is not finished explaining itself.
- W/?01
Trace behavior
Narrate the normal payment, retry, failure, refund, support, administrative, and recovery paths before declaring what the integration does not touch.
A versioned payment and security-influence narrative - W/→02
Map relationships
Join code, services, identities, providers, public endpoints, data stores, deployment systems, and operators through explicit account-data and security-influence relationships.
A relationship graph with known, excluded, and unresolved edges - W/↔03
Assign control
Separate provider execution from customer configuration, monitoring, testing, evidence, change, incident, and assessment responsibilities for the exact services in use.
A service-and-activity responsibility record - W/!04
Derive proof
Derive inventories, test populations, evidence events, negative cases, and production-representativeness claims from the maintained architecture rather than from a late evidence request.
A test-and-evidence contract tied to the build - W/✓05
Govern change
Make each material change reopen the affected boundary, ownership, inventory, test, evidence, and assessment claims before deployment closes the ticket.
A change fan-out and bounded release decision
Fictional system / Relay Market Hosted Checkout
The payment feature is the visible part. The relationships are the system.
A fictional marketplace uses a provider-hosted payment page, a serverless session API, an Internet-facing webhook receiver, a containerized order service, cloud identity, CI/CD, centralized logging, and a support console. The exercise contains no real card data, credentials, provider tenant, or production target.
02
Storefront application
customer-code
Web engineering03
Checkout session function
serverless
Payments engineering04
Hosted payment provider
tpsp
Provider + customer relationship owner05
Public webhook receiver
public-interface
Payments engineering06
Order service
container
Commerce platform07
Cloud and workforce identity
control-plane
Identity + platform08
CI/CD and artifact registry
deployment
Platform engineering09
Logs, traces, and alerts
evidence-plane
SRE + security10
Support and refund console
administrative
Customer operationsDECLARED RELATIONSHIPS14 edges
browserLOADSstorefrontstorefrontREQUESTS SESSIONsessionbrowserSUBMITS PAYMENTproviderproviderCALLS PUBLIC ENDPOINTwebhookwebhookUPDATES ORDERordersidentityADMINISTERSsessionidentityADMINISTERSwebhookpipelineDEPLOYSstorefrontpipelineDEPLOYSsessionpipelineDEPLOYSwebhooksessionEMITStelemetrywebhookEMITStelemetrysupportINITIATES REFUNDprovidersupportREADS AND UPDATESorders
What the diagram cannot claim
- W/!A hosted payment page does not by itself decide the assessed entity's scope, validation instrument, or compliance result.
- W/!A component without known account data is not automatically unrelated to the security of the payment environment.
- W/!The provider's assurance does not certify the customer's implementation, configuration, retained responsibilities, or evidence.
- W/!The capstone does not authorize testing of a provider, production system, or any environment the learner does not own and have permission to test.
Six capstone checkpoints
A working endpoint is checkpoint zero.
01BUILD-CHECK-01
Behavior before boxes
Can another engineer reconstruct every payment and administrative path without reading the code?- Ship
- One-page data-flow narrative covering normal, alternate, failure, retry, refund, support, and administrative paths.
- W/!
- The explanation stops at the provider redirect or describes only the happy path.
02BUILD-CHECK-02
Two-path architecture
Does the model show both where payment data travels and what can affect the security of that journey?- Ship
- A relationship graph with typed nodes, account-data edges, security-influence edges, owners, and unresolved candidates.
- W/!
- The scope picture is a circle around hosts and omits identity, deployment, scripts, webhooks, support, or provider control surfaces.
03BUILD-CHECK-03
Provider claim boundary
Can the team explain exactly what the provider performs and exactly what the customer still owns?- Ship
- A service-and-activity responsibility record tied to current provider assurance, configuration, evidence, and change conditions.
- W/!
- The record says the provider handles PCI or treats an AOC as the customer's architecture conclusion.
04BUILD-CHECK-04
Durable ephemeral ownership
Can a short-lived function or container be reconstructed after the runtime object is gone?- Ship
- A revision lineage joining source, build, artifact digest, deployment, configuration, workload identity, runtime population, telemetry, and owner.
- W/!
- The inventory names only a service category or a current instance and cannot identify the tested revision.
05BUILD-CHECK-05
Tests from propositions
What exact security proposition is each scan, penetration test, negative test, and control observation meant to support?- Ship
- A coverage matrix joining proposition, subject, population, material variants, environment, method, authorization, evidence, exceptions, and retest.
- W/!
- The team starts with the final report or substitutes staging without proving production representativeness.
06BUILD-CHECK-06
Release with consequences
Which governed records must change when this commit changes a payment relationship?- Ship
- A release record that fans one change into affected flow, graph, inventories, ownership, public presence, test populations, evidence, claims, and reopening triggers.
- W/!
- The feature ticket closes while the assessment story continues to describe the prior architecture.
Four change drills
Make the architecture flinch before production does.
Each drill starts with a plausible engineering change and ends only when the affected operating records agree again.
BUILD-DRILL-01
The callback moved
The webhook receiver moves behind a new API gateway and public hostname.
- Hidden assumption
- The endpoint is just an implementation detail because the provider still sends the same event.
- Reopen
- data-flow narrative · public-point inventory · DNS and certificate ownership · external scan population · penetration-test propositions · software inventory · change evidence
BUILD-DRILL-02
The identity shortcut
A shared emergency role is added so support can repair failed payment events.
- Hidden assumption
- Read-only or emergency access cannot affect payment security.
- Reopen
- identity inventory · role purpose · authentication path · authorization test · logging and review · support narrative · reopening trigger
BUILD-DRILL-03
The invisible deployment
The session function changes runtime, dependency bundle, and deployment workflow without changing its public API.
- Hidden assumption
- No interface change means no PCI-relevant change.
- Reopen
- software inventory · artifact lineage · configuration baseline · vulnerability population · test-equivalence claim · telemetry expectations · release evidence
BUILD-DRILL-04
The assurance contradiction
The provider responsibility matrix conflicts with the contract and implemented product behavior.
- Hidden assumption
- The most favorable provider document wins because the provider is compliant.
- Reopen
- frozen assurance packet · contradiction record · affected customer claims · provider question · interim boundary · owner decision · reverification condition
Eight portable build records
Give the system an engineering memory.
Each Markdown record is editable, versionable, and deliberately separate from a compliance conclusion.
01BUILD-KIT-01
Payment Behavior Narrative
Describe the system as behavior before reducing it to boxes and arrows.
Download record02BUILD-KIT-02
Account Data and Security Influence Graph
Keep the data path and the influence path visible in the same architecture.
Download record03BUILD-KIT-03
Service and Activity Responsibility Record
Turn provider reliance into a testable, service-specific claim.
Download record04BUILD-KIT-04
Ephemeral Revision Lineage
Give short-lived compute a durable identity and evidence trail.
Download record05BUILD-KIT-05
Identity Plane Map
Separate workforce, cloud, workload, application, provider, and emergency identities.
Download record06BUILD-KIT-06
Public Interface and Webhook Register
Make every Internet-facing payment relationship discoverable and testable.
Download record07BUILD-KIT-07
Proposition to Test Matrix
Design testing from the maintained claim rather than from a vendor report template.
Download record08BUILD-KIT-08
Change Fan-Out Record
Prevent a successful deployment from leaving the compliance story behind.
Download recordTwelve reviewed field manuals
The capstone composes the library. It does not clone it.
These technical readings already carry digest-current named practitioner approvals. The new W/ Builders program remains separately reviewable.
01WACK-CONTENT-0140
Design the Payment Boundary Before Product Launch
The cheapest PCI scope reduction happens while the payment architecture is still erasable. After launch, every shortcut acquires customers, evidence obligations, rollback anxiety, and somebody prepared to call it indispensable.
02WACK-CONTENT-0120
What Is Your Data-Flow Narrative?
A data-flow diagram gives account data a route. A data-flow narrative gives every route a transaction, condition, data state, owner, and consequence. If the arrow cannot be spoken as a complete testable sentence, it may be decoration.
03WACK-CONTENT-0132
Hidden Points of Public Presence
Your homepage is not your public attack surface. It is merely the public endpoint everyone remembered to name.
04WACK-CONTENT-0133
Your Twilio Pay Webhook Is a Public Payment Boundary
You deferred card capture to Twilio, then forgot the application Twilio calls next.
05WACK-CONTENT-0108
Assess the Compute You Never See
A function can finish before the evidence request is written. A container can disappear before the assessor sees it. The assessment obligation does not disappear with the runtime.
06WACK-CONTENT-0109
What About That Entra ID?
The CDE may occupy one corner of the environment. Entra ID can still hold the keys to the doors, the badge printer, the emergency entrance, and several robots nobody invited to the access review.
07WACK-CONTENT-0099
Explain TPSP Deferral as a Testable Claim
‘We defer to the provider’ is not an assessment result. It is the opening sentence of a claim that still needs a service, activity, boundary, evidence set, customer duty, test, and owner.
08WACK-CONTENT-0128
The TPSP Assurance Packet Is Wrong. Now What?
A current AOC and a polished responsibility matrix can still be unusable for your exact claim. The dangerous move is not noticing the flaw. The dangerous move is noticing it—and continuing as if the packet said what everyone needed it to say.
09WACK-CONTENT-0117
Do You Understand Your Penetration Testing Methodology?
A penetration-test report proves that somebody tested something. Your methodology must explain why those targets, positions, layers, techniques, exclusions, dates, and retests were capable of testing the PCI claim you made.
10WACK-CONTENT-0121
Can I Test Development Instead of Production?
Development can prove that a control can work there. It cannot automatically prove that the production control did work here, against the required population, during the required period.
11WACK-CONTENT-0135
Your Cryptographic Inventory Is a Join, Not Another Spreadsheet
TCP 443 is a service fact. TLS enabled is a configuration claim. Cryptographic viability is a maintained decision. Stop letting one impersonate the others.
12WACK-CONTENT-0104
Build a Cross-Referenceable PCI Operating Model
Your inventory, diagrams, scans, penetration tests, critical tools, control records, and assessment evidence are not separate deliverables. They are different views of the same environment, and every material component must be traceable across them.
Ready-to-run engineering session
From Working Feature to Reviewable Payment Architecture
One fictional payment narrative, one two-path architecture, one provider responsibility record, one test proposition, and one change fan-out that another engineer can reconstruct.
- Fifteen minutes: read the fictional build and narrate normal, failure, refund, support, and administrative behavior.
- Fifteen minutes: map account-data and security-influence relationships without drawing a scope circle.
- Fifteen minutes: assign exact provider, customer, shared, assessor, and accepting-authority statements.
- Fifteen minutes: give ephemeral workloads, identities, public endpoints, and deployments durable record identities.
- Fifteen minutes: derive one test proposition, complete population, representative environment, evidence, and retest condition.
- Fifteen minutes: run one change drill and decide which records reopen before the release can close.