PCI DSS saat memakai payment gateway: redirect, iframe dan SAQ A

1. Pastikan cara pembayaran dipasang

Minta pengembang menunjukkan alur yang benar-benar berjalan. Nama produk gateway saja belum cukup. Tabel berikut adalah titik awal pembahasan teknis, bukan keputusan otomatis tentang SAQ yang boleh dipakai.

Pola integrasi	Yang perlu diperiksa tim
Redirect	Pembeli dipindahkan ke halaman penyedia untuk mengisi data kartu. Catat siapa yang dapat mengubah alamat tujuan.
Formulir tertanam, misalnya iframe	Formulir penyedia muncul di dalam halaman toko. Catat asal formulir dan skrip yang berjalan pada halaman.
Formulir buatan toko atau data melewati server sendiri	Telusuri komponen yang menerima atau mengirim data. Jangan menganggap lingkupnya sama dengan redirect atau iframe.

Jika toko menerima pembayaran melalui beberapa kanal, catat masing-masing. Jangan memakai hasil pemeriksaan satu website untuk menyimpulkan kondisi seluruh kanal, aplikasi, atau toko lain.

2. Jangan langsung memilih SAQ A

SAQ A merupakan kuesioner untuk merchant tertentu yang menyerahkan fungsi data pembayaran ke pihak ketiga dan memenuhi seluruh kriteria kelayakannya. Memasang iframe atau redirect saja belum membuktikan semua syarat terpenuhi.

Baca formulir yang sesuai di perpustakaan PCI SSC dan konfirmasikan pilihan dengan acquirer atau merek kartu. Pengantar PCI DSS menjelaskan peran mereka serta dokumen pelaporan yang mungkin diminta.

3. Periksa ketentuan skrip pada formulir tertanam

Revisi SAQ A Januari 2025, berlaku 31 Maret 2025, menghapus pertanyaan 6.4.3, 11.6.1 dan 12.3.1 yang terkait dari formulir itu serta menambahkan kriteria kelayakan tentang serangan skrip. Perubahan formulir ini tidak menghapus persyaratan tersebut dari PCI DSS.

FAQ 1588 menjelaskan bahwa kriteria skrip tersebut berlaku pada halaman merchant yang memuat formulir pembayaran tertanam dari penyedia. Kriteria khusus itu tidak berlaku pada pola redirect atau pembayaran yang seluruhnya dialihkan, seperti tautan pembayaran melalui email. Perbedaan ini bukan pembebasan dari seluruh persyaratan lain.

Untuk formulir tertanam, FAQ tersebut menjelaskan dua cara konfirmasi: menerapkan teknik pelindungan halaman, misalnya yang dibahas pada 6.4.3 dan 11.6.1; atau memperoleh konfirmasi dari penyedia patuh PCI DSS bahwa solusinya melindungi halaman pembayaran dari serangan skrip bila dipasang sesuai instruksinya.

Sebagai pekerjaan tim, simpan instruksi integrasi dan bukti bahwa penerapannya sesuai. Periksa ulang ketika pengembang mengganti komponen checkout atau menambahkan skrip. Jangan mengubah halaman pembayaran hanya berdasarkan contoh kode tanpa mengetahui dampaknya.

4. Bedakan pemeriksaan skrip dari pemindaian ASV

FAQ 1604, diperbarui Juni 2026, menegaskan bahwa ketentuan pemindaian kerentanan eksternal oleh Approved Scanning Vendor (ASV) dalam SAQ A juga mencakup halaman merchant yang melakukan redirect maupun memuat iframe penyedia. Mengalihkan pemrosesan kartu ke pihak ketiga tidak otomatis menghilangkan pekerjaan ini.

Untuk memenuhi ketentuan pemindaian ASV, layanan pemindaian harus dilakukan oleh ASV yang tercantum pada daftar PCI SSC dengan solusi pemindaiannya. Pemeriksaan biasa dari alat keamanan website tidak otomatis menjadi pemindaian ASV.

Contoh fiktif: sebuah toko memakai redirect dan menyimpulkan bahwa pengecualian kriteria skrip berarti websitenya tidak perlu diperiksa lagi. Kesimpulan itu keliru: kriteria skrip dan pemindaian ASV adalah pembahasan berbeda. Minta penjelasan lingkup pemindaian, pemilik tindak lanjut, dan bukti hasil yang perlu disimpan.

5. Jangan menyimpan CVV untuk tagihan berikutnya

Untuk merchant, kode verifikasi kartu seperti CVV/CVC tidak boleh disimpan setelah transaksi diotorisasi, termasuk untuk pembayaran berulang. FAQ 1280 menjelaskan bahwa enkripsi atau izin pelanggan tidak membolehkan penyimpanan tersebut. Bahas mekanisme pembayaran berulang yang sesuai dengan penyedia dan pengelola program kepatuhan.

Sebagai pemeriksaan praktis, telusuri apakah formulir bantuan, rekaman sesi, log aplikasi, atau pesan kesalahan dapat menangkap data yang tidak seharusnya disimpan. Gunakan lingkungan uji serta data uji yang disediakan untuk pengujian; jangan mengirim data kartu pelanggan ke checklist atau percakapan tim.

Apa yang dibawa ke pertemuan dengan penyedia?

Siapkan gambar alur pembayaran, daftar komponen checkout, instruksi integrasi yang dipakai, pembagian pekerjaan dan pertanyaan yang belum terjawab. Setelah rapat, catat keputusan dan siapa yang menindaklanjutinya.

Gunakan checklist persiapan PCI DSS. Untuk pekerjaan pengamanan website secara umum, lanjutkan ke panduan keamanan website dan aplikasi. Panduan ini tidak memilih SAQ atas nama merchant atau menjalankan pemindaian sistem.