ICT Applications – Electronic Funds Transfer at Point of Sale (EFTPOS)
1. Where EFTPOS Fits in the IGCSE 0417 ICT Syllabus
EFTPOS is a real‑world example that brings together many of the syllabus strands – hardware, software, data handling, safety, communication and the impact of IT. The sections below show how each part of the syllabus is addressed.
| Syllabus Strand | Notes Covered |
|---|
| 1‑5 Computer hardware, software, operating systems, emerging technologies | Section 2 |
| 6‑9 Effects of IT, ICT applications, systems life‑cycle, safety & security | Sections 3‑5, 8‑9 |
| 10‑16 Document production (file formats, images, layout, styles, proofing) | Section 6 |
| 17‑19 Databases and presentations | Sections 7‑8 |
| 20‑21 Spreadsheets and website authoring | Sections 9‑10 |
| 22‑23 Safety, e‑safety, data protection, copyright | Section 11 |
| 24‑25 Communication and internet use | Section 12 |
| 26‑27 File management and image handling | Section 13 |
2. Computer Hardware, Software & Emerging Tech (Syllabus 1‑5)
- Hardware basics – CPU (processor), RAM (volatile memory), ROM/flash (non‑volatile), storage (HDD/SSD), input devices (card reader, keypad), output devices (display, receipt printer).
- Software layers
- System software – operating system (e.g., Windows, Android) that manages hardware resources.
- Application software – POS application that records sales and communicates with banks.
- Utility software – anti‑malware, backup tools used on the terminal.
- Emerging technologies – AI‑driven fraud detection, Augmented Reality (AR) for product visualisation, Internet of Things (IoT) sensors in smart‑checkout lanes.
3. Effects of IT on Individuals, Society & the Environment (Syllabus 6‑9)
| Area | Positive Effects | Negative / Considerations |
|---|
| Health & Well‑being | Reduced need to carry cash, quicker transactions. | Increased screen time, reliance on electronic devices. |
| Social | Convenient shopping, better access for people with disabilities. | Digital divide – those without cards or smartphones are excluded. |
| Economic | Lower cash‑handling costs, detailed sales data for businesses. | Merchant fees, potential job loss in cash‑handling roles. |
| Environmental | Less paper money & receipts (e‑receipts). | E‑waste from obsolete terminals if not recycled. |
4. Systems Life‑Cycle (Syllabus 6‑9)
- Analysis – Identify user requirements (e.g., speed, security, contactless).
- Design – Choose hardware (EMV chip reader, NFC antenna) and software architecture (client‑server POS).
- Development & Testing – Programme transaction logic, simulate ISO 8583 messages, perform security testing.
- Implementation – Install terminals, train staff, migrate data.
- Evaluation & Maintenance – Monitor transaction success rate, apply patches, review fraud reports.
5. EFTPOS – Detailed Transaction Process
5.1 Components of an EFTPOS System
- Card – magnetic stripe, EMV chip, contactless (NFC) or tokenised mobile‑wallet.
- Terminal – reads card, captures PIN, encrypts data, connects to retailer’s POS.
- POS computer – creates transaction messages, prints receipts, stores sales data.
- Acquiring bank – retailer’s bank; forwards request to payment network.
- Payment network – VisaNet, Mastercard Network, etc., carries ISO 8583 messages.
- Issuing bank – card‑holder’s bank; authorises or declines.
5.2 Validity Checks Before Authorisation
- Physical inspection – card present, undamaged, not expired.
- Luhn algorithm – verifies the Primary Account Number (PAN) checksum.
- Expiry‑date comparison with terminal’s internal clock.
- Card status flag – blocked, stolen, over‑limit (checked during authorisation).
5.3 Chip‑and‑PIN (EMV) Flow
- Customer inserts card; terminal reads chip.
- Terminal generates a dynamic cryptogram (unique per transaction).
- Customer enters PIN on a secure keypad.
- PIN is encrypted with the card‑scheme’s public key.
- All data (cryptogram, encrypted PIN, amount, timestamp) are sent to the acquiring bank.
- Acquirer routes the request through the payment network to the issuing bank.
- Issuing bank validates cryptogram, decrypts PIN, checks balance, then returns APPROVED or DECLINED.
- Terminal displays the result and prints (or shows) a receipt.
5.4 Contactless (Tap‑and‑Go) Cards
- Uses same EMV chip but omits the PIN for low‑value purchases (e.g., ≤ \$50 – \$100).
- Customer taps card on the 13.56 MHz antenna.
- Terminal creates a dynamic cryptogram and sends an authorisation request as above.
- After a cumulative limit is reached, the terminal forces a PIN entry.
5.5 NFC Mobile‑Wallet Payments
- Device stores a tokenised version of the PAN; the real card number never leaves the device.
- When the user taps, the device generates a one‑time Dynamic Security Code (DSC).
- Terminal receives token + DSC, forwards to acquiring bank.
- Issuing bank maps token to the actual account, validates DSC, and returns authorisation.
5.6 Message Exchange – ISO 8583 (Syllabus 6‑9)
All communications use the ISO 8583 standard. The most relevant fields for IGCSE are shown below.
| Field | Name | Typical Content (example) |
|---|
| 0 | Message Type Indicator (MTI) | 0100 – Authorisation request |
| 2 | Primary Account Number (PAN) | 1234 5678 9012 3456 |
| 3 | Processing Code | 000000 – Purchase |
| 4 | Transaction Amount | 000000001000 – $10.00 |
| 7 | Transmission Date & Time | 1122101530 – 22 Nov 10:15:30 |
| 11 | System Trace Audit Number | 123456 – Unique per transaction |
| 14 | Expiration Date | 2509 – Sep 2025 |
| 48 | Additional Data – Chip Cryptogram | Encrypted data string |
| 52 | PIN Data | Encrypted PIN block (if PIN entered) |
| 70 | Network Management Information Code | 001 – Request for authorisation |
5.7 Security Measures (Syllabus 6‑9)
- End‑to‑end encryption (E2EE) of all sensitive fields.
- Transport security – TLS/SSL between POS gateway and acquiring bank.
- Tokenisation for NFC & mobile‑wallet transactions.
- Compliance with PCI‑DSS (Payment Card Industry Data Security Standard).
- Dynamic cryptograms prevent replay attacks.
5.8 e‑Safety & Fraud Prevention (Syllabus 22‑23)
- Card skimming – illegal devices capture magnetic‑stripe data. Counter‑measure: EMV chips, regular terminal inspections.
- Phishing & social engineering – attackers seek PINs or card details. Counter‑measure: educate users, never share PIN, use secure POS software.
- Malware on POS systems – can exfiltrate transaction data. Counter‑measure: keep OS and applications patched, use anti‑malware, restrict physical access.
- Data protection – store PAN, expiry, token only in encrypted form; retain for the minimum period required (GDPR/PDPA principles).
6. Document Production Fundamentals (Syllabus 10‑16)
- File formats – .doc/.docx (Word), .pdf (portable), .odt (OpenDocument).
- Compression – ZIP, RAR; useful for sending large transaction logs.
- Images – raster (PNG, JPEG) vs. vector (SVG); colour depth (24‑bit vs. 8‑bit) affects file size.
- Layout & Styles – use headings, bullet lists, tables; apply consistent style sheets for professional reports.
- Proofing – spell‑check, grammar check, peer review before submission.
7. Database Basics (Syllabus 17‑19)
POS systems rely on relational databases to store sales, inventory and customer data.
- Tables – e.g.,
Transactions, Products, Customers. - Primary key – unique identifier (e.g., TransactionID).
- Foreign key – links tables (e.g., ProductID in Transactions).
- Forms – data entry screens for cashiers.
- Queries – SELECT statements to retrieve daily sales totals.
- Reports – automatically generated end‑of‑day settlement reports.
8. Presentation Design (Syllabus 17‑19)
When presenting EFTPOS data (e.g., sales trends) to managers, follow this checklist:
- Use a master slide with consistent fonts and colours.
- Limit text – aim for 6‑8 words per line, 6‑8 lines per slide.
- Include clear charts (bar, line) with labelled axes.
- Apply animations sparingly – only to reveal key points.
- Check accessibility – high contrast, alt‑text for images.
9. Spreadsheets for Modelling (Syllabus 20‑21)
- Formulas & Functions – SUM, IF, VLOOKUP to calculate totals and flag declined transactions.
- Charts – column chart of sales per hour, pie chart of payment‑method share.
- Conditional formatting – highlight transactions > $500 in red.
- Data validation – restrict entry to valid card‑type codes.
10. Web Authoring (Syllabus 20‑21)
Many retailers also offer an online checkout that mirrors EFTPOS logic.
- HTML5 –
<form>, <input type="tel"> for card number, <input type="password"> for PIN. - CSS3 selectors – style the payment form, make it responsive (media queries).
- JavaScript – client‑side validation (Luhn check) before sending data to the server.
- HTTPS – mandatory for encrypting data in transit.
11. Safety, e‑Safety, Data Protection & Copyright (Syllabus 22‑23)
| Aspect | Key Points |
|---|
| Physical safety | Secure mounting of terminals, avoid exposed wiring, use UPS for power failures. |
| e‑Safety | Strong passwords, regular software updates, anti‑malware, network firewalls. |
| Data protection | GDPR/PDPA: obtain consent, store data encrypted, allow data‑subject access requests. |
| Copyright | Only use licensed images in receipts or promotional material; give credit where required. |
12. Communication & Internet Use (Syllabus 24‑25)
- Netiquette – polite language, avoid ALL CAPS, respect privacy.
- Email basics – use CC/BCC appropriately, keep attachments under 10 MB, scan for phishing links.
- Internet research – use Boolean operators, evaluate source credibility (author, date, domain).
- URL structure – https://domain.com/path – understand secure (HTTPS) vs. non‑secure (HTTP).
13. File Management & Image Handling (Syllabus 26‑27)
- Folder hierarchy – e.g.,
POS/2025/03_March/ for daily logs. - Naming conventions –
YYYYMMDDStoreIDTransactionLog.csv. - Version control – keep a “v1”, “v2” suffix or use a cloud service with history.
- Image editing – crop, resize to ≤ 500 KB for e‑receipts; use PNG for logos (lossless) and JPEG for photographs (lossy).
14. Evaluation of EFTPOS vs. Other Payment Methods
| Criterion | EFTPOS (Chip & PIN) | Contactless Card | NFC Mobile Wallet | Cash / Cheque |
|---|
| Security | High – dynamic cryptogram + PIN | Medium – cryptogram, no PIN for low value | High – tokenisation + one‑time DSC | Low – physical theft, forgery |
| Speed | Moderate (PIN entry) | Fast (tap) | Fast (tap + biometric unlock) | Variable (counting change) |
| Cost to merchant | Transaction fee (~1‑2 %) | Same as chip | Same as chip, plus possible mobile‑wallet fees | No electronic fee, but cash‑handling cost |
| Customer convenience | Widely accepted | Very convenient for small purchases | Convenient for phone‑only users | Requires exact change, slower |
| Privacy | Electronic record, but protected by encryption | Same as chip | Detailed spending profile stored by wallet provider | No electronic trail |
15. Key Points to Remember
- Validity checks (physical, Luhn, expiry) prevent obvious errors before contacting the bank.
- Chip‑and‑PIN provides the strongest in‑store security; contactless adds speed for low‑value sales.
- Mobile‑wallet NFC payments hide the real PAN through tokenisation.
- All communication follows ISO 8583 and must meet PCI‑DSS requirements.
- e‑Safety measures (encryption, anti‑skimming, regular updates) protect both customers and retailers.
- When evaluating any ICT application, consider convenience, cost, security, privacy and wider societal impact.
16. Further Reading (Optional)
- Full ISO 8583 field list and message‑flow diagrams.
- EMV cryptographic algorithms – ARQC (Authorization Request Cryptogram), ARPC (Authorization Response Cryptogram).
- PCI‑DSS compliance checklist for merchants.
- Case studies of POS fraud and how tokenisation reduced losses.
- Guides on GDPR/PDPA data‑subject rights for payment data.