Memeriksa dampak perubahan cookie pihak ketiga pada alur kerja pembayaran Anda

Cookie pihak ketiga dapat diblokir oleh pembatasan browser, setelan pengguna, flag developer, atau kebijakan perusahaan.

Anda harus memastikan situs atau layanan Anda memberikan pengalaman yang baik bagi semua pengguna, terlepas dari tersedia atau tidaknya cookie pihak ketiga.

Halaman ini berisi informasi tentang perjalanan pengguna umum yang mungkin terpengaruh jika cookie pihak ketiga diblokir.

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 tersedianya lebih banyak solusi Privacy Sandbox.

Perjalanan Pengguna	API yang Direkomendasikan
Checkout lintas situs	FedCM Kumpulan Situs Terkait Storage Access API (SAA) sciencePopin yang Dipartisi
Dasbor pembayaran	FedCM Storage Access API (SAA) Related Website Sets CHIPS
Mengelola metode pembayaran	FedCM Storage Access API (SAA) Related Website Sets CHIPS sciencePopin yang Dipartisi
Deteksi penipuan	Token Status Pribadi
Tombol checkout yang dipersonalisasi	scienceFrame dengan Fence dengan akses data lokal yang tidak dipartisi

Menguji perjalanan pengguna terkait pembayaran

Cara terbaik untuk menguji apakah alur pengguna Anda terpengaruh oleh pembatasan cookie pihak ketiga adalah dengan mencobanya saat flag pengujian cookie pihak ketiga diaktifkan.

Untuk memastikan situs Anda berfungsi seperti yang diharapkan, uji alur berikut dengan cookie pihak ketiga 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. Pastikan pengguna dapat:
  • Akses dasbor.
  • Lihat semua pembayaran seperti yang diharapkan.
  • Beralih tanpa error di antara berbagai bagian dasbor (misalnya, histori transaksi, detail pembayaran).
• Mengelola metode pembayaran: Uji apakah widget pengelolaan metode pembayaran berfungsi seperti yang diharapkan. Dengan cookie pihak ketiga diblokir, uji bahwa:
  • Menambahkan atau menghapus metode pembayaran berfungsi seperti yang diharapkan.
  • Pembayaran dengan metode pembayaran yang disimpan sebelumnya tidak terpengaruh.
• Deteksi penipuan: Bandingkan cara kerja solusi deteksi penipuan Anda dengan dan tanpa cookie pihak ketiga.
  • Apakah memblokir cookie pihak ketiga akan menimbulkan langkah tambahan, sehingga menyebabkan gesekan tambahan bagi pengguna?
  • Apakah sistem ini masih dapat mendeteksi pola mencurigakan saat cookie pihak ketiga diblokir di browser?
• Tombol checkout yang dipersonalisasi: Uji apakah tombol pembayaran dirender dengan benar saat cookie pihak ketiga 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 melakukan autentikasi ulang. Perjalanan pengguna ini mungkin terpengaruh bagi mereka yang memilih untuk menjelajah tanpa cookie pihak ketiga.

Formulir checkout yang disematkan

Pertimbangkan domain berikut:

• payment-provider.example menyediakan layanan pembayaran ke situs penjual, dan menyimpan data pembayaran dan sesi 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 tersedianya cookie pihak ketiga, formulir checkout payment-provider.example yang disematkan di merchant.example akan memiliki akses ke cookie sesi tingkat atasnya sendiri yang ditetapkan di payment-provider.example dalam konteks tingkat atas. Namun, jika cookie pihak ketiga diblokir, sematan tidak akan memiliki akses ke cookie level teratasnya sendiri.

Solusi yang dapat disesuaikan dengan FedCM

payment-provider.example harus mempertimbangkan untuk menerapkan FedCM untuk 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 berbagi data kustom antara Pihak Tepercaya (merchant.example) dan Penyedia Identitas (payment-provider.example). Pihak tepercaya dapat memilih untuk mendukung satu atau beberapa penyedia identitas, dan UI FedCM hanya akan ditampilkan secara kondisional.

Bergantung pada kebutuhan, developer dapat memilih antara mode pasif agar dialog 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 sematan mengakses cookie tanpa partisi tingkat teratasnya setelah pengguna setuju untuk login dengan penyedia sematan, tanpa memerlukan dialog 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 sematan payment-provider.example 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 guna mendapatkan pengalaman yang lebih disesuaikan.

Mengurangi hambatan pengguna di sejumlah kecil situs terkait

Jika situs penjual dan penyedia pembayaran termasuk dalam perusahaan yang sama, Anda dapat menggunakan API Set Situs Terkait (RWS) untuk menyatakan hubungan antar-domain. Hal ini dapat membantu mengurangi gesekan 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 teratasnya sendiri saat akses penyimpanan diminta dalam sematan payment-portal-insurance.example.

Solusi eksperimental lainnya

API eksperimental lain yang mungkin berguna dalam skenario ini adalah Partitioned Popins. API saat ini dalam tahap pengembangan aktif.

