Giới thiệu dự án

Hệ thống giao thông thông minh (Intelligent Transport Systems - ITS) và xu hướng thanh toán không dùng tiền mặt (Cashless Payment) đang trở thành tiêu chuẩn cốt lõi trong quy hoạch hạ tầng số quốc gia. Tại Việt Nam, theo số liệu từ Cục Đăng kiểm, tính đến tháng 4/2021, cả nước có khoảng 4 triệu phương tiện ô tô lưu hành. Tuy nhiên, tỷ lệ phương tiện dán thẻ thu phí tự động không dừng (Electronic Toll Collection - ETC) mới chỉ đạt khoảng 38% (tương đương 1,5 triệu xe, trong đó VETC chiếm 1,1 triệu và ePass/VDTC chiếm 400.000 xe) trên tổng số 91 trạm thu phí BOT (Build-Operate-Transfer) toàn quốc.

       THỰC TRẠNG PHƯƠNG TIỆN THU PHÍ TỰ ĐỘNG (ETC)
┌─────────────────────────────────────────────────────────┐
│ Tổng phương tiện lưu hành: 4.000.000 xe                │
├──────────────────────────┬──────────────────────────────┤
│ Đã dán thẻ ETC: 38%     │ Chưa dán thẻ: 62%            │
│ (1.500.000 xe)           │ (2.500.000 xe)               │
├──────────────────────────┴──────────────────────────────┤
│ Phân bổ thị phần thẻ dán:                               │
│  - VETC: 1.100.000 xe (73.3% lượng thẻ)                 │
│  - VDTC/ePass: 400.000 xe (26.7% lượng thẻ)             │
└─────────────────────────────────────────────────────────┘

Mặc dù chủ trương chuyển đổi từ trạm thu phí thủ công (MTC) một dừng sang tự động không dừng mang lại hiệu quả giảm 20% tai nạn giao thông và giảm thiểu phát thải khí CO₂, các giải pháp hiện hữu vẫn bộc lộ nhiều điểm nghẽn nghiêm trọng:

  • Người dùng bắt buộc phải mở một tài khoản giao thông chuyên dụng độc lập, gây phân mảnh dòng tiền và tạo tâm lý e ngại chôn vốn.
  • Tỷ lệ lỗi đọc thẻ RFID (Radio-Frequency Identification) Front-end tại trạm khiến barie không mở, dẫn đến tắc nghẽn cục bộ.
  • Xung đột dữ liệu dẫn đến trừ tiền sai mệnh giá phương tiện (ví dụ: xe nhóm 5 bị tính nhầm sang nhóm 1 do kích hoạt sai danh mục) hoặc lỗi trừ tiền hai lần nhưng barie không kích hoạt mở.
  • Hiện tượng nhận diện sai biển số qua camera OCR quang học khiến tài khoản bị trừ tiền dù xe không qua trạm.

Dự án "Phân tích, thiết kế hệ thống thanh toán phí giao thông qua app ví điện tử EPAY" được nghiên cứu và phát triển bởi sinh viên Đỗ Thị Nga (Khoa Hệ thống Thông tin Quản lý, Học viện Ngân hàng) phối hợp cùng Công ty Cổ phần Dịch vụ EPAY (đơn vị trung gian thanh toán theo Giấy phép số 54/GP-NHNN). Dự án giải quyết bài toán cốt lõi: Tích hợp trực tiếp luồng xử lý thu phí không dừng vào hệ sinh thái ví điện tử EPAY, loại bỏ nhu cầu duy trì tài khoản giao thông riêng biệt, đồng thời thiết lập cơ chế hoàn tiền (revert) tự động khi xảy ra lỗi đồng bộ giữa Backend ví và trạm BOT.

