Member Avatar for chrisw09

I'm working on a page that takes credit cards. Everything works great except when the user goes back to place another order, IE/Firefox/etc. saved the form data and is displaying the credit card used previously. Is there a way to prevent a browser from storing (caching) certain fields so this doesn't happen?

I thought about generating a random value and using that as the field name but then I end up having to deal with things like card declines and new field names. Was hoping there was a simpler way...

thanks!

  • 3 Contributors
  • 3 Replies
  • 129 Views
  • 4 Days Discussion Span
  • Latest Post Latest Post by MidiMagic

Dani AI

Generated

Browsers save and autofill form values locally; TLS/SSL only protects data in transit and does not stop a browser from offering saved cards. Modern HTML defines an autocomplete attribute and specific tokens for payment fields, but browsers may still ignore autocomplete="off" for fields they treat as autofillable. See the spec and guidance for the standardized tokens: WHATWG autofill tokens and the practical browser guidance at MDN autocomplete.

Recommended approaches (sorted by safety and reliability):

  • Offload card entry entirely to a payment-provider widget (hosted fields or tokenization). This keeps PANs off the site and avoids browser-autofill issues. Many gateways publish implementation guides; using one also simplifies PCI obligations (do not store CVV, etc.). See a provider example at .
  • Never repopulate card inputs after a decline. Show an error but require the user to re-enter PAN/CVV. Store only non-sensitive metadata (last4, expiry) if needed.
  • Use the standardized autocomplete tokens so browsers know the field purpose (e.g., cc-number, cc-exp, cc-csc). That helps browsers behave consistently.

If a blocking behavior is required (fragile and use with caution), a common client-side trick is to make the input readonly on load and remove readonly on focus so the browser won’t autofill it. This breaks some password managers and can harm accessibility, so test thoroughly.

Example of the safe autocomplete use:

<input name="cc-number" autocomplete="cc-number" inputmode="numeric" />
<input name="cc-exp" autocomplete="cc-exp" />
<input name="cc-csc" autocomplete="cc-csc" />

Also set response headers to reduce cached copies (e.g., Cache-Control: no-store) but expect that this won’t fully control browser autofill. As and observed, some behavior is client-controlled; the most robust fix is to avoid collecting raw card data on your domain. For PCI guidance see the Payment Card Industry site: pcisecuritystandards.org.

Recommended Answers

All 3 Replies

Member Avatar for sikka_varun

Hi..
Preferably try to make each and every of such pages secure by using ssl.. i.e. https... with this it will not save the form data... and everytime request a new data...

Member Avatar for chrisw09

That's the funny thing, the site is SSL yet when i start to type in the field, a dropdown from the browser appears with other things typed in. Doing it for both IE and Firefox. I found AutoComplete="off" but this invalidates the HTML... I would think that if the site is SSL, it wouldn't save things...

Member Avatar for MidiMagic

It's a setting in the browser, and belongs to the user, not to the web developer. The user must set these values.

AutoComplete= is a nonstandard IE extension. This is why it won't validate.

Can you write empty strings into these fields with your script, before allowing the user to enter values?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.