Chrome mengusulkan pengalaman baru untuk pilihan pengguna terkait cookie pihak ketiga. Anda perlu menyiapkan situs untuk pengguna yang memilih untuk menjelajah tanpa cookie pihak ketiga.
Halaman ini berisi informasi tentang hal yang mungkin terpengaruh oleh perubahan mendatang.
Perjalanan umum pengguna
Banyak alur kerja pembayaran dan belanja mengandalkan cookie pihak ketiga. Tabel berikut mencantumkan beberapa perjalanan pengguna yang mungkin terpengaruh jika cookie pihak ketiga dinonaktifkan, dan menyarankan API alternatif yang dapat digunakan developer untuk menghindari kerusakan. Daftar ini mungkin tidak lengkap dan dapat diperbarui seiring dengan semakin banyaknya solusi Privacy Sandbox yang tersedia. Sebaiknya Anda memberikan masukan jika menemukan skenario tambahan yang terpengaruh.
Menguji perjalanan pengguna terkait pembayaran
Cara terbaik untuk menguji apakah alur penggunaan Anda terpengaruh oleh pembatasan cookie pihak ketiga adalah dengan menjalankannya dengan tanda pengujian cookie pihak ketiga diaktifkan.
Untuk memastikan situs Anda berfungsi seperti yang diharapkan, uji alur berikut dengan cookie pihak ketiga yang dibatasi:
- Checkout lintas situs: Uji alur pembayaran yang mengandalkan
penyedia pembayaran pihak ketiga (seperti Bayar dengan <example-provider>). Pastikan
bahwa:
- Pengalihan berhasil dilakukan.
- Gateway pembayaran dimuat dengan benar.
- Proses pembayaran dapat diselesaikan tanpa error.
- Pengguna dialihkan kembali ke situs Anda seperti yang diharapkan.
- Dasbor pembayaran: Uji apakah widget dasbor transaksi berfungsi seperti
yang diharapkan dengan cookie pihak ketiga yang dibatasi. Verifikasi bahwa pengguna dapat:
- Akses dasbor.
- Lihat semua pembayaran seperti yang diharapkan.
- Beralih antar-bagian dasbor tanpa error (misalnya, histori transaksi, detail pembayaran).
- Kelola metode pembayaran: Uji apakah widget pengelolaan metode pembayaran
berfungsi seperti yang diharapkan. Dengan cookie pihak ketiga diblokir, uji apakah:
- Menambahkan atau menghapus metode pembayaran berfungsi seperti yang diharapkan.
- Pembayaran dengan metode pembayaran yang disimpan sebelumnya tidak akan terpengaruh.
- Deteksi penipuan: Bandingkan cara kerja solusi deteksi penipuan Anda
dengan dan tanpa cookie pihak ketiga.
- Apakah pemblokiran cookie pihak ketiga akan menimbulkan langkah tambahan, yang menyebabkan hambatan tambahan bagi pengguna?
- Apakah fitur ini masih dapat mendeteksi pola yang mencurigakan saat cookie pihak ketiga diblokir di browser?
- Tombol checkout yang dipersonalisasi: Uji apakah tombol pembayaran dirender
dengan benar dengan cookie pihak ketiga yang dibatasi.
- Dapatkah pengguna tetap menyelesaikan pembelian meskipun tombol yang dipersonalisasi tidak menampilkan metode pilihan mereka?
Checkout lintas situs
Beberapa penyedia pembayaran mungkin mengandalkan cookie pihak ketiga untuk mengizinkan pengguna mengakses akun mereka di beberapa situs penjual tanpa perlu mengautentikasi ulang. Perjalanan pengguna ini mungkin terpengaruh bagi pengguna yang memilih untuk menjelajah tanpa cookie pihak ketiga.
Formulir checkout tersemat
Pertimbangkan domain berikut:
payment-provider.example
menyediakan layanan pembayaran ke situs penjual, dan menyimpan data sesi dan pembayaran pengguna.merchant.example
adalah situs yang menyematkan formulir checkout yang disediakan olehpayment-provider.example
.
Pengguna baru saja login ke payment-provider.example
(misalnya, saat
menyelesaikan checkout di situs lain). Pengguna memulai proses checkout di
merchant.example
.
Dengan cookie pihak ketiga yang tersedia, formulir checkout payment-provider.example
yang disematkan di merchant.example
akan memiliki akses ke cookie sesi tingkat atas
miliknya sendiri yang ditetapkan di payment-provider.example
dalam konteks tingkat atas.
Namun, jika cookie pihak ketiga diblokir, penyematan tidak akan memiliki akses ke
cookie tingkat teratas miliknya sendiri.