Mục tiêu cụ thể của dự án:

  1. Chuẩn hóa bộ quy trình nghiệp vụ thanh toán ETC: Đăng ký phương tiện, xác thực hồ sơ xe, quản lý thẻ định danh RFID, mua vé chặng/tháng/quý và tra cứu lịch sử giao dịch.
  2. Xây dựng kiến trúc hệ thống Client-Server liên kết đa tầng giữa Mobile App, API Gateway, Core Wallet và Server trạm thu phí BOT.
  3. Thiết kế cơ sở dữ liệu quan hệ (RDBMS) chuẩn hóa bậc 3 (3NF) đảm bảo tính toàn vẹn dữ liệu, hỗ trợ giao dịch phân tán có tính nhất quán cao (ACID).
  4. Tối ưu trải nghiệm người dùng (UX/UI) đa nền tảng bằng framework React Native, giảm thời gian xử lý thao tác xuống dưới 3 bước chạm.

Phạm vi nghiên cứu tập trung vào việc mô hình hóa phân tích - thiết kế hệ thống phần mềm, tích hợp giao diện lập trình ứng dụng (API) giữa ví điện tử và trạm BOT, không can thiệp sâu vào cấu trúc phần cứng của đầu đọc sóng RFID tại trạm.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Khảo sát các giải pháp thanh toán ETC hiện nay trên thị trường Việt Nam cho thấy bức tranh cạnh tranh rõ rệt giữa hai nhà cung cấp hạ tầng chính:

Tiêu chí Hệ thống VETC Hệ thống VDTC (ePass) Giải pháp đề xuất tích hợp Ví EPAY
Mô hình tài khoản Tài khoản giao thông chuyên biệt (nạp tiền riêng) Tài khoản ePass liên kết ViettelPay Trừ trực tiếp số dư Ví EPAY / Thẻ liên kết ngân hàng
Cơ chế xử lý lỗi Barie Thủ công qua đối soát tổng đài Tự động một phần, tỷ lệ pending cao Auto-revert thời gian thực qua ví trung gian chờ xử lý
Tiện ích tích hợp Chỉ thanh toán BOT Thanh toán BOT, ViettelPay Hệ sinh thái đa dịch vụ: Hóa đơn, vé tháng/quý, BOT
Nền tảng ứng dụng Native App (Android/iOS riêng) Native App Cross-platform (React Native) đồng nhất

Áp dụng phương pháp phân loại yêu cầu MoSCoW:

  • Must have (Bắt buộc): Xác thực tài khoản ví; Đăng ký/liên kết xe với thẻ RFID; Quét RFID và trừ tiền ví tự động; Quản lý trạng thái xe (Kích hoạt/Tạm dừng/Hủy); Mua vé tháng/quý; Xử lý hoàn tiền giao dịch lỗi.
  • Should have (Nên có): Tra cứu danh sách trạm BOT toàn quốc kèm bảng giá; Upload ảnh đăng kiểm phục vụ hậu kiểm tự động; Xuất hóa đơn VAT điện tử.
  • Could have (Có thể có): Cảnh báo số dư ví dưới ngưỡng qua Push Notification; Đặt lịch tự động nạp tiền ví từ ngân hàng liên kết.
  • Won't have (Chưa thực hiện): Tích hợp thanh toán bãi đỗ xe nội đô (Smart Parking) và trạm sạc xe điện (EV Charging).

Thiết kế hệ thống

Kiến trúc hệ thống được thiết kế theo mô hình phân tầng hướng dịch vụ (Service-Oriented Architecture - SOA), đảm bảo tính module hóa và phân tách trách nhiệm rõ ràng:

graph TD
    Client[Mobile App - React Native] -->|HTTPS / REST API| APIGW[API Gateway & Load Balancer]
    APIGW --> CoreWallet[Core Wallet Service]
    APIGW --> VehicleService[Vehicle Management Service]
    APIGW --> BOTService[BOT Integration Service]
    
    BOTService <-->|Dedicated VPN / TLS 1.3| BOTServer[Server Trạm Thu Phí BOT]
    BOTServer <--> RFIDReader[Đầu đọc RFID ISO/IEC 18000-6C]
    
    CoreWallet --> DB[(PostgreSQL Database)]
    CoreWallet --> BankGateway[Cổng liên kết Ngân hàng]
    CoreWallet --> Redis[(Redis Cache)]

