Sebelum menandatangani: memeriksa operator sistem tiket bioskop Anda

1. Satu kursi tidak terjual dua kali

Tanyakan: bagaimana sistem mencegah dua pembeli, atau loket dan situs web, mendapat kursi yang sama pada pertunjukan yang sama?

Periksa sendiri. Di kode, pencegahnya adalah satu aturan di basis data: reservation_no_overlap, sebuah EXCLUDE PostgreSQL yang menolak dua pemesanan aktif untuk kursi yang sama pada waktu yang tumpang tindih (V1__init_schema.sql:485–487). Ada tiga pasang uji. Uji "differential" sengaja mencabut satu perlindungan dan menuntut anomalinya benar-benar terjadi. Uji pasangannya memakai perlindungan yang asli dan menuntut anomali itu tidak terjadi.

Jalankan keenamnya (perlu Docker atau podman, lihat bagian "Tests" di README):

./mvnw test -DskipJsTests -Dtest='SeatBookingConcurrencyDifferentialTest,SeatBookingConcurrencyTest,SessionCancellationRaceDifferentialTest,SessionCancellationRaceTest,DailyPurchaseCapConcurrencyDifferentialTest,DailyPurchaseCapConcurrencyTest'

Keenamnya harus lulus. Uji differential yang lulus berarti anomalinya memang muncul ketika perlindungan dicabut. Itu yang membuat kelulusan uji pasangannya menjadi bukti, bukan kebetulan. Lalu pastikan aturan itu juga ada di basis data yang berjalan. Minta operator menjalankan perintah berikut di depan Anda:

SELECT conname FROM pg_constraint WHERE conname = 'reservation_no_overlap';

Jawaban yang wajar: operator menunjuk baris EXCLUDE, menjalankan keenam uji di depan Anda, dan memperlihatkan aturan itu di basis data produksi. Loket juga memesan melalui jalur yang sama (CounterSaleResource.kt:95), jadi tidak ada "kursi loket" di luar aturan ini, asal semua penjualan, termasuk di loket, memang dilakukan melalui sistem. Kursi yang dijual di loket dengan buku kertas tidak diketahui sistem.

2. Data bioskop Anda terpisah dari bioskop lain

Tanyakan: bila operator menjalankan beberapa bioskop di satu basis data, apa yang mencegah satu bioskop membaca pesanan bioskop lain? Aplikasinya terhubung ke basis data sebagai peran (role) apa?

Periksa sendiri. Pemisahannya memakai row level security (RLS) PostgreSQL. Dua puluh tabel milik bioskop memakai ENABLE dan FORCE ROW LEVEL SECURITY, dengan kebijakan yang hanya meloloskan baris milik bioskop yang sedang dilayani (V1:886–981). Bioskop itu ditetapkan per transaksi dengan set_config(…, true) (Db.kt:107–117). Migrasi membuat peran app_runtime tanpa hak superuser dan tanpa BYPASSRLS (V1:1001–1006), dan peran itu tidak bisa mengubah atau menghapus jejak audit (V1:1029).

Ada satu jebakan. Bila operator tidak mengisi apa pun, aplikasi terhubung sebagai booking, pemilik tabel, bukan sebagai app_runtime (application.properties:67, :112). RLS tetap berlaku bagi pemilik karena FORCE, tetapi pemilik bisa mengubah kebijakannya dan jejak audit tidak lagi hanya bisa ditambah (README, "Against your own PostgreSQL 18"). Aplikasi menulis di log saat mulai dengan peran apa ia terhubung, dan memberi peringatan bila peran itu bisa mengubah atau menghapus audit_log (RuntimeRoleStartupLog.kt:30–47). Minta operator memperlihatkan baris log itu, lalu menjalankan di basis data produksi:

