Memasang plugin melawan menulis integrasi sendiri: tiga kelas kesalahan yang sudah selesai sebelum baris pertama ditulis, dua nilai yang menentukan segalanya, dan bentuk penjualan yang memaksa jalur panjang

Jawaban singkatnya lebih dulu: toko WooCommerce biasa yang menjual dalam Rupiah lewat checkout bawaan sebaiknya memasang plugin, dan jaraknya tidak dekat. Integrasi sendiri bukan pilihan yang lebih serius, melainkan pilihan yang dipaksa oleh bentuk penjualan tertentu.

Yang layak dibaca terus adalah alasannya, karena alasan yang benar bukan hemat waktu. Menulis integrasi sendiri berarti mengambil alih tiga kelas kesalahan yang sudah selesai di dalam plugin, dan ketiganya adalah kesalahan yang akibatnya uang, bukan tampilan. Bentuk pemasangan pluginnya sendiri sudah diterbitkan di dokumentasi plugin WooCommerce; yang dibahas di sini adalah memilih jalurnya.

Yang sebenarnya berpindah tangan saat plugin dipasang

Plugin bukan pembungkus tipis di atas satu panggilan API. Tiga perilaku di dalamnya adalah jawaban atas tiga kesalahan yang berulang pada integrasi yang ditulis sendiri:

• Tagihan ganda dari satu pesanan. Setiap pesanan membuat tagihan dengan header Idempotency-Key yang diturunkan dari pesanan beserta isi permintaannya, sehingga tombol bayar yang terklik dua kali tidak pernah menagih dua kali. Perlu diingat bahwa hanya header itu yang menggandengkan dua permintaan menjadi satu pembayaran; nomor pesanan yang dikirim sebagai label tidak melakukannya. Sebabnya dibahas di idempotency untuk pembayaran.
• Pesanan yang diubah oleh kiriman yang belum terbukti. Webhook diverifikasi dengan tanda tangan Kasera-Signature-V1, HMAC berikut timestamp dengan toleransi lima menit, sebelum pesanan disentuh. Urutannya yang penting: memverifikasi sesudah mengubah pesanan tidak menghasilkan apa pun.
• Nominal yang tidak cocok. Kiriman yang nominalnya berbeda dari total pesanan membuat pesanan ditahan pada status on hold, bukan diselesaikan. Integrasi yang ditulis sendiri sering melewatkan pemeriksaan ini sepenuhnya, dan akibatnya adalah pesanan yang dikirim atas pembayaran yang kurang.

Ketiganya bisa ditulis sendiri. Yang jarang dihitung adalah bahwa ketiganya harus ditulis sendiri dengan benar pada percobaan pertama, karena kesalahannya tidak muncul saat pengujian melainkan saat penjualan sedang ramai.

Yang tidak bisa diubah dari dalam plugin

Sisi sebaliknya perlu sama jelasnya. Pengaturan plugin hanya memuat dua nilai wajib, yaitu API key dan webhook signing secret, ditambah satu kolom opsional berisi kode metode yang dipisah koma untuk membatasi apa yang ditawarkan di checkout. Kosongkan kolom itu dan yang muncul adalah semua metode yang aktif pada akun tersebut, sesuai daftar metode pembayaran.

Konsekuensinya: halaman pembayarannya adalah halaman checkout Kasera Pay, dan urutan layar yang dilihat pembeli tidak diatur dari dalam WooCommerce. Untuk sebagian besar toko itu keuntungan, karena halaman itu ikut terpelihara tanpa pekerjaan tambahan. Untuk toko yang memang menjual pengalaman checkout yang dirancang khusus, itu batas yang nyata.

Dua hal lagi yang jujur perlu masuk hitungan. Pemasangan dan pembaruan dilakukan dengan mengunggah berkas zip dari halaman rilis, jadi naik versi adalah langkah yang dikerjakan seseorang dan bukan sesuatu yang terjadi sendiri. Dan syarat lingkungannya menggugurkan lebih dulu: WordPress 6.0 ke atas, WooCommerce 8.0 ke atas, PHP 8.1 ke atas, serta mata uang toko IDR. Syarat terakhir itu yang paling sering membingungkan, karena pada mata uang lain metode pembayarannya menyembunyikan diri tanpa pesan galat apa pun.