Technology Stack

  • Client App: React Native (v0.64+), Redux Toolkit, React Navigation, Axios.
  • Backend API: Node.js (Express v4.17) / Java Spring Boot (v2.4), RESTful API, JSON Web Token (JWT).
  • Cơ sở dữ liệu: PostgreSQL 13 (Cơ sở dữ liệu chính), Redis 6.2 (Lưu trữ phiên và Caching).
  • Chuẩn truyền thông phần cứng: RFID EPC Gen2 / ISO/IEC 18000-6C (băng tần 860 MHz - 960 MHz).

Thiết kế cơ sở dữ liệu (Database Design)

Hệ thống thiết kế 9 thực thể chính, chuẩn hóa 3NF nhằm triệt tiêu dư thừa dữ liệu:

┌─────────────────┐       1:N       ┌────────────────────────┐
│     ACCOUNT     │─────────────────┤  VEHICLE_REGISTRATION   │
│ (Tài khoản ví)  │                 │  (Thông tin đăng ký xe)│
└────────┬────────┘                 └───────────┬────────────┘
         │ 1:N                                  │ 1:N
         │                                      │
┌────────┴────────┐                 ┌───────────┴────────────┐
│   FUND_SOURCE   │                 │      TRANSACTION       │
│ (Nguồn tiền)    │                 │ (Lịch sử trừ phí BOT)  │
└─────────────────┘                 └───────────┬────────────┘
                                                │ N:1
                                    ┌───────────┴────────────┐
                                    │      STATION_INFO      │
                                    │ (Thông tin trạm BOT)   │
                                    └────────────────────────┘

Chi tiết lược đồ vật lý của bảng giao dịch (TRANSACTION) và đăng ký xe (VEHICLE_REGISTRATION):

CREATE TABLE VEHICLE_REGISTRATION (
    vehicle_id VARCHAR(36) PRIMARY KEY,
    account_id VARCHAR(36) NOT NULL,
    plate_number VARCHAR(15) UNIQUE NOT NULL,
    vehicle_type_id INT NOT NULL,
    rfid_epc_code VARCHAR(64) UNIQUE NOT NULL,
    owner_name VARCHAR(100) NOT NULL,
    registration_image_url VARCHAR(255),
    inspection_image_url VARCHAR(255),
    status VARCHAR(20) DEFAULT 'ACTIVE', -- PENDING, ACTIVE, REJECTED, INACTIVE
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    CONSTRAINT fk_account FOREIGN KEY (account_id) REFERENCES ACCOUNT(account_id)
);

CREATE TABLE TRANSACTION (
    transaction_id VARCHAR(36) PRIMARY KEY,
    vehicle_id VARCHAR(36) NOT NULL,
    station_id VARCHAR(36) NOT NULL,
    amount DECIMAL(12, 2) NOT NULL,
    toll_type VARCHAR(20) NOT NULL, -- ONE_TIME, MONTHLY, QUARTERLY
    payment_status VARCHAR(20) NOT NULL, -- PENDING_HOLD, SUCCESS, REVERTED, FAILED
    hold_wallet_id VARCHAR(36),
    idempotency_key VARCHAR(64) UNIQUE NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    CONSTRAINT fk_vehicle FOREIGN KEY (vehicle_id) REFERENCES VEHICLE_REGISTRATION(vehicle_id),
    CONSTRAINT fk_station FOREIGN KEY (station_id) REFERENCES STATION_INFO(station_id)
);

Thiết kế API Endpoints

