Apa Itu AFC dan Hubungannya dengan Sistem Transportasi

Dalam sistem transportasi modern, proses pembayaran tidak hanya soal penumpang menempelkan kartu atau scan QR. Di belakangnya ada sistem yang mengatur tarif, validasi perjalanan, perangkat terminal, data transaksi, dan pelaporan operasional.

Salah satu konsep penting di area ini adalah AFC atau Automatic Fare Collection.

Apa itu AFC?

AFC (Automatic Fare Collection) adalah sistem otomatis untuk mengelola pembayaran, validasi tiket, perhitungan tarif, dan pencatatan transaksi pada layanan transportasi.

Secara sederhana, AFC menjawab pertanyaan:

• Apakah penumpang punya media pembayaran yang valid?
• Berapa tarif yang harus dibayar?
• Dari mana dan ke mana perjalanan dilakukan?
• Apakah transaksi berhasil, gagal, atau perlu disinkronkan ulang?
• Bagaimana data transaksi masuk ke sistem pelaporan?

Jadi AFC bukan hanya aplikasi pembayaran. AFC adalah kombinasi antara software, hardware, fare rules, payment integration, dan backend operations.

Hubungan AFC dengan transportasi

Di transportasi publik, AFC menjadi penghubung antara penumpang, operator, perangkat lapangan, dan sistem pusat.

Contoh alur sederhananya:

Passenger -> Tap / Scan -> Fare Calculation -> Payment Validation -> Transaction Log -> Backend Sync -> Reporting

Pada bus, terminal, gate, atau validator, sistem AFC biasanya berjalan di perangkat yang terhubung dengan card reader, QR scanner, GPS, dan backend API. Perangkat ini harus bisa memproses transaksi dengan cepat karena digunakan dalam situasi operasional yang padat.

Komponen utama dalam sistem AFC

Sistem AFC biasanya terdiri dari beberapa komponen berikut.

1) Fare management

Fare management mengatur struktur tarif. Bentuknya bisa berbeda tergantung model transportasi:

• Flat fare: tarif sama untuk semua perjalanan.
• Dynamic fare: tarif dihitung berdasarkan titik naik dan titik turun.
• Zone-based fare: tarif berdasarkan zona perjalanan.
• Route-based fare: tarif mengikuti rute atau trayek tertentu.

Bagian ini penting karena kesalahan data tarif bisa langsung berdampak pada nilai transaksi.

2) Payment media

AFC mendukung berbagai media pembayaran, misalnya:

• kartu transportasi atau prepaid card,
• QR payment,
• mobile wallet,
• tiket digital,
• token atau pass khusus.

Di level aplikasi, setiap media pembayaran punya flow dan error handling yang berbeda. Kartu membutuhkan reader dan validasi saldo. QR membutuhkan validasi payload. Mobile payment bisa membutuhkan komunikasi dengan provider eksternal.

3) Validator atau terminal device

Validator adalah perangkat yang digunakan di lapangan. Bentuknya bisa berupa gate terminal, bus validator, handheld device, atau Android terminal.

Perangkat ini biasanya memiliki peripheral seperti:

• NFC atau card reader,
• QR scanner atau camera,
• GPS/location module,
• SIM/4G, Wi-Fi, atau Ethernet,
• printer atau customer display pada beberapa konfigurasi,
• secure module seperti SAM/PSAM untuk kebutuhan pembayaran tertentu.

Karena perangkat AFC berada di lapangan, aplikasi harus memperhatikan service readiness, koneksi yang tidak stabil, retry, logging, dan local storage.

4) Trip dan location context

Pada transportasi berbasis rute, transaksi tidak bisa diproses hanya dari media pembayaran. Sistem juga perlu tahu konteks perjalanan:

• trayek atau route yang aktif,
• halte atau stop saat ini,
• arah perjalanan,
• status trip,
• asal dan tujuan penumpang jika memakai dynamic fare.