Solusi yang dapat disesuaikan dengan FedCM
payment-provider.example
harus mempertimbangkan untuk menerapkan
FedCM agar dapat bertindak sebagai
penyedia identitas. Pendekatan ini dapat sangat cocok jika:
payment-provider.example
disematkan di situs pihak ketiga yang tidak terkait.payment-provider.example
disematkan di lebih dari lima situs terkait.
Manfaat utama FedCM adalah UI dapat memberikan lebih banyak konteks kepada pengguna untuk
pilihan mereka. Dengan izin pengguna, FedCM memungkinkan pembagian
data kustom
antara Pihak Penerima (merchant.example
) dan Penyedia Identitas
(payment-provider.example
). Pihak penerima dapat memilih untuk mendukung satu atau beberapa
penyedia identitas, dan UI FedCM hanya akan ditampilkan
secara bersyarat.
Bergantung pada kebutuhan, developer dapat memilih antara mode pasif agar perintah FedCM muncul secara otomatis saat pengguna login dengan penyedia identitas, atau mode aktif, saat proses login harus dipicu setelah tindakan oleh pengguna, seperti mengklik tombol checkout.
FedCM juga berfungsi sebagai sinyal kepercayaan untuk Storage Access API (SAA), yang memungkinkan penyematan mengakses cookie tingkat atas tanpa partisi setelah pengguna setuju untuk login dengan penyedia penyematan, tanpa memerlukan permintaan pengguna tambahan.
Solusi yang berfokus pada akses penyimpanan
API lain yang perlu dipertimbangkan adalah
Storage Access API (SAA).
Dengan SAA, pengguna akan diminta untuk mengizinkan penyematan payment-provider.example
agar dapat mengakses cookie tingkat atasnya sendiri. Jika pengguna menyetujui akses, formulir dapat
dirender seperti saat cookie pihak ketiga tersedia.
Sama seperti FedCM, pengguna harus menyetujui permintaan di setiap situs baru
tempat payment-provider.example
disematkan. Lihat demo
SAA untuk memahami cara kerja API.
Jika perintah SAA default tidak sesuai dengan kebutuhan Anda, pertimbangkan untuk menerapkan FedCM
untuk pengalaman yang lebih disesuaikan.
Mengurangi hambatan pengguna di sejumlah kecil situs terkait
Jika situs penjual dan penyedia pembayaran berasal dari perusahaan yang sama,
Anda dapat menggunakan
Related Website Sets (RWS)
API untuk mendeklarasikan hubungan antar-domain. Hal ini dapat membantu mengurangi
hambatan pengguna: misalnya, jika insurance.example
dan
payment-portal-insurance.example
berada di RWS yang sama,
payment-portal-insurance.example
akan otomatis mendapatkan akses ke cookie
tingkat teratas sendiri saat akses penyimpanan diminta dalam
penyematan payment-portal-insurance.example
.
Solusi eksperimental lainnya
API eksperimental lain yang mungkin berguna dalam skenario ini adalah Popin yang Dipartisi. API saat ini sedang dalam tahap pengembangan aktif.
Dengan Pop-up yang Dipartisi, pengguna dapat diminta untuk memasukkan kredensial mereka guna
login ke payment-provider.example
dalam pop-up yang dibuka oleh
merchant.example
. Penyimpanan akan
dipartisi
oleh pembuka merchant.example
. Dalam hal ini, penyematan payment-provider.example
akan memiliki akses ke nilai penyimpanan yang ditetapkan dalam pop-in. Dengan solusi
ini, pengguna harus login ke penyedia pembayaran di setiap situs.
Checkout link pembayaran
Beberapa penyedia pembayaran menawarkan layanan yang menghasilkan link pembayaran, yang merender halaman checkout kustom untuk situs penjual. Layanan link pembayaran dan portal pengguna untuk penyedia pembayaran sering diterapkan di domain yang berbeda, misalnya, payment-provider.example
dan payment-link.example
.
payment-link.example
menyematkan formulir checkout yang disediakan oleh
payment-provider.example
. Ini adalah variasi dari
pola formulir checkout tersemat.
FedCM,
SAA,
dan
RWS
juga merupakan opsi yang baik untuk dipertimbangkan dalam kasus ini.
Dasbor pembayaran
Beberapa aplikasi menampilkan dasbor transaksi kepada penggunanya di beberapa situs, yang memberikan tampilan terpusat tentang aktivitas keuangan mereka. Hal ini mengharuskan dasbor mengakses data khusus pengguna di beberapa domain.
Pertimbangkan domain berikut:
earnings.example
menyediakan dasbor pembayaran yang dapat disematkan di berbagai aplikasi web. Layanan ini menyimpan data penghasilan pengguna dan informasi sesi.catsitting.example
dandogsitting.example
adalah situs terpisah yang menyisipkan dasborearnings.example
.
Pengguna login ke akun earnings.example
-nya. Saat mengunjungi
catsitting.example
atau dogsitting.example
, mereka dapat melihat penghasilan mereka. Dasbor
earnings.example
tersemat mengandalkan cookie tingkat teratas dan menampilkan
informasi penghasilan yang dipersonalisasi pengguna.
Sama seperti contoh lainnya, penyematan earnings.example
tidak akan memiliki akses ke cookie tingkat teratas dengan cookie pihak ketiga dinonaktifkan.