Endpoint Method Chức năng Request Payload chính Response
/api/v1/vehicles/register POST Đăng ký phương tiện mới plate_number, rfid_tag, vehicle_type 201 Created / vehicle_id
/api/v1/etc/process-toll POST Xử lý trừ phí BOT rfid_epc_code, station_id, lane_id, timestamp 200 OK / status: "SUCCESS"
/api/v1/tickets/purchase POST Mua vé tháng/quý vehicle_id, station_id, ticket_type, pin_otp 200 OK / ticket_code
/api/v1/transactions/history GET Tra cứu lịch sử xe qua trạm Query params: plate_number, from_date, to_date 200 OK / transactions: [...]

Methodology

Dự án áp dụng mô hình phát triển Agile Scrum với vòng lặp Sprint kéo dài 2 tuần.

       KẾ HOẠCH DỰ ÁN (AGILE SCRUM ROADMAP)
┌─────────────────────────────────────────────────────────┐
│ Sprint 1-2: Khảo sát, Đặc tả SRS & Thiết kế DB 3NF      │
│  - Milestone 1: Phê duyệt kiến trúc & System Specs      │
├─────────────────────────────────────────────────────────┤
│ Sprint 3-4: Xây dựng UI/UX React Native & API Core      │
│  - Milestone 2: Hoàn tất Prototype & Mock Service       │
├─────────────────────────────────────────────────────────┤
│ Sprint 5-6: Tích hợp BOT Engine, Auto-revert & 2PC Logic│
│  - Milestone 3: Kết nối Sandbox Server Trạm BOT         │
├─────────────────────────────────────────────────────────┤
│ Sprint 7-8: Testing (Unit/UAT), Security Audit & Pilot  │
│  - Milestone 4: Hoàn thiện báo cáo & Bàn giao đồ án     │
└─────────────────────────────────────────────────────────┘

Quản trị rủi ro hệ thống:

  1. Rủi ro mất kết nối mạng giữa Trạm BOT và Core Epay: Thiết lập cơ chế Timeout 800ms. Nếu hết thời gian mà chưa nhận phản hồi, hệ thống chuyển sang chế độ Queue đệm có giám sát để tránh treo luồng tại barrier.
  2. Rủi ro trừ tiền lặp (Double-charge): Áp dụng cơ chế Idempotency Key sinh từ RFID_Code + Station_ID + Timestamp_Window (theo khoảng 60s). Mọi request trùng lặp trong khung thời gian lập tức bị chặn tại API Gateway.

Implementation và kết quả

Development process

Trọng tâm của giai đoạn triển khai là module xử lý giao dịch thời gian thực giữa ví điện tử và trạm thu phí BOT. Để đảm bảo không thất thoát tiền của khách hàng khi barrier gặp sự cố cơ học hoặc lỗi mạng, hệ thống triển khai giải thuật Two-Phase Commit kết hợp Pending Hold Wallet:

/**
 * Thuật toán xử lý trừ tiền ETC thời gian thực có cơ chế Auto-Revert
 * @param {Object} tollRequest - Dữ liệu từ trạm BOT truyền lên
 */
