Member Avatar for quibbie

I am looking for an autofill script to use with with a point of sale system. We would like to hook a credit card reader to our computers and when we swipe the credit card it will autofill the customers information the fields so it does not have to be done by hand on every sale.

Any ideas or existing scripts would be a great help.

Thanks everyone.

Chuck

  • 2 Contributors
  • 3 Replies
  • 120 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by Airshow

Dani AI

Generated

As suggested, extending one existing system is almost always simpler than building a new middleman. For 's goal of autofilling customer fields from a swipe, there are three practical approaches to evaluate: a keyboard‑emulating (wedge) reader + in‑page JS parsing, a small local middleware service that talks to the reader and the web app, or using a payments vendor SDK (tokenized readers) that already exposes customer info without handling raw track data.

Keyboard‑wedge readers are the easiest to try: they act like a keyboard and send the raw track string into whichever field has focus. Typical workflow is to put a hidden input always focused, detect the fast stream (swipes are far faster than manual typing), extract the Track 1 string (starts with % and ends with ?), split on ^ to get the name, then populate your form fields. Example sketch (proof of concept only; do not store raw track data):

// simple swipe detector (proof of concept)
let buf = '';
let last = Date.now();

document.addEventListener('keydown', e => {
  const now = Date.now();
  if (now - last > 200) buf = '';      // reset on pause between keys
  last = now;

  if (e.key.length === 1) buf += e.key;
  if (buf.includes('%') && buf.includes('?')) {
    const track = buf.slice(buf.indexOf('%'), buf.indexOf('?') + 1);
    const parts = track.split('^');         // Track 1 is %B<PAN>^NAME^...
    const pan = parts[0].replace(/^%B/, '');
    const name = (parts[1] || '').trim();  // "LAST/FIRST"
    // populate form fields here — do NOT log or persist track strings
    buf = '';
  }
});

For more robust deployments use a local middleware or a vendor SDK. WebHID/WebUSB let browsers talk to devices (see WebHID and WebUSB docs) but have limited cross‑browser/device coverage and require explicit user consent. A small native service (reads the device, tokenizes via your processor or exposes safe JSON to the browser over localhost) is the most reliable cross‑platform route. If payment processing is involved, prefer the payment provider’s terminal SDKs (for example, Stripe Terminal) so card data is tokenized and PCI scope is minimized.

Important cautions: magnetic tracks often do not include full address/email, so some fields may still need manual entry. Never store full track data or PANs unless fully PCI compliant. Read the PCI Security Standards guidance before design decisions (see the PCI SSC site) and test a real swipe into a text editor first to see exactly what your reader sends (Track 1 vs Track 2 formats differ). Relevant references: WebHID/WebUSB (MDN), magnetic stripe formats (magnetic stripe card), and Stripe Terminal docs.

Recommended Answers

All 3 Replies

Member Avatar for Airshow

I would try sticking "Credit Card Processing Software Reviews" or similar into Google.

Airshow

Member Avatar for quibbie

I would try sticking "Credit Card Processing Software Reviews" or similar into Google.

Airshow

I have a credit card processor, when I swip the card I want the script to fill the fields of the card owner. Otherwise the information in going to have be put into our sytem twice. Once for sale and once for the customer management software, I am trying to avoid this.

Member Avatar for Airshow

Quibbie,

In that case, you would appear already to have two systems/applications that can receive swipecard data.

I think your best bet would be to seek/write an extension to one or other system/application such that one receives the data and passes it to the other. That would involve one interface.

If you were to find/write a third system/ application to receive swipedata and pass it on to both existing systems/applications, then it would involve two interfaces.

In general two interfaces will be more difficult/expensive than one to develop/integrate. Therefore I think your first choice should be to extend one or other of your existing systems rather than look for a third element.

What ever approach you eventually adopt, the process will start with an internet search.

Airshow
(Many years experience as a Systems Engineer)

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.