Kepatuhan PCI untuk Pengembang Aplikasi: Versi Singkat dan Menyakitkan

Kepatuhan PCI (aturan keamanan industri kartu pembayaran bagi siapa saja yang menangani data kartu) adalah harga yang harus dibayar demi kata-kata "menerima kartu kredit." Versi singkatnya: jika data kartu pernah menyentuh kode yang Anda tulis atau server yang Anda kelola, Anda menanggung standar keamanan dengan ratusan kontrol, atestasi tahunan (pernyataan resmi bertanda tangan bahwa Anda memenuhi standar), dan konsekuensi yang disalurkan melalui pemroses pembayaran Anda. Versi menyakitkan dari kepatuhan PCI bagi pengembang aplikasi: sebagian besar baru menyadarinya setelah alur checkout selesai dibuat.

Satu catatan sebelum masuk ke rincian. Nomor versi, tanggal, dan aturan kuesioner di bawah ini akurat pada saat publikasi; standar ini terus berkembang, jadi anggap rincian ini sebagai gambaran pada saat tulisan dibuat.

Apa itu kepatuhan PCI sebenarnya?

PCI DSS (Payment Card Industry Data Security Standard) adalah kewajiban kontraktual, bukan undang-undang. Jaringan kartu menerapkannya pada bank dan pemroses pembayaran, lalu mereka menerapkannya pada merchant dan perangkat lunak yang dijalankan oleh merchant tersebut. Versi saat ini adalah 4.0.1, dan gelombang terakhir dari persyaratan barunya mulai wajib berlaku pada 31 Maret 2025¹. Standar ini mencakup 12 kelompok persyaratan, mulai dari keamanan jaringan dan enkripsi hingga kontrol akses dan pencatatan log, yang berkembang menjadi ratusan kontrol individual².

Tidak ada regulator yang akan datang ke pintu Anda. Konsekuensinya justru datang secara komersial: denda yang diteruskan melalui bank akuisisi Anda (bank yang memproses penyelesaian pembayaran kartu untuk merchant), biaya pemrosesan yang lebih tinggi, dan dalam skenario terburuk, kehilangan kemampuan untuk menerima kartu sama sekali. Setelah terjadi kebocoran data, biaya investigasi forensik dan penerbitan ulang kartu akan mengikuti alur yang sama.

Mengapa "tinggal tambah pembayaran" memasukkan seluruh aplikasi Anda ke dalam cakupan PCI?

Cakupan (scope) adalah inti dari segalanya. PCI DSS berlaku untuk setiap sistem yang menyimpan, memproses, atau mentransmisikan data pemegang kartu, ditambah semua sistem yang terhubung dengannya. Validasi bekerja seperti tangga, dan setiap anak tangga jauh lebih berat daripada anak tangga sebelumnya²:

• SAQ A (Self-Assessment Questionnaire A): pemrosesan pembayaran sepenuhnya diserahkan kepada penyedia yang patuh dan data kartu tidak pernah menyentuh sistem Anda. Ini adalah kuesioner terpendek.

• SAQ A-EP: situs Anda tidak pernah menyentuh data kartu tetapi mengontrol bagaimana pelanggan mengakses formulir pembayaran. Sebagian besar dari standar penuh kini berlaku untuk server web Anda.

• SAQ D: data kartu melewati apa pun yang Anda bangun, meskipun hanya sebentar dan tidak disimpan. Secara efektif berlaku seluruh standar, yang wajib didokumentasikan dan diatestasi setiap tahun.

Anak tangga terbawah pun bukan berarti "tanpa beban." Pada Januari 2025, PCI Security Standards Council menghapus persyaratan skrip halaman pembayaran dari SAQ A, tetapi menambahkan syarat kelayakan: Anda harus mengonfirmasi bahwa situs Anda tidak rentan terhadap serangan skrip yang dapat memengaruhi sistem e-commerce Anda¹. Bahkan tingkat yang sepenuhnya diserahkan ke pihak ketiga pun mengharuskan Anda melindungi halaman yang memuat formulir pembayaran milik pihak lain tersebut.

Jika transaksi kartu melebihi enam juta per tahun, penilaian mandiri berakhir sepenuhnya dan audit di lokasi oleh QSA (Qualified Security Assessor atau penilai eksternal tersertifikasi) akan dimulai².