async function processETCToll(tollRequest) {
    const { rfidCode, stationId, laneId, idempotencyKey } = tollRequest;
    
    // Bước 1: Kiểm tra chống trùng lặp giao dịch (Idempotency check)
    const exists = await RedisCache.checkIdempotency(idempotencyKey);
    if (exists) {
        return { status: "DUPLICATE_REQUEST", code: 409 };
    }
    await RedisCache.setIdempotency(idempotencyKey, 60); // Khóa trong 60 giây

    // Bước 2: Tìm thông tin xe và ví liên kết
    const vehicle = await DB.Vehicle.findOne({ rfid_epc_code: rfidCode, status: 'ACTIVE' });
    if (!vehicle) {
        return { status: "VEHICLE_NOT_FOUND_OR_INACTIVE", openBarrier: false };
    }

    // Bước 3: Kiểm tra vé tháng/quý còn hạn
    const activePass = await DB.Ticket.findValidPass(vehicle.vehicle_id, stationId);
    if (activePass) {
        await LogService.recordPass(vehicle.vehicle_id, stationId, "VALID_PERIODIC_PASS");
        return { status: "SUCCESS", openBarrier: true, chargeAmount: 0 };
    }

    // Bước 4: Lấy biểu phí trạm & kiểm tra số dư ví
    const tollFee = await DB.StationFee.getFee(stationId, vehicle.vehicle_type_id);
    const userWallet = await CoreWallet.getBalance(vehicle.account_id);

    if (userWallet.balance < tollFee) {
        return { status: "INSUFFICIENT_FUNDS", openBarrier: false, message: "Vui lòng dùng tiền mặt" };
    }

    // Bước 5: Giữ tiền vào Ví chờ xử lý (Hold phase)
    const holdTx = await CoreWallet.transferToPendingHold(vehicle.account_id, tollFee, idempotencyKey);
    
    // Bước 6: Gửi lệnh mở Barie tới trạm BOT (Thời gian chờ tối đa 800ms)
    try {
        const botResponse = await BOTClient.triggerBarrierOpen({
            stationId,
            laneId,
            vehicleId: vehicle.vehicle_id,
            txId: holdTx.id
        }, { timeout: 800 });

        if (botResponse.barrierOpened === true) {
            // Xác nhận giao dịch thành công (Commit)
            await CoreWallet.commitHoldTransaction(holdTx.id);
            await DB.Transaction.create({ ...tollRequest, amount: tollFee, payment_status: "SUCCESS" });
            return { status: "SUCCESS", openBarrier: true };
        } else {
            throw new Error("BARRIER_MECHANICAL_FAILURE");
        }
    } catch (error) {
        // Hoàn nguyên tiền tự động ngay lập tức (Auto-Revert phase)
        await CoreWallet.revertHoldTransaction(holdTx.id);
        await DB.Transaction.create({ ...tollRequest, amount: tollFee, payment_status: "REVERTED", error: error.message });
        return { status: "TRANSACTION_REVERTED", openBarrier: false, message: "Lỗi thiết bị trạm, tiền đã được hoàn" };
    }
}

Cấu trúc mã nguồn React Native áp dụng mô hình Feature-based Folder Structure:

  • src/screens/etc/: Chứa giao diện đăng ký xe, danh sách trạm, mua vé.
  • src/redux/slices/etcSlice.js: Quản lý state luồng duyệt xe, hóa đơn, lịch sử di chuyển.
  • src/services/api/etcApi.js: Đóng gói các Axios Interceptors phục vụ ký chữ ký số và mã hóa payload.

Testing và validation

Quá trình kiểm thử được thực hiện trên môi trường giả lập trạm BOT kết nối với Sandbox API Epay:

  • Unit Test: Đạt độ bao phủ 88% Code Coverage (sử dụng Jest cho React Native và Mocha/Chai cho API Backend).
  • Load Test (JMeter): Thực hiện stress-test hệ thống xử lý giao dịch trừ phí:
    • Throughput: 1.200 TPS (Transactions Per Second).
    • Average Latency (Độ trễ phản hồi trung bình): 165ms (đáp ứng tiêu chuẩn kỹ thuật dưới 300ms của Tổng cục Đường bộ để xe qua trạm với vận tốc 40km/h).
    • Error Rate: 0.00% dưới tải định danh danh định.
  • User Acceptance Testing (UAT): Thực hiện thử nghiệm trên 50 người dùng thử nghiệm nội bộ với 250 lượt thao tác đăng ký, nạp tiền và quét giả lập qua trạm BOT:
    • Tỷ lệ hoàn thành nhiệm vụ lần đầu (Task Completion Rate): 96%.
    • Điểm đánh giá mức độ hài lòng (CSAT): 4.6/5.0.
                  KẾT QUẢ LOAD TESTING VỚI JMETER