Inilah alasan AFC sering terhubung dengan GPS atau mekanisme stop lock. Lokasi membantu sistem menentukan konteks tarif dan status perjalanan.

5) Backend sync dan reporting

Transaksi di device lapangan biasanya perlu dikirim ke backend untuk:

• rekonsiliasi pembayaran,
• laporan operasional,
• monitoring device,
• analisis ridership,
• audit transaksi,
• troubleshooting ketika terjadi error.

Jika jaringan tidak stabil, aplikasi AFC perlu menyimpan transaksi secara lokal dulu, lalu melakukan sinkronisasi ketika koneksi tersedia.

Kenapa AFC cukup kompleks?

AFC terlihat sederhana dari sisi user, tetapi kompleks dari sisi engineering. Penyebabnya:

• sistem harus cepat karena transaksi terjadi saat penumpang naik atau turun,
• perangkat berinteraksi dengan hardware dan payment provider,
• data tarif harus konsisten dengan rute dan konfigurasi backend,
• kondisi jaringan di lapangan tidak selalu stabil,
• transaksi harus aman, tercatat, dan bisa diaudit,
• operator membutuhkan laporan yang jelas untuk operasional harian.

Dengan kata lain, AFC adalah sistem real-world operation. Aplikasi tidak hanya harus terlihat baik, tetapi juga harus tahan terhadap kondisi perangkat, jaringan, dan proses lapangan.

Contoh flow AFC di bus

Pada sistem bus, alurnya bisa seperti ini:

1. Operator login ke terminal.
2. Device mengambil konfigurasi, data trayek, dan fare rules.
3. Operator memilih trayek dan memulai trip.
4. Sistem menentukan stop aktif melalui GPS atau input manual.
5. Penumpang melakukan tap kartu atau scan QR.
6. Aplikasi menghitung tarif berdasarkan rule yang berlaku.
7. Transaksi disimpan ke local database dan log.
8. Data transaksi dikirim ke backend untuk pelaporan.

Jika memakai dynamic fare, flow bisa lebih panjang karena sistem harus menentukan asal dan tujuan perjalanan sebelum nilai akhir transaksi dihitung.

Peran Android dalam AFC

Android sering digunakan untuk AFC karena fleksibel untuk integrasi perangkat lapangan. Dalam implementasi nyata, aplikasi Android bisa menangani:

• UI operator,
• card reader SDK,
• QR scanner atau QR provider SDK,
• local database seperti Room,
• foreground service untuk sync, heartbeat, atau location,
• API integration,
• logging untuk debugging,
• state management untuk trip dan transaction flow.

Tantangannya adalah menjaga agar semua komponen ini tetap sinkron. UI, background service, local database, hardware SDK, dan backend API harus bekerja dalam urutan yang aman.

Hal yang perlu diperhatikan saat membangun AFC

Beberapa prinsip engineering yang penting:

• Validate before transaction: pastikan config, fare, reader, dan service siap sebelum transaksi.
• Local-first transaction: simpan transaksi lokal dulu agar tidak hilang saat network bermasalah.
• Clear state: bedakan status pending, success, failed, synced, dan retry.
• Strong logging: log harus cukup jelas untuk debugging lapangan.
• Safe retry: retry tidak boleh membuat transaksi ganda.
• Operational UX: UI harus cepat dipahami operator, bukan hanya terlihat rapi.

Penutup

AFC adalah bagian penting dari sistem transportasi karena menghubungkan pembayaran, validasi perjalanan, perangkat lapangan, dan pelaporan operasional.

Untuk engineer, membangun AFC berarti bekerja di antara mobile app, device integration, payment flow, local storage, backend sync, dan business rules transportasi.

Kesimpulannya: AFC bukan sekadar fitur ticketing. AFC adalah sistem operasional yang memastikan perjalanan, pembayaran, dan data transportasi bisa berjalan secara konsisten di dunia nyata.