Dengan Popin yang Dipartisi, pengguna dapat diminta untuk memasukkan kredensial mereka untuk login ke payment-provider.example dalam popin yang dibuka oleh merchant.example. Penyimpanan akan dipartisi oleh pembuka merchant.example. Dalam hal ini, sematan payment-provider.example akan memiliki akses ke nilai penyimpanan yang ditetapkan dalam popin. Dengan solusi ini, pengguna harus login ke penyedia pembayaran di setiap situs.

Checkout link pembayaran

Beberapa penyedia pembayaran menawarkan layanan yang membuat 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 pola formulir checkout sematan. FedCM, SAA dan RWS juga merupakan opsi yang baik untuk dipertimbangkan dalam kasus ini.

Dasbor pembayaran

Beberapa aplikasi menampilkan dasbor transaksi kepada pengguna di beberapa situs, sehingga memberikan tampilan terpusat dari 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 sama-sama menyematkan dasbor earnings.example.

Pengguna login ke akun earnings.example miliknya. Saat mengunjungi catsitting.example atau dogsitting.example, mereka dapat melihat penghasilan mereka. Dasbor earnings.example yang disematkan mengandalkan cookie tingkat teratas dan menampilkan informasi penghasilan pribadi pengguna.

Sama seperti contoh lainnya, sematan earnings.example tidak akan memiliki akses ke cookie tingkat teratasnya jika cookie pihak ketiga dinonaktifkan.

Dasbor pihak pertama

Jika ketiga domain tersebut dimiliki oleh pihak yang sama, pertimbangkan untuk menggunakan SAA bersama dengan RWS. Dengan SAA, earnings.example dapat memperoleh akses ke cookie tingkat atasnya dengan izin pengguna. Jika pihak ini menggunakan earnings.example di empat domain atau kurang, menyatakan 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 menyatakan hubungan antara semua situs penyematan dan domain widget, karena RWS hanya mendukung hingga 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 untuk bertindak sebagai penyedia identitas. Artinya, pengguna harus login ke dogsitting.example dengan akun yang dikelola oleh earnings.example.

FedCM menawarkan UI yang dapat disesuaikan yang dapat membantu mengomunikasikan dengan jelas kepada pengguna informasi mana yang sedang 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 sematan earnings.example akan diberi akses penyimpanan ke cookie tingkat teratasnya 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 Anda 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 sematan tanpa meninggalkan situs induk.

Pertimbangkan alur berikut:

• payments.example menyediakan alat pengelolaan pembayaran yang dapat disematkan di situs. Layanan ini menyimpan data pembayaran dan informasi sesi pengguna.
• 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 Tepercaya (shop.example) menggunakan akun yang dikelola oleh Penyedia Identitas (payments.example).

Dengan izin pengguna, FedCM memungkinkan berbagi data kustom antara pihak tepercaya dan penyedia identitas. Manfaat utama menggunakan FedCM adalah UI dapat memberikan lebih banyak konteks kepada pengguna untuk pilihan mereka. Selain itu, iframe juga berfungsi sebagai sinyal kepercayaan untuk Storage Access API, yang memungkinkan sematan mengakses cookie tingkat atasnya.

Dengan cookie pihak ketiga dinonaktifkan, sematan payments.example tidak akan memiliki akses ke cookie tingkat atasnya. Dalam hal ini, SAA dapat membantu memastikan pengoperasian yang tepat dengan meminta akses penyimpanan.

Terkadang, set informasi 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 memartisi cookie menggunakan CHIPS. Dengan CHIPS, cookie yang ditetapkan dalam payments.example yang disematkan di shop.example tidak dapat diakses oleh payments.example yang disematkan di another-shop.example.

API eksperimental lain yang berpotensi digunakan dalam alur pengguna ini adalah Partitioned Popins. Saat pengguna login ke payments.example dalam popin yang dibuka oleh shop.example, penyimpanan akan dipartisi oleh pembuka, dan sematan payments.example akan memiliki akses ke nilai penyimpanan yang ditetapkan dalam popin. 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 pengiriman dan melakukan beberapa pembelian besar menggunakan perangkat baru, skor potensi penipuan dapat meningkat. Cookie deteksi penipuan biasanya merupakan cookie pihak ketiga, yang ditetapkan di situs penjual oleh penyedia pembayaran atau widget layanan pencegahan penipuan.

Meskipun pembatasan cookie pihak ketiga tidak akan merusak sistem deteksi penipuan, pembatasan ini dapat menimbulkan hambatan tambahan bagi pengguna. Jika sistem tidak dapat memverifikasi dengan yakin bahwa pengguna 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 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 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 menghasilkan pengalaman pengguna yang ideal.

Kami sedang mengeksplorasi potensi solusi yang secara khusus menargetkan kasus penggunaan ini: Fenced Frames 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.

Bantuan dan masukan

Jika ada pertanyaan atau masukan tentang perjalanan pengguna atau API yang dijelaskan dalam panduan ini, Anda dapat membagikan masukan Anda.