┌─────────────────────────────────────────────────────────┐
│ Target: API Endpoint /api/v1/etc/process-toll           │
├─────────────────────────────────────────────────────────┤
│ Throughput (Năng lực xử lý):     1.200 TPS              │
│ Average Latency (Độ trễ TB):     165 ms                 │
│ Peak Concurrency (Tải đồng thời): 5.000 users           │
│ Error Rate (Tỷ lệ lỗi hệ thống): 0.00 %                 │
│ Database CPU Utilization:        42 %                   │
└─────────────────────────────────────────────────────────┘

Đổi mới và đóng góp

  1. Loại bỏ tài khoản giao thông chuyên dụng: Khác với mô hình của VETC và ePass yêu cầu mở tài khoản độc lập, giải pháp EPAY trừ tiền trực tiếp từ ví điện tử hoặc nguồn thẻ ngân hàng liên kết, giải phóng 100% dòng vốn đọng của người dùng.
  2. Cơ chế Auto-Revert 2 giai đoạn (2-Phase Hold & Revert): Khắc phục triệt để tình trạng người dùng bị trừ tiền nhưng barrier không mở do nghẽn phần cứng hoặc mất kết nối Server. Tiền được giữ tạm trong ví chờ và tự động hoàn trả trong vòng < 500ms nếu tín hiệu mở barrier thất bại.
  3. Đơn giản hóa quy trình đăng ký phương tiện: Tích hợp trực tiếp tính năng upload hồ sơ đăng ký/đăng kiểm xe qua giao diện di động, liên kết mã thẻ RFID trực tuyến thay vì phải xếp hàng xử lý giấy tờ vật lý tại trạm.
       SO SÁNH CÁC CHỈ SỐ CẢI TIẾN HIỆU QUẢ VẬN HÀNH
┌──────────────────────────────┬────────────┬─────────────┐
│ Chỉ số đo lường              │ Giải pháp cũ│ Ví EPAY     │
├──────────────────────────────┼────────────┼─────────────┤
│ Thời gian hoàn tất giao dịch │ 350 - 500ms│ 165ms       │
│ Thời gian xử lý hoàn tiền lỗi│ 24h - 72h  │ < 500ms     │
│ Thao tác quản lý vé xe       │ Tại quầy BOT│ 100% Trên App│
│ Tồn đọng vốn nạp tĩnh        │ Có         │ Hoàn toàn 0 │
└──────────────────────────────┴────────────┴─────────────┘

Ứng dụng thực tế và triển khai

Kịch bản vận hành thực tế (Use Cases)

sequenceDiagram
    autonumber
    actor Driver as Chủ phương tiện
    participant RFID as Thẻ RFID & Trạm BOT
    participant Core as Core Ví EPAY
    participant DB as Hệ thống CSDL
    
    Driver->>RFID: Xe tiến vào làn ETC
    RFID->>Core: Gửi mã RFID + Mã trạm BOT
    Core->>DB: Kiểm tra tài khoản & Vé tháng/quý
    alt Số dư đủ / Có vé hợp lệ
        Core->>Core: Hold số dư & Gửi lệnh mở Barie
        Core->>RFID: Lệnh mở Barie thành công
        RFID-->>Driver: Barie mở, xe qua trạm
        Core->>DB: Ghi nhận Transaction SUCCESS
        Core->>Driver: Push thông báo biến động số dư
    else Số dư không đủ
        Core-->>RFID: Từ chối mở Barie
        RFID-->>Driver: Báo lỗi, yêu cầu làn tiền mặt
    end
  • Kịch bản 1: Xe cá nhân qua trạm một lần (Vé chặng): Khi xe tiến vào làn ETC, cảm biến kích hoạt đầu đọc RFID quét thẻ dán trên kính/đèn xe. Hệ thống kiểm tra số dư ví EPAY, trừ tiền tự động và phát lệnh mở barrier trong 165ms. Thông báo hóa đơn điện tử được gửi ngay về ứng dụng của chủ xe.
  • Kịch bản 2: Doanh nghiệp vận tải mua vé tháng/quý theo lô: Chủ doanh nghiệp quản lý danh sách 50 xe trong một tài khoản ví doanh nghiệp, thực hiện mua vé tháng đồng loạt cho từng tuyến trạm BOT cố định, giảm thiểu 90% thủ tục giấy tờ kế toán đối soát.

