A payment form submits over an unencrypted http:// connection

Why it matters

A form on this page collects payment details and posts them to an http:// address — an explicit `http://` address, so the submission is sent unencrypted no matter how the visitor reached the page. Anyone between the customer and that server — on café Wi-Fi, on a compromised router, at an ISP — can read the details as they go past, and can alter them in flight. Handling cardholder data over an open network without strong cryptography is also a direct PCI DSS requirement (v4.0 requirement 4.2.1), so this is a compliance failure as well as a security one. Change the form's action to the https:// address of the same endpoint and confirm that endpoint actually serves https.

How ShipReady detects it

Payment configuration that stops money arriving. The failure this pillar exists for is mundane and catastrophic: a live site wired to a payment provider's TEST environment. Checkout appears to work, the form submits, a success page renders — and no money ever moves. It survives launch because the developer's own testing passes perfectly, and it is usually found when a founder wonders why a week of signups produced no revenue. Deliberately narrow. Every rule here keys off a marker that is definitionally a test credential — Razorpay's `rzp_test_` prefix, Paddle's sandbox environment call, Adyen's test Checkout host. None of them require interpretation, none of them can appear in a correctly configured production deployment, and none of them involve touching the payment provider or attempting a transaction. One marker is shared rather than definitional: `pk_test_` is issued by BOTH Stripe and Paystack. It still proves test mode, so it is still reported — but the provider is resolved from what the page actually loads rather than assumed from the prefix (see _publishable_key_provider). NOT checked, deliberately: whether a checkout page exists or is reachable. Payment routes have no convention — /checkout, /pricing, /billing, /upgrade, /subscribe are all common and most sites have none of them. Probing a list of guesses and reporting the 404s would produce noise on nearly every scan, which is the opposite of what this pillar is for.

Detection is deterministic. ShipReady reports this only when it observes the condition directly, and prefers to miss a real problem over inventing one. Rule version 1.4.0.

How to fix it

This is the prompt ShipReady puts in your report — written to be pasted straight into Cursor, Claude Code, or whichever assistant built the app.

A payment form on your site posts to an explicit http:// address, so card and billing details travel unencrypted and can be read or altered by anyone on the network path. Change the form's `action` to the https:// address of the same endpoint — and if the form is generated, fix the base URL or environment variable it is built from rather than the rendered page. Then confirm the endpoint really serves https (request it directly and check for a valid certificate, not just a redirect), because a form that posts to http and relies on a redirect has already sent the data in the clear before the redirect happens. Handling cardholder data over an open network without strong cryptography is also a direct PCI DSS v4.0 requirement 4.2.1 failure, so this needs fixing before you take a real payment. While you are there, serve the whole site over https and add an HSTS header so no page can be loaded insecurely in the first place.

Frequently asked questions

What does "A payment form submits over an unencrypted http:// connection" mean?

A form on this page collects payment details and posts them to an http:// address — an explicit `http://` address, so the submission is sent unencrypted no matter how the visitor reached the page.

How serious is it?

ShipReady rates this high. Fix before launch. A real weakness that an attacker can act on.

How do I fix it?

Paste the fix prompt on this page into Cursor, Claude Code or your AI editor. It is the same prompt ShipReady puts in your report.

Can I check my own site?

Yes — ShipReady scans up to ten pages of any public site for free and reports this alongside every other check. The free report lists every issue it finds and shows full evidence and a fix prompt for the critical and high-severity ones; medium and low findings are counted and unlock on Pro.

Related checks

• Card details are collected by your own page, not a hosted payment fieldhigh
• Payment test mode keyhigh
• Working discount codes are compiled into the browser bundlehigh
• A PayPal order is priced in the browsermedium
• Both live and test Stripe keys are shipped to the browsermedium
• Checkout price is submitted from a hidden form fieldmedium