Card Payment Security
Our plan for protecting payment card data (PCI DSS v4.0). Effective [effective date]
Draft for review. This is a working plan prepared for the demo. It is not legal or compliance advice. Confirm it with your payment processor and a Qualified Security Assessor (QSA) where required before card payments go live.
1. The short version
- Card numbers never touch our servers. Cards are entered only into the payment processor's own card terminal or secure payment form. We receive a token and the last four digits, never the full number, expiry-and-number together, or security code.
- This keeps JEZT Digital Console and your store's computers out of most of the PCI scope. You'll usually complete the shortest self-assessment your processor offers.
- Payment features are off until a supported processor is connected. Today, no card payments are processed in this system.
2. How payments will be designed
| Where | How cards are handled | Typical PCI self-assessment |
|---|---|---|
| At the counter | Processor-supplied, PCI-validated card reader (point-to-point encryption, P2PE). The reader talks to the processor directly; the CRM only sends the amount and receives the result. | SAQ P2PE (or the processor's equivalent) |
| Online store and customer payments | Processor-hosted payment page or embedded fields served from the processor's domain. Card data goes browser → processor. | SAQ A |
| Saved cards / autopay | Stored by the processor ("vaulted"). We keep only the processor's token, brand and last four digits. | Covered by the processor |
| Phone orders | Staff type the card into the processor's virtual terminal or reader, never into CRM notes. | Per processor guidance |
We plan to support more than one processor (for example Stripe and Square) so stores can choose, and so products such as ammunition that some processors restrict can still be sold with a compatible processor.
3. Who does what
| JEZT Digital (software provider) | Your business (merchant) | Payment processor |
|---|---|---|
| Integrate only with PCI-validated processors using tokens; never log or store card data; keep the software patched; enforce HTTPS, unique logins, two-step verification and audit logs; provide this plan and help with your self-assessment. | Use only processor-supplied readers; inspect readers for tampering; train staff never to write card numbers down or into notes; keep counter computers updated with antivirus; complete your annual self-assessment and any network scans your processor requires. | Process and store card data in its PCI Level 1 environment; provide validated readers and hosted fields; handle chargebacks and fraud screening. |
4. Controls in the software
- Encrypted connections (TLS/HTTPS) everywhere, with strict security headers.
- Unique user accounts, role-based permissions, two-step verification, automatic sign-out and step-up confirmation for sensitive changes.
- Append-only audit log of sign-ins, payment actions and settings changes.
- Processor credentials stored encrypted and never shown in full after saving.
- Planned: automatic detection and blocking of card-number patterns typed into free-text fields.
- Security updates applied promptly; dependencies reviewed; an annual independent security test before card processing is offered broadly.
5. Card readers at the counter
- Keep an inventory of readers (model, serial number, location).
- Check each reader regularly for tampering: seals, loose parts, extra devices, unexpected wires.
- Don't let anyone service a reader without verifying they are from the processor.
6. If something goes wrong
- Contain: stop using the affected reader, computer or account; don't turn off or wipe devices (evidence).
- Report: call your payment processor immediately, and notify us at [security contact email]. We will help within one business day.
- Investigate: we review audit logs and system records and cooperate with the processor and any forensic investigator.
- Notify: affected parties are notified as required by card-brand rules and state breach-notification laws.
- Improve: we document the cause and fix it.
7. Surcharges and bank payments
Card surcharging and cash-discount programs are regulated by card-brand rules and by some states; the software will only apply them where your processor and state allow, with required disclosures. ACH (bank) payments follow Nacha rules through the processor; bank account numbers are tokenized by the processor, like cards.
8. Review
This plan is reviewed at least yearly, and whenever a new payment method or processor is added.