Empat bentuk penjualan yang benar-benar memaksa integrasi sendiri

Pertanyaan yang memisahkan keduanya bukan seberapa mampu tim menulis kode, melainkan apakah pesanan WooCommerce sanggup memegang penjualannya. Kalau jawabannya tidak, plugin tidak akan pernah cukup berapa pun pengaturannya:

• Pembayaran yang lahir sebelum ada pesanan. Formulir pemesanan jasa, pendaftaran acara, atau penawaran yang ditagih sebelum keranjang terbentuk. Tidak ada pesanan yang bisa dipegang plugin.
• Penjualan di luar WooCommerce. Tagihan yang terbit dari aplikasi internal, dari percakapan WhatsApp, atau dari sistem kasir di toko fisik, sementara WooCommerce hanya memegang sebagian penjualan.
• Storefront headless. WooCommerce dipakai sebagai backend saja dan checkout-nya dibangun terpisah, sehingga hook checkout yang dipakai plugin tidak pernah dilewati.
• Penagihan berulang yang tidak berbentuk pesanan. Iuran, langganan, atau termin pekerjaan yang jadwalnya hidup di sistem lain.

Perlu dicatat bahwa yang tidak masuk daftar ini adalah alasan yang paling sering diucapkan, yaitu keinginan mengendalikan tampilan. Itu alasan yang mahal untuk memindahkan tiga kelas kesalahan di atas ke pundak sendiri.

Siapa yang memegang webhook, dan apa artinya saat ada yang rusak

Perbedaan yang paling terasa setelah berbulan-bulan berjalan adalah siapa yang dipanggil saat pesanan tidak berubah. Dengan plugin, penanganan webhook ada di dalamnya, dan pemeriksaannya berhenti pada dua nilai: URL webhook di dashboard dan signing secret di pengaturan plugin. Dengan integrasi sendiri, yang dipegang adalah endpoint, verifikasi tanda tangannya, pencegahan pemrosesan ganda atas satu event, dan jawaban 2xx yang tepat waktu. Rinciannya ada di dokumentasi webhook.

Kabar baiknya berlaku untuk kedua jalur: kiriman yang gagal dicoba ulang berkali-kali selama lebih dari satu hari penuh, sehingga endpoint yang mati semalam tidak kehilangan kabar pembayarannya. Yang berbeda hanyalah siapa yang harus memperbaikinya.

Susunan campuran, yang biasanya benar untuk toko yang tumbuh

Kedua jalur berjalan berdampingan pada satu akun, dan ini yang paling sering terlewat. Toko yang menjual lewat WooCommerce sekaligus menagih lewat chat memasang plugin untuk tokonya dan memakai API atau tautan pembayaran untuk sisanya. Kunci API-nya sama, dashboard dan pencairannya sama, dan seluruh pembayaran tampil pada satu daftar. Tidak ada migrasi yang perlu direncanakan, karena menambah jalur kedua bukan mengganti jalur pertama.

Urutan yang biasanya paling murah: pasang plugin lebih dulu, jalankan dalam mode tes sampai satu pesanan berpindah sendiri ke Processing, lalu baru pertimbangkan integrasi sendiri untuk penjualan yang memang tidak muat di dalam pesanan WooCommerce. Perpindahan dari menagih dengan tangan ke integrasi, beserta bentuk integrasi terkecil yang sudah berguna, dibahas terpisah di panduan dari tautan manual ke integrasi API.

Ringkasnya

Plugin WooCommerce Kasera Pay menang untuk toko WooCommerce biasa dalam Rupiah, bukan karena lebih cepat dipasang melainkan karena tiga kelas kesalahan yang akibatnya uang sudah tertutup di dalamnya. Harganya adalah pengaturan yang sengaja sempit, halaman pembayaran yang tidak diatur dari dalam WooCommerce, dan pembaruan yang dikerjakan seseorang. Integrasi sendiri dipilih ketika pesanan WooCommerce tidak sanggup memegang penjualannya, bukan ketika tampilannya ingin diatur. Dan karena keduanya hidup pada satu akun yang sama, keputusan ini tidak perlu diambil untuk selamanya.

Pertanyaan yang sering muncul