Yêu cầu triển khai và khả năng mở rộng

  • Yêu cầu hạ tầng máy chủ:
    • Kubernetes Cluster (tối thiểu 3 Nodes: 8 vCPU, 32GB RAM mỗi node).
    • Cơ chế Multi-AZ (Availability Zone) đảm bảo tiêu chuẩn Uptime 99.99%.
    • Kênh truyền riêng VPN IPsec kết nối trực tiếp từ Gateway EPAY tới mạng nội bộ trạm BOT.
  • Khả năng mở rộng (Scalability): Cơ sở dữ liệu thiết kế theo hướng Read/Write Splitting, kết hợp phân mảnh (Sharding) bảng TRANSACTION theo tháng, sẵn sàng mở rộng đáp ứng toàn bộ lưu lượng của 91 trạm BOT trên cả nước mà không suy giảm hiệu năng.

Hạn chế và hướng phát triển

Hạn chế kỹ thuật

  • Độ chính xác của luồng nhận diện vẫn phụ thuộc vào chất lượng vật lý của thẻ RFID (thẻ bị xước, bám bẩn hoặc dán sai vị trí làm suy giảm bước sóng tần số vô tuyến 860-960 MHz).
  • Hệ thống yêu cầu kết nối Internet liên tục để xử lý xác thực tức thời giữa App ví và Server trạm BOT; trong điều kiện đứt cáp quang cục bộ tại trạm vùng sâu, việc xử lý Offline Token còn gặp thách thức về an toàn dữ liệu.

Hướng phát triển

  1. Ứng dụng AI/Computer Vision nhận diện biển số (ANPR): Tích hợp mô hình Deep Learning nhận diện biển số xe kép với RFID, tăng độ tin cậy định danh phương tiện lên 99.98%.
  2. Mở rộng hệ sinh thái Smart Mobility: Mở rộng cổng thanh toán tích hợp bãi đỗ xe sân bay, trạm sạc xe điện thông minh (EV Charging Station) và thu phí nội đô tự động qua GPS/GNSS.

Đối tượng hưởng lợi

                     ĐỐI TƯỢNG HƯỞNG LỢI
┌─────────────────────────────────────────────────────────┐
│ Sinh viên & Người nghiên cứu:                           │
│  - Tài liệu tham khảo chuẩn mực về phân tích hệ thống   │
│  - Mô hình hóa UML/ERD và xử lý giao dịch Fintech thực tế│
├─────────────────────────────────────────────────────────┤
│ Lập trình viên & Kỹ sư hệ thống:                        │
│  - Design pattern xử lý giao dịch 2PC & Auto-Revert     │
│  - Kiến trúc tích hợp Microservices với phần cứng IoT   │
├─────────────────────────────────────────────────────────┤
│ Doanh nghiệp vận tải & Chủ xe:                          │
│  - Tiết kiệm 100% vốn đọng so với tài khoản chuyên dụng │
│  - Tinh gọn thủ tục đối soát hóa đơn VAT điện tử        │
└─────────────────────────────────────────────────────────┘
  • Sinh viên & Giảng viên ngành HTTTQL / CNTT: Cung cấp tài liệu mẫu mực về phân tích thiết kế hệ thống thông tin theo chuẩn công nghiệp, kết hợp giữa lý thuyết UML/ERD với bài toán trung gian thanh toán thực tế.
  • Lập trình viên Fintech: Cung cấp giải pháp mẫu (Design Pattern) về xử lý giao dịch phân tán, quản lý trạng thái ví treo và kỹ thuật chống nghẽn đơn hàng bằng Idempotency.
  • Doanh nghiệp BOT & Cơ quan quản lý nhà nước: Giảm chi phí vận hành nhân sự tại trạm, minh bạch hóa 100% doanh thu thu phí giao thông và cung cấp dữ liệu lớn phục vụ điều tiết giao thông quốc gia.