Bisakah Anda menyiasati pembayaran kartu langsung dengan pengkodean?

Tidak. Pembayaran tatap muka adalah titik di mana tangga berubah menjadi tembok pembatas. Transaksi kartu langsung (card-present) membutuhkan perangkat keras tersertifikasi: pembaca fisik yang telah lolos program laboratorium PTS dari Dewan, menjalankan firmware terdisetujui, dan dipasok melalui pemroses pembayaran. Mengubah ponsel menjadi mesin pembaca hanya dengan perangkat lunak diatur dalam standar terpisah, yaitu Mobile Payments on COTS (MPoC), yang menyertifikasi penyedia solusi, bukan aplikasi yang Anda buat.

Ini adalah batasan yang tidak dapat ditembus oleh pembuatan kode AI. Sebuah model bisa menghasilkan tampilan checkout yang meyakinkan dalam waktu satu sore; artikel Bisakah Anda Membangun POS dengan Lovable atau Replit? dan *Vibe Coding* Point of Sale mengulas di mana pembuatan aplikasi semacam itu mengalami jalan buntu. Tidak ada kode buatan AI yang bisa menghasilkan pembaca kartu tersertifikasi, perjanjian akuisisi, atau atestasi kepatuhan, tidak peduli seberapa lama model AI tersebut mengode tanpa pengawasan. Kepatuhan juga menjadi alasan berulang mengapa aplikasi pembayaran hasil *vibe coding* ditolak dari App Store.

Bagaimana cara pengembang memperkecil cakupan PCI secara nyata?

Anda tidak perlu memaksakan kepatuhan yang lebih rumit; Anda cukup merancang arsitektur sehingga semakin sedikit hal yang perlu dipatuhi:

• Jangan pernah membiarkan PAN (primary account number, yaitu nomor kartu itu sendiri) menyentuh kode Anda. Gunakan hosted payment fields dari pemroses Anda sehingga data kartu terkirim langsung dari peramban pelanggan ke pemroses.

• Simpan token, bukan kartu. Tokenisasi (mengganti nomor kartu dengan string referensi yang tidak berguna jika dicuri) mencegah kartu tersimpan dan pengembalian dana menarik basis data Anda ke dalam cakupan PCI.

• Untuk penjualan langsung, gunakan pembaca kartu tersertifikasi dari pemroses Anda sehingga data kartu mengalir dari pembaca ke pemroses tanpa melalui aplikasi Anda.

• Buat halaman pembayaran sesederhana mungkin. Setiap skrip pihak ketiga di halaman tersebut akan menjadi hal yang harus Anda pertanggungjawabkan.

Jika dilakukan dengan benar, aplikasi Anda mengatur alur penjualan tanpa pernah memiliki data kartu, dan kuesioner tetap singkat. Jika salah, satu fitur kemudahan ("catat saja seluruh request body") secara diam-diam akan mengalihkan Anda ke SAQ D.

Jadi seberapa menyakitkan kepatuhan PCI bagi pengembang aplikasi?

Menyakitkan sebanding dengan seberapa banyak data kartu yang tersentuh oleh kode Anda, itulah mengapa langkah terbaik adalah tidak menyentuhnya sama sekali. Standar ini tidak peduli apakah tim pengembang yang menulis aplikasi Anda atau AI yang membuatnya dalam waktu satu sore; cakupan tetaplah cakupan. Sebelum Anda merilis apa pun yang menerima kartu, ajukan satu pertanyaan: mungkinkah nomor kartu melewati kode yang saya tulis? Jika ya, siapkan anggaran untuk audit. Jika tidak, pertahankan kondisi tersebut.

Arsitektur seperti itulah yang digunakan oleh Final. Checkout yang dibangun di atas Final, baik yang diinstruksikan melalui Build atau dibangun oleh AI Anda sendiri melalui MCP, menjalankan pembayarannya melalui Final Pay: pemroses pembayaran dan perangkat keras terminal tersertifikasi menangani data kartu, sehingga alur itu sendiri tidak pernah menyimpan nomor kartu. Artikel Di mana Final Pay tersedia membahas sisi praktisnya, dan Menghubungkan Tap to Pay ke Alur POS AI menunjukkan seperti apa penerimaan kartu ketika lapisan kepatuhan sudah tersedia di bawahnya.