SELECT usename, count(*) FROM pg_stat_activity WHERE datname = current_database() GROUP BY usename;
SELECT rolname, rolsuper, rolbypassrls FROM pg_roles WHERE rolname IN ('app_runtime', 'booking');
SELECT relname FROM pg_class
 WHERE relnamespace = 'public'::regnamespace AND relkind = 'r' AND relrowsecurity AND relforcerowsecurity;

Baris pertama harus memperlihatkan koneksi aplikasi atas nama app_runtime. Baris kedua harus false di kedua kolom untuk kedua peran. Baris ketiga harus mendaftar kedua puluh tabel itu. Tiga tabel sengaja tidak memakai RLS: tenant, platform_agreement_version, dan app_user, yang menyimpan alamat email akun (V1:284–294).

Yang tidak dilindungi RLS: operator sendiri. RLS melindungi satu bioskop dari bioskop lain dan dari kesalahan di kode aplikasi. RLS tidak melindungi Anda dari orang yang memegang kredensial pemilik basis data. Operator yang memegangnya bisa membaca semua baris semua bioskop, termasuk email dan tanggal lahir penonton (V1:251–266). Itu bukan cacat. Begitulah basis data bekerja. Perlindungannya ada di perjanjian (bagian 4) dan pada pilihan siapa yang memegang server (bagian 6).

Jawaban yang wajar: aplikasi berjalan sebagai app_runtime, diperlihatkan dengan tiga perintah di atas. Operator menyebut siapa saja yang memegang kredensial pemilik basis data dan berjanji tertulis untuk tidak membuka data Anda kecuali atas perintah Anda.

3. Uang pembeli

Tanyakan: uang dari pembeli masuk ke akun pedagang (merchant) Midtrans milik siapa? Kapan uang itu sampai ke rekening Anda? Siapa yang mengembalikan uang pembeli? Apa yang dicocokkan sistem?

Akun pedagang

Kode memakai satu akun pedagang Midtrans untuk satu instalasi. Nomornya diambil dari konfigurasi (MIDTRANS_MERCHANT_ID, application.properties:213–215), dan komentar di skemanya berbunyi "Our Midtrans merchant id, from configuration — an aggregator integration has no per-tenant acquirer merchant id" (V1:633–635). Artinya, bila satu instalasi melayani beberapa bioskop, uang pembeli semua bioskop itu masuk ke satu akun, dan akun itu milik siapa pun yang mengisi konfigurasinya. Biasanya operator.

Jawaban yang wajar: uang pembeli masuk ke akun Midtrans atas nama bioskop Anda dan diselesaikan (settlement) ke rekening bank Anda. Operator tidak pernah memegang uang pembeli. Dengan kode hari ini, itu berarti satu instalasi untuk bioskop Anda sendiri, dengan kredensial akun Anda. Periksa sendiri: Anda masuk ke dasbor Midtrans dengan akun Anda, dan nomor pedagang yang tampil di sana sama dengan yang tercatat di setiap baris pembayaran (kolom payment.qris_merchant_id).

Belum ada: akun pedagang per bioskop di dalam satu instalasi bersama.

Kapan uang sampai

Jadwal settlement diatur perjanjian Anda dengan Midtrans, bukan oleh kode ini. Halaman ini tidak memeriksanya. Tanyakan kepada Midtrans, bukan kepada operator.

Pengembalian uang

Untuk pembayaran QRIS, sistem mengembalikan uang sendiri. Setiap utang pengembalian yang dicatat dikirim lewat BI-SNAP (QR MPM refund) ke aplikasi pembayaran pembeli setelah pembatalannya tersimpan (RefundService.kt:75–86); kiriman yang tidak dijawab Midtrans diulang oleh penyapu 5 menit, paling banyak 12 kali. Bila Midtrans menolak, utangnya tetap ada dan masalahnya tampil di /admin/payments dengan kalimat yang menyebut langkah berikutnya, yaitu pengembalian dari dasbor Midtrans atau tunai di loket (RefundService.kt:188–213). Uang tunai tidak pernah dikirim ke Midtrans. Pembeli menerima email, dan push bila ia menyalakannya, ketika pertunjukan dibatalkan dan ketika uang dikirim atau ditolak (BuyerMail.kt:97–140); email hanya terkirim bila SMTP sudah diisi. Baru terbukti di sandbox Midtrans dengan GoPay. Aplikasi pembayaran lain, batas waktu pengembalian tiap penyedia, dan ShopeePay (hanya pengembalian penuh, hanya pukul 06.00–23.55 WIB) baru bisa diuji di produksi. Utang dicatat dan ditampilkan kepada staf di /admin/payments dan kepada pembeli di halaman pesanannya:

• ketika staf membatalkan kursi yang sudah dibayar (BookingService.kt:783–802);
• ketika pembayaran QRIS masuk setelah kodenya kedaluwarsa. Kursinya tidak diterbitkan, karena masa tahannya sudah habis (PaymentService.kt:463–490);
• ketika staf menekan "Cancel showing": setiap kursi pada pertunjukan itu dibatalkan dan setiap kursi yang sudah dibayar dicatat sebagai utang, dalam satu transaksi (BookingService.kt:680–729). QR yang masih terbuka ditarik dan dibatalkan di Midtrans; bila pembeli tetap sempat membayarnya, jumlah itu juga dicatat sebagai utang;
• ketika Midtrans melaporkan pengembalian (04), yang dihitung adalah tiap pengembalian dalam riwayatnya, bukan jumlah pesanan, dan setiap pengembalian dihitung sekali. Pengembalian yang tidak menutup utang apa pun ditandai untuk staf (PaymentService.kt:424–461).

Karena uang masuk ke akun Anda, kewajiban mengembalikannya kepada pembeli juga ada pada Anda. Hak pembeli dijelaskan di halaman untuk pembeli tiket.

Pencocokan

Setiap 5 menit, sistem menanyakan kepada Midtrans status pembayaran yang notifikasinya tidak sampai (PaymentReconciliationService.kt:16–30, application.properties:228), dan berhenti menanyakan setelah satu jam (:233). Itu pencocokan status per transaksi. Sistem tidak mencocokkan laporan settlement Midtrans atau mutasi rekening Anda dengan penjualan.

Jawaban yang wajar: operator menjelaskan prosedur tertulis untuk tiga kasus di atas (QRIS terlambat, pertunjukan dibatalkan, pembayaran ganda): siapa yang melihat, dalam berapa hari pembeli mendapat uangnya kembali, dan siapa yang menekan tombol di dasbor Midtrans untuk pengembalian yang ditolak.

Belum ada: pengembalian uang yang teruji di produksi dan untuk aplikasi pembayaran selain GoPay; pencocokan dengan laporan settlement.

Biaya operator dan penghentian layanan

Kode menagih bioskop dengan tarif bulanan tetap per paket, bukan per tiket (BillingService.kt:20–30). Angka bawaan di application.properties:308–310 hanya contoh konfigurasi, bukan harga siapa pun. Empat belas hari setelah tagihan lewat jatuh tempo, staf operator dapat menandai bioskop sebagai suspended dengan satu tombol (BillingService.kt:174–184). Status itu menolak setiap penahanan kursi baru di semua saluran: web, API aplikasi, dan loket (BookingService.kt:343–351). Kursi yang sudah ditahan sebelumnya tetap bisa dibayar dan tiket yang sudah lunas tetap bisa dipakai masuk, karena pembelinya tidak berbuat salah. Jadi satu tombol operator menghentikan penjualan Anda. Pastikan perjanjian menentukan kapan tombol itu boleh ditekan, termasuk pemberitahuan tertulis sebelum layanan dihentikan.

4. Data pribadi penonton

Tanyakan: siapa pengendali dan siapa prosesor data pribadi? Pihak lain siapa saja yang ikut menerima data? Bagaimana bentuk data Anda ketika Anda pergi? Bagaimana penghapusan dilakukan? Seberapa cepat Anda diberi tahu bila terjadi kebocoran?

