Memeriksa dampak perubahan cookie pihak ketiga pada alur kerja pembayaran Anda

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.

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 oleh payment-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.

Diagram menunjukkan interaksi dengan situs penjual (merchant.example) yang menggunakan widget pembayaran dari penyedia pihak ketiga (payment-provider.example). Jika cookie pihak ketiga diblokir, widget tidak dapat mengakses cookie tingkat teratas, yang berpotensi mengganggu pengalaman pengguna.
Jika cookie pihak ketiga dinonaktifkan, widget `payment-provider.example` tidak akan memiliki akses ke cookie sesi pengguna yang ditetapkan dalam konteks tingkat teratas di `payment-provider.example`.

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.

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 dan dogsitting.example adalah situs terpisah yang menyisipkan dasbor earnings.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.

Diagram yang mengilustrasikan skenario saat informasi penghasilan pengguna, yang dihosting di earnings.example,
      ditampilkan di dasbor tersemat di dogsitting.example.  Jika cookie pihak ketiga diblokir,
      dasbor tersemat tidak dapat mengakses cookie tingkat teratas, sehingga mencegah tampilan data penghasilan yang dipersonalisasi pengguna.
Jika cookie pihak ketiga dinonaktifkan, widget `earnings.example` yang disematkan di `dogsitting.example` tidak akan memiliki akses ke cookie yang ditetapkan dalam konteks tingkat teratas di `earnings.example`.

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 alat payments.example untuk memungkinkan pengguna melihat, mengedit, atau memilih metode pembayaran pilihan yang terkait dengan akun shop.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.