Dasbor pihak pertama
Jika ketiga domain tersebut milik pihak yang sama, sebaiknya gunakan
SAA
bersama dengan
RWS.
Dengan SAA, earnings.example
dapat mendapatkan akses ke cookie tingkat teratas dengan izin
pengguna. Jika pihak ini menggunakan earnings.example
di empat domain atau kurang,
mendeklarasikan hubungan di antara domain tersebut dengan RWS dapat memberikan pengalaman
pengguna yang lebih lancar.
Jika pihak yang sama menyematkan widget di lebih dari lima domain, mereka tidak dapat mendeklarasikan hubungan antara semua situs penyematan dan domain widget, karena RWS hanya mendukung maksimal enam situs dalam satu set—satu situs utama dan lima situs terkait.
Distribusi dasbor yang diskalakan
Dalam kasus berikut, SAA dan RWS mungkin bukan solusi yang optimal:
- Anda mendistribusikan solusi dasbor untuk situs pihak ketiga.
- Anda memiliki lebih dari lima situs yang menyematkan widget dasbor.
Dalam hal ini, earnings.example
harus mempertimbangkan untuk menerapkan
FedCM agar dapat bertindak sebagai
penyedia identitas. Ini berarti pengguna harus login ke
dogsitting.example
dengan akun yang dikelola oleh earnings.example
.
FedCM menawarkan UI yang dapat disesuaikan yang dapat membantu menyampaikan dengan jelas kepada pengguna
informasi mana yang dibagikan. Dengan FedCM, dogsitting.example
dapat meminta
earnings.example
untuk membagikan
izin kustom,
misalnya, untuk mengakses data transaksi.
FedCM juga berfungsi sebagai
sinyal kepercayaan untuk Storage Access API,
dan penyematan earnings.example
akan diberi akses penyimpanan ke cookie
level teratas-nya sendiri tanpa perintah pengguna tambahan pada panggilan SAA API.
Setelan dasbor khusus situs
Jika data tidak perlu dibagikan di beberapa situs, pertimbangkan untuk mempartisi cookie dengan CHIPS. CHIPS dapat berguna untuk menyimpan preferensi khusus situs, misalnya, tata letak dasbor atau filter.
Kelola metode pembayaran
Alur umum lainnya adalah pengguna dapat melihat dan mengedit metode pembayaran mereka dalam penyematan tanpa keluar dari situs host.
Pertimbangkan alur berikut:
payments.example
menyediakan alat pengelolaan pembayaran yang dapat disematkan di situs. Layanan ini menyimpan data pembayaran pengguna dan informasi sesi.shop.example
adalah situs yang menyematkan alatpayments.example
untuk memungkinkan pengguna melihat, mengedit, atau memilih metode pembayaran pilihan yang terkait dengan akunshop.example
mereka.
Penyedia pembayaran yang menerapkan pengelolaan metode pembayaran juga harus
mempertimbangkan untuk menjadi penyedia identitas dengan
FedCM. Dengan
FedCM, pengguna akan dapat login ke Pihak Penerima (shop.example
)
menggunakan akun yang dikelola oleh Penyedia Identitas (payments.example
).
Dengan izin pengguna, FedCM memungkinkan berbagi data kustom antara pihak yang mengandalkan dan penyedia identitas. Manfaat utama menggunakan FedCM adalah UI dapat memberikan lebih banyak konteks kepada pengguna untuk pilihan mereka. Cookie ini juga berfungsi sebagai sinyal kepercayaan untuk Storage Access API, yang memungkinkan penyematan mengakses cookie tingkat atasnya.
Dengan menonaktifkan cookie pihak ketiga, penyematan payments.example
tidak akan memiliki
akses ke cookie level teratas. Dalam hal ini,
SAA
dapat membantu memastikan operasi yang tepat dengan meminta akses penyimpanan.
Terkadang informasi yang ditetapkan dalam sematan tidak perlu dibagikan di
situs penyematan lainnya. payments.example
mungkin hanya perlu menyimpan preferensi pengguna
yang berbeda untuk setiap situs penyematan tertentu. Dalam hal ini, pertimbangkan untuk mempartisi cookie menggunakan CHIPS. Dengan
CHIPS, cookie yang ditetapkan dalam payments.example
yang disematkan di shop.example
tidak akan
dapat diakses oleh payments.example
yang disematkan di another-shop.example
.
API eksperimental lain yang berpotensi dapat digunakan dalam alur penggunaan ini adalah
Popin yang Dipartisi.
Saat pengguna login ke payments.example
dalam pop-in yang dibuka oleh
shop.example
, penyimpanan akan dipartisi oleh pembuka, dan
penyematan payments.example
akan memiliki akses ke nilai penyimpanan yang ditetapkan dalam
pop-in. Namun, pendekatan ini mengharuskan pengguna memasukkan kredensial untuk login ke
penyedia pembayaran di setiap situs.
Deteksi penipuan
Sistem analisis risiko dapat menganalisis data yang disimpan dalam cookie untuk mengidentifikasi pola yang menyimpang dari norma. Misalnya, jika pengguna tiba-tiba mengubah alamat pengirimannya, dan melakukan beberapa pembelian besar menggunakan perangkat baru, skor potensi penipuan dapat ditingkatkan. Cookie deteksi penipuan biasanya adalah cookie pihak ketiga, yang ditetapkan di situs penjual oleh penyedia pembayaran atau widget layanan pencegahan penipuan.
Meskipun batasan cookie pihak ketiga tidak akan merusak sistem deteksi penipuan, batasan tersebut dapat menimbulkan hambatan tambahan bagi pengguna. Jika sistem tidak dapat memverifikasi dengan yakin bahwa pengguna adalah sah karena cookie diblokir, sistem mungkin memerlukan pemeriksaan tambahan, seperti menyelesaikan verifikasi identitas.
Untuk mendukung deteksi penipuan saat cookie pihak ketiga diblokir, pertimbangkan untuk mengintegrasikan Private State Tokens (PST) API ke dalam solusi deteksi penipuan Anda. Dengan PST, penyedia pembayaran dapat mendaftar sebagai penerbit token dan memberikan token kepada pengguna yang tidak bergantung pada cookie pihak ketiga. Token ini kemudian dapat ditukarkan di situs penjual untuk memeriksa apakah pengguna dapat dipercaya. Lihat dokumentasi developer PST untuk mengetahui detail penerapan.
Privacy Sandbox sedang bereksperimen dengan API anti-penipuan lainnya.
Tombol checkout yang dipersonalisasi
Tombol pembayaran (seperti Bayar dengan <metode pembayaran pilihan>) yang disematkan di situs penjual sering kali mengandalkan informasi lintas situs yang ditetapkan oleh penyedia pembayaran. Hal ini memungkinkan personalisasi, dan pengguna dapat menikmati checkout yang lancar dengan metode pembayaran pilihan mereka. Jika cookie pihak ketiga diblokir di browser pengguna, hal ini dapat memengaruhi rendering tombol pembayaran yang dipersonalisasi.
Meskipun SAA dapat mengizinkan akses penyimpanan, perintah yang diperlukan mungkin tidak memberikan pengalaman pengguna yang ideal.
Kami sedang mempelajari potensi solusi yang secara khusus menargetkan kasus penggunaan ini: Frame Pagar dengan akses data lokal yang tidak dipartisi. API saat ini dalam tahap pengembangan aktif, dan Anda dapat membentuk masa depannya. Coba sendiri dan berikan masukan.
Dapatkan bantuan
Laporkan setiap gangguan yang dialami ke goo.gle/report-3pc-broken. Anda juga dapat mengirimkan formulir masukan atau melaporkan masalah di GitHub di repositori dukungan developer Privacy Sandbox.