Peran

UU 27/2022 tentang Pelindungan Data Pribadi membedakan Pengendali Data Pribadi, yang menentukan tujuan dan mengendalikan pemrosesan (Pasal 1 angka 4), dari Prosesor, yang memproses "atas nama" Pengendali (Pasal 1 angka 5). Pembagian yang lazim: bioskop Anda Pengendali, operator Prosesor. Pembagian itu ditentukan oleh perjanjian, bukan oleh kode. Akibatnya:

• Prosesor wajib memproses "berdasarkan perintah Pengendali" (Pasal 51 ayat 1), dan pemrosesan itu "termasuk dalam tanggung jawab Pengendali" (ayat 3). Pemrosesan "di luar perintah dan tujuan" menjadi tanggung jawab Prosesor (ayat 6).
• Prosesor "wajib mendapatkan persetujuan tertulis dari Pengendali" sebelum melibatkan prosesor lain (Pasal 51 ayat 5). Kode ini dapat mengirim data ke penyedia server, Midtrans, Google (masuk dengan akun Google, application.properties:325–328; Google Wallet, :436), Firebase untuk notifikasi, dan penyedia model bahasa untuk asisten /chat bila diaktifkan. Mintalah daftar tertulis yang menyebut mana yang aktif.

Kebocoran

Bila terjadi kegagalan pelindungan, Pengendali, yaitu Anda, wajib memberi tahu secara tertulis "paling lambat 3 x 24 (tiga kali dua puluh empat) jam" kepada Subjek Data Pribadi dan lembaga (Pasal 46 ayat 1). Pemberitahuan itu memuat data yang terungkap, kapan dan bagaimana terungkapnya, serta upaya penanganannya (ayat 2). Anda hanya bisa memenuhinya bila operator memberi tahu Anda jauh lebih awal.

Jawaban yang wajar: operator memberi tahu Anda paling lambat 24 jam sejak mengetahui kebocoran, dengan isi seperti Pasal 46 ayat 2.

Salinan data dan penghapusan

Penonton berhak memperoleh salinan datanya (Pasal 7) dan berhak menghapusnya (Pasal 8). Di kode belum ada fitur ekspor, baik untuk satu penonton maupun untuk seluruh data satu bioskop. Belum ada pula fitur penghapusan. Tabel customer_pii punya kolom deleted_at (V1:715–721), tetapi tidak ada kode yang mengisinya.

Cara sementara yang bisa diperiksa: karena RLS, perintah \copy di psql yang dijalankan sebagai app_runtime, setelah set_config('app.current_tenant_id', '<id bioskop Anda>', false), hanya mengeluarkan baris milik bioskop Anda. Untuk instalasi milik Anda sendiri, cadangan pg_dump utuh adalah salinan yang paling lengkap.

Jawaban yang wajar: perjanjian menyebut format (dump PostgreSQL atau CSV per tabel), batas waktu penyerahan setelah berakhir, batas waktu penghapusan salinan operator dengan konfirmasi tertulis, dan siapa yang menangani permintaan salinan atau penghapusan dari penonton selama perjanjian berjalan.

Belum ada: ekspor data satu bioskop; salinan data satu penonton; penghapusan data penonton.

5. Pendaftaran PSE dan OSS

Tanyakan: siapa Penyelenggara Sistem Elektronik (PSE) Lingkup Privat untuk layanan ini, operator atau bioskop Anda? Apakah pihak itu sudah terdaftar, dan apa nomor tanda daftarnya?

Pertanyaan ini masih terbuka. Panduan di repositori menyebut dua kemungkinan bacaan dan tidak menutupnya (docs/pse-oss-registration.md, bagian 2). Di sana juga dijelaskan bahwa pendaftaran di OSS bergantung pada NIB. Kode menyiapkan satu kolom per bioskop, tenant.pse_registration_no (V1:75). Kolom itu boleh kosong. Kode juga mewajibkan nomor telepon pengaduan saat bioskop didaftarkan (TenantProvisioningService.kt:251–255), dan nomor itu tampil di bagian bawah setiap halaman pembeli, bersama nomor tanda daftar PSE bila sudah dicatat (base.html:155).

