Exercise 1: The Custom Checkout Form Proposal — Possible Solution
====================================================================

WHAT THIS PROPOSAL ACTUALLY BUILDS
------------------------------
Per this chapter, plain HTML fields for card number and CVV, posted
directly to the store's own PHP backend, means raw cardholder data
now genuinely passes through and is processed by the store's own
server - exactly the scenario this chapter names as the mistake it
exists to head off.

THE REAL, CONCRETE CONSEQUENCE
------------------------------
Per this chapter, a store built this way no longer qualifies for a
light PCI-DSS compliance tier at all. Instead of the SAQ A (or closely
related) tier a hosted/tokenized approach like Stripe Elements
qualifies for, this store falls under a far more demanding
assessment, such as SAQ D, which carries real infrastructure-level
security requirements this chapter notes "most WordPress hosting was
never designed to satisfy."

WHY "MORE ON-BRAND" DOESN'T OFFSET THIS
------------------------------
Per this chapter, this isn't a purely theoretical or cosmetic
trade-off - it's described as "the single most common way a
well-meaning custom checkout accidentally creates a serious
compliance liability." The visual/branding benefit the junior
developer is describing does not change the underlying fact that raw
cardholder data would now be flowing through and stored/processed by
systems the store itself controls.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies that the proposal moves raw card data through
the store's own server, correctly names the resulting shift to a much
heavier SAQ tier, and correctly explains why the desired branding
benefit doesn't change that underlying compliance consequence.