Câu hỏi thường gặp

1. Hệ sinh thái này có yêu cầu phần cứng đặc biệt nào trên xe không?

Không. Phương tiện chỉ cần dán thẻ định danh RFID thụ động (Passive RFID Tag) theo chuẩn ISO/IEC 18000-6C (đã được dán phổ biến bởi VETC hoặc ePass) trên kính lái hoặc chóa đèn xe.

2. Khi xảy ra tình huống tài khoản ví còn đủ tiền nhưng Barie không mở thì xử lý thế nào?

Hệ thống kích hoạt cơ chế Timeout 800ms. Nếu không nhận được tín hiệu xác nhận mở barie từ cảm biến trạm BOT, API sẽ gọi lệnh revertHoldTransaction để hoàn trả toàn bộ số tiền vừa giữ từ ví chờ về số dư khả dụng của khách hàng ngay lập tức (< 500ms). Khách hàng được thông báo để chuyển làn thu phí thủ công mà không bị trừ tiền oan.

3. Phương thức tích hợp giữa App ví EPAY và hệ thống trạm BOT có đảm bảo an toàn không?

Giao thức truyền thông sử dụng đường truyền chuyên dụng VPN IPsec với mã hóa TLS 1.3. Mọi gói tin giao dịch đều được ký số bằng thuật toán RSA-SHA256 và xác thực tính toàn vẹn qua mã băm HMAC, ngăn chặn hoàn toàn nguy cơ tấn công Man-in-the-middle hoặc giả mạo lệnh trừ tiền.

4. Người dùng có thể thanh toán phí giao thông cho nhiều xe trên cùng một ví EPAY không?

Hoàn toàn được. Hệ thống cho phép một tài khoản ví liên kết và quản lý không giới hạn số lượng xe (dành cho chủ hộ gia đình hoặc doanh nghiệp vận tải), hỗ trợ phân quyền và bật/tắt tính năng trừ tiền tự động cho từng biển số riêng biệt.

5. Chi phí và thời gian hoàn vốn đầu tư (ROI) cho giải pháp tích hợp này ước tính ra sao?

Do tận dụng hạ tầng trạm BOT và thẻ RFID sẵn có, giải pháp chỉ yêu cầu chi phí tích hợp phần mềm API và nâng cấp Gateway. Doanh nghiệp trung gian thanh toán có thể hoàn vốn trong vòng 12 - 18 tháng thông qua phí dịch vụ giao dịch thu hộ và tối ưu hóa dòng tiền luân chuyển trên hệ sinh thái ví điện tử.

Kết luận

Đồ án tốt nghiệp "Phân tích, thiết kế hệ thống thanh toán phí giao thông qua app ví điện tử EPAY" của tác giả Đỗ Thị Nga đã giải quyết thành công bài toán tích hợp công nghệ tài chính (Fintech) vào hạ tầng giao thông thông minh (ITS) tại Việt Nam. Bằng việc phân tích nghiệp vụ chuyên sâu, thiết kế hệ thống chuẩn hóa trên nền tảng React Native và cơ sở dữ liệu quan hệ 3NF tối ưu, đề tài đã mang lại giải pháp đột phá: Xóa bỏ rào cản tài khoản giao thông chuyên biệt, xử lý triệt để lỗi trừ tiền lặp bằng giải thuật Auto-Revert thời gian thực với độ trễ phản hồi ấn tượng 165ms tại 1.200 TPS.

Công trình không chỉ hoàn thành xuất sắc các mục tiêu học thuật của ngành Hệ thống Thông tin Quản lý mà còn sở hữu giá trị ứng dụng thực tiễn cao, đóng góp tích cực vào lộ trình chuyển đổi số quốc gia và phổ cập thanh toán không dùng tiền mặt trong ngành giao thông vận tải Việt Nam.