Jawaban yang wajar: perjanjian menyebut pihak yang mendaftar, dan sebelum penjualan pertama pihak itu menyerahkan NIB serta nomor tanda daftar PSE-nya. Bila belum jelas, operator mengatakan belum jelas dan menyebut siapa yang akan memutuskannya, bukan menyatakan "sudah beres".

6. Letak server, cadangan data, dan saat server mati

Tanyakan: di mana server berada, siapa yang memegang kredensial pemilik basis data, siapa yang membuat cadangan, dan apa yang terjadi saat server mati pada jam ramai?

Biaya ketiganya dibandingkan di halaman on-premise atau cloud (sedang disusun).

Cadangan dan uji pemulihan

README dan docs/ tidak memuat prosedur cadangan atau pemulihan. Itu urusan operator.

Jawaban yang wajar: ada cadangan terjadwal yang disimpan di tempat lain, dan perjanjian menyebut berapa lama data terakhir boleh hilang serta berapa lama pemulihan boleh berlangsung. Yang terpenting, ada uji pemulihan yang Anda saksikan: cadangan dipulihkan ke PostgreSQL yang kosong, aplikasi dijalankan di atasnya, dan pesanan terakhir yang Anda kenal muncul. Cadangan yang belum pernah dipulihkan belum terbukti bisa dipakai.

Belum ada: prosedur cadangan dan pemulihan yang tertulis di repositori.

Saat server mati

movie-ticket tidak punya aplikasi loket atau kios yang bisa bekerja tanpa server. Halaman loket (CounterSaleResource.kt) dan pemindai di pintu masuk dilayani oleh server yang sama dengan situs pembeli. Bila server mati, penjualan daring, penjualan loket lewat sistem, dan pemeriksaan tiket di pintu berhenti bersamaan.

Jawaban yang wajar: ada rencana tertulis untuk menjual dan memeriksa tiket secara manual. Rencana itu menyebut siapa yang memutuskan kursi mana yang boleh dijual manual, karena kursi yang dijual di luar sistem tidak diketahui sistem (bagian 1). Ada pula cara mencatat penjualan manual itu ke sistem setelah server hidup lagi, waktu tanggap operator untuk gangguan "tidak bisa menjual sama sekali", dan nomor yang bisa dihubungi pada jam tayang, termasuk malam dan akhir pekan.

7. Pindah operator atau menjalankan sendiri

Kodenya berlisensi Apache-2.0 (LICENSE). Bioskop Anda boleh menjalankannya sendiri atau memindahkannya ke operator lain. Lisensi ini tidak mewajibkan operator membuka perubahan yang ia buat pada kodenya. Bila operator menjalankan versi yang diubah, perubahan itu hanya Anda dapatkan bila perjanjian memintanya.

Jawaban yang wajar: semua akun di tabel ini atas nama bioskop Anda sejak awal, atau perjanjian mewajibkan pemindahannya ketika Anda pergi, dengan batas waktu dan bantuan teknis yang disebut.

8. Isi perjanjian

Bahasa

UU 24/2009 Pasal 31 ayat (1): "Bahasa Indonesia wajib digunakan dalam nota kesepahaman atau perjanjian yang melibatkan lembaga negara, instansi pemerintah Republik Indonesia, lembaga swasta Indonesia atau perseorangan warga negara Indonesia." Perpres 63/2019 Pasal 26 ayat (4): bila padanan atau terjemahannya ditafsirkan berbeda, "bahasa yang digunakan ialah bahasa yang disepakati dalam nota kesepahaman atau perjanjian".

Dalam putusan 1572 K/Pdt/2015 (23 Oktober 2015), Mahkamah Agung menolak kasasi atas putusan yang menyatakan sebuah loan agreement batal demi hukum karena "tidak dibuat dalam bahasa Indonesia", bertentangan dengan Pasal 31 ayat (1), sehingga dibuat "berdasarkan sebab yang terlarang" (KUHPerdata Pasal 1335 jo. 1337). SEMA 3/2023, Rumusan Kamar Perdata, Perdata Umum angka 1, kemudian menyatakan: perjanjian "dengan pihak asing dalam bahasa asing yang tidak disertai dengan terjemahan bahasa Indonesia tidak dapat dijadikan alasan pembatalan perjanjian, kecuali dapat dibuktikan bahwa ketiadaan terjemahan Bahasa Indonesia karena adanya iktikad tidak baik oleh salah satu pihak". Bila bioskop Anda dan operator sama-sama pihak Indonesia, yang paling aman adalah perjanjian dalam Bahasa Indonesia. Bila ada salinan bahasa lain, sebutkan bahasa mana yang berlaku.

Tempat menyelesaikan sengketa

Untuk sengketa tentang biaya layanan bulanan, biaya minimum BANI bisa melebihi nilai yang disengketakan. Pilih tempat sengketa dengan sadar, bukan karena sudah tertulis di draf.

Biaya, layanan, dan tanggal berakhir

• Biaya: jumlahnya, apa saja yang termasuk (server, cadangan, dukungan, pembaruan keamanan), dan bagaimana biaya boleh berubah: pemberitahuan tertulis sebelumnya dan hak Anda untuk keluar tanpa denda bila tidak setuju. Apa yang wajar dicakup sebuah biaya dibahas di halaman on-premise atau cloud.
• Tingkat layanan: ketersediaan yang dijanjikan, diukur pada jam tayang Anda; waktu tanggap untuk "tidak bisa menjual sama sekali" dan untuk gangguan lain; pemberitahuan sebelum pemeliharaan terjadwal; dan apa yang Anda dapat bila janji itu tidak tercapai.
• Batas tanggung jawab: bila tanggung jawab operator dibatasi, periksa apakah kebocoran data pribadi dan pemrosesan di luar perintah Anda ikut dibatasi. Ingat UU PDP Pasal 51 ayat (6).
• Tanggal berakhir: tanggal yang pasti, cara memperpanjang, cara mengakhiri lebih awal, dan apa yang tetap berlaku setelah berakhir (data, kerahasiaan, bantuan pindah).

9. Pajak tontonan (PBJT)

Tiket bioskop termasuk objek Pajak Barang dan Jasa Tertentu atas jasa kesenian dan hiburan. UU 1/2022 Pasal 56 ayat (2): "Wajib Pajak PBJT adalah orang pribadi atau Badan yang melakukan penjualan, penyerahan, dan/atau konsumsi barang dan jasa tertentu", yaitu bioskop yang menjual tiket. Operator menjual layanan perangkat lunak kepada bioskop, bukan pertunjukan. Dasar pengenaannya adalah "jumlah yang dibayarkan oleh konsumen" (Pasal 57 ayat 1). Tarifnya "paling tinggi sebesar 10%" (Pasal 58 ayat 1) dan ditetapkan oleh Perda masing-masing daerah.

PP 35/2023 menyatakan PBJT atas jasa kesenian dan hiburan "dipungut berdasarkan penghitungan sendiri oleh Wajib Pajak" (Pasal 3 ayat 4 huruf b angka 5), dengan masa pajak satu bulan kalender atau paling lama tiga bulan (Pasal 4 ayat 3), dan dasar pengenaan "jumlah pembayaran yang diterima oleh penyelenggara Jasa Kesenian dan Hiburan" (Pasal 19 ayat 1 huruf e). Halaman ini tidak menemukan pasal dalam PP 35/2023 yang menunjuk penyedia pembayaran atau operator perangkat lunak sebagai pemungut. Apakah Perda daerah Anda menunjuk pihak ketiga tidak diteliti. Tanyakan kepada Bapenda setempat.

