Card-input fields appear in page markup
ShipReady found card-detail input signals in HTML served by the site instead of only a hosted payment-field mount point.
Why it matters
Collecting card details in merchant-controlled markup expands the security and compliance responsibilities that must be considered for the checkout flow.
How ShipReady detects it
What it inspects
ShipReady examines server-delivered HTML outside inert templates for supported card-number, expiry, CVC, and related input signals. When scripts are fully read, it also notes whether supported hosted-field SDK hosts were observed.
What triggers a finding
The rule triggers when the page HTML contains supported card-field signals.
What the evidence shows
The scanner observed card-detail input markup in the page HTML it received. If the report says no hosted SDK was observed, that statement is limited to the successfully read page and script content.
Limits of this check
ShipReady does not type card data, inspect the rendered DOM after client-side changes, trace tokenization, inspect every third-party script, or determine PCI scope. It cannot prove that a field stores, transmits, or exposes card data.
How to fix it
Use provider-hosted payment fields where appropriate
Prefer a provider checkout, hosted fields, or tokenization design that keeps raw card entry outside merchant-controlled page markup.
Review the payment-data design
If collecting card data directly is intentional, obtain the appropriate security and compliance review for the actual architecture.
How to verify the change
Review the deployed checkout implementation
Confirm which component receives card data and whether the page embeds only provider-supported mount points or hosted frames.
Expected: The payment design matches the intended provider and compliance model.