Angka yang Anda perlukan untuk melapor: jumlah yang dibayar pembeli per bulan, dipisah tunai dan QRIS, dikurangi pengembalian. Harga tersimpan per kursi saat dipesan (BookingService.kt:922–934), dan pembayaran tersimpan di tabel payment. Kode tidak punya baris pajak, tetapi ada laporan penjualan: /admin/payments/sales.csv, dari formulir di halaman /admin (PaymentAttentionResource.kt:97). Isinya satu baris per tanggal, cabang, kota, dan saluran (tunai atau QRIS): jumlah pembayaran, nilai kotor, dan pengembalian yang masih terutang (PaymentRepository.kt:291). Kota dicantumkan karena PBJT adalah pajak kabupaten/kota. Nilai kotor dan pengembalian tidak dikurangkan: sistem tidak memindahkan uang kembali, jadi angka bersih hanya tebakan tentang pengembalian yang dilakukan staf secara manual. Laporan itu tidak memuat jumlah tiket maupun tarif PBJT.

Jawaban yang wajar: operator menyerahkan laporan bulanan tertulis (penjualan per hari, tunai dan QRIS, pengembalian), dan perjanjian menyebut apakah harga tiket di sistem sudah termasuk PBJT.

Belum ada: laporan pajak (tarif PBJT ditetapkan per daerah) dan jumlah tiket terjual di laporan penjualan.

10. Ringkasan: yang belum ada di kode

Untuk setiap baris di bawah, jawaban yang wajar tidak bisa diberikan oleh kode hari ini. Jawabannya harus datang dari prosedur operator yang tertulis di perjanjian.

11. Sumber

1. UU 27/2022 tentang Pelindungan Data Pribadi, Pasal 1 angka 4–5, 7, 8, 46, 51: peraturan.bpk.go.id.
2. UU 30/1999 tentang Arbitrase dan Alternatif Penyelesaian Sengketa, Pasal 11, 27, 60: peraturan.bpk.go.id.
3. Peraturan dan Prosedur Arbitrase BANI 2025, dan daftar biaya BANI (berlaku untuk perkara yang didaftarkan sejak 2 Januari 2026): baniarbitration.org/fees, dibaca 4 November 2026.
4. PERMA 4/2019 tentang perubahan PERMA 2/2015 tentang Tata Cara Penyelesaian Gugatan Sederhana, Pasal 1 angka 1: peraturan.bpk.go.id.
5. UU 24/2009 tentang Bendera, Bahasa, dan Lambang Negara, serta Lagu Kebangsaan, Pasal 31: peraturan.bpk.go.id.
6. Perpres 63/2019 tentang Penggunaan Bahasa Indonesia, Pasal 26: peraturan.bpk.go.id.
7. Putusan Mahkamah Agung Nomor 1572 K/Pdt/2015, diputus 23 Oktober 2015: Direktori Putusan Mahkamah Agung, putusan3.mahkamahagung.go.id.
8. SEMA 3/2023 tentang Pemberlakuan Rumusan Hasil Rapat Pleno Kamar Mahkamah Agung Tahun 2023, B.1: jdih.mahkamahagung.go.id.
9. UU 1/2022 tentang Hubungan Keuangan antara Pemerintah Pusat dan Pemerintahan Daerah, Pasal 55–58: peraturan.bpk.go.id.
10. PP 35/2023 tentang Ketentuan Umum Pajak Daerah dan Retribusi Daerah, Pasal 1 angka 14, 3, 4, 19: peraturan.bpk.go.id.
11. movie-ticket, kode sumber pada commit 39351cc; pertanyaan untuk operator: README; pendaftaran PSE: docs/pse-oss-registration.md.
12. Untuk pembeli tiket: Kursi Anda, uang Anda.