{"content_id":"dtvo1yuy0p","slug":"ai-payment-feature-7-core-decisions","locale":"id","schema_type":"TechArticle","category":"how_to","category_name":"Panduan","title":"7 hal yang perlu ditentukan terlebih dahulu saat membuat fitur pembayaran dengan AI","summary":"AI dapat membuat kode pembayaran dengan cepat, tetapi keamanan fitur pembayaran bergantung pada perancangan kebijakan seperti status pesanan, batas waktu refund, refund parsial, dan pencegahan pembayaran ganda. Khususnya untuk layanan e-commerce Korea, hak pembatalan pembelian, bunga keterlambatan refund, pemberitahuan aturan refund, dan penghindaran dark pattern harus tercermin dengan jelas dalam persyaratan pengembangan.","author":{"name":"injoys","url":"https://injoys.com/ko/about"},"key_points":["Fitur pembayaran bukan sekadar fungsi otorisasi kartu, melainkan sistem operasional yang menghubungkan pesanan, settlement, refund, layanan pelanggan, dan pemberitahuan hukum.","Status pesanan harus didefinisikan agar pelanggan dan operator memahaminya dengan makna yang sama, seperti menunggu pembayaran, pembayaran selesai, dibatalkan, refund sedang diproses, dan refund selesai.","Dalam e-commerce Korea, umumnya perlu mempertimbangkan periode hak pembatalan pembelian konsumen, batas waktu pemrosesan refund oleh pelaku usaha, dan aturan bunga keterlambatan.","Pencegahan pembayaran ganda tidak cukup hanya dengan menonaktifkan tombol; diperlukan kunci idempotensi di sisi server, penguncian pesanan, dan pemeriksaan duplikasi otorisasi pembayaran.","Desain yang menyembunyikan aturan refund dan cara pembatalan atau membuat pembatalan langganan menjadi sulit dapat merusak kepercayaan pelanggan dan meningkatkan risiko regulasi dark pattern."],"content_markdown":"## Ringkasan Inti\n\nPrompt paling berbahaya saat menyerahkan fungsi pembayaran kepada AI adalah meminta secara sederhana, “tambahkan pembayaran.” Pembayaran bukan sekadar kode untuk menerima uang, melainkan sistem operasional, akuntansi, dan dukungan pelanggan yang bertanggung jawab atas aliran uang.\n\nSecara teknis, AI dapat dengan cepat mengimplementasikan integrasi jendela pembayaran, pemanggilan API persetujuan, penerimaan webhook, dan penyimpanan pesanan. Namun, jika kebijakan berikut belum ditentukan, dalam layanan nyata dapat muncul masalah seperti pesanan hantu, pembayaran ganda, keterlambatan pengembalian dana, lonjakan pusat layanan pelanggan, dan kelalaian pemberitahuan hukum.\n\n| Area keputusan | Pertanyaan yang harus ditentukan terlebih dahulu | Risiko jika gagal |\n|---|---|---|\n| Status pesanan | Status apa saja yang dilalui pesanan secara berurutan? | Terjadi pesanan hantu: pembayaran berhasil tetapi pesanan tidak ada |\n| Batas waktu pengembalian dana | Bagaimana mencerminkan batas waktu pembatalan pembelian dan pemrosesan pengembalian dana? | Pelanggaran batas waktu hukum, bunga keterlambatan, risiko sengketa |\n| Pengembalian dana sebagian | Bagaimana menghitung retur sebagian produk, kupon, dan ongkos kirim? | Operator harus menghitung manual setiap kali, pelanggan tidak percaya |\n| Pembayaran ganda | Bagaimana mencegah pembayaran tercatat dua kali untuk pesanan yang sama? | Keluhan pelanggan berdasarkan tagihan kartu, kepercayaan menurun |\n| Panduan kegagalan | Bagaimana menjelaskan limit terlampaui, saldo tidak cukup, dan kegagalan autentikasi? | Tingkat konversi percobaan ulang menurun, pertanyaan yang tidak perlu meningkat |\n| Riwayat pembayaran | Di mana pelanggan memeriksa status pembayaran dan pengembalian dana? | Pertanyaan ke pusat layanan pelanggan meningkat, status tidak transparan |\n| Pemberitahuan pengembalian dana | Di mana menempatkan aturan pengembalian dana dan tombol pembatalan? | Kontroversi dark pattern, risiko regulasi |\n\n## 1. Desain status pesanan: status adalah bahasa operasional\n\nSaat membuat fungsi pembayaran, status pesanan tidak boleh hanya berupa satu status “pesanan selesai.” Dalam praktiknya, pesanan melalui berbagai tahap seperti percobaan pembayaran, persetujuan, pembatalan, pengembalian dana, kegagalan, dan kedaluwarsa.\n\n### Contoh status yang direkomendasikan\n\n| Contoh kode status | Status yang terlihat oleh pelanggan | Makna |\n|---|---|---|\n| `payment_pending` | Menunggu pembayaran | Pesanan sudah dibuat tetapi pembayaran belum selesai |\n| `paid` | Pembayaran selesai | Persetujuan pembayaran selesai dan pesanan valid |\n| `payment_failed` | Pembayaran gagal | Percobaan pembayaran gagal dan perlu ditentukan apakah bisa dicoba ulang |\n| `cancel_requested` | Pembatalan diminta | Pelanggan mengajukan pembatalan dan sedang menunggu pemrosesan |\n| `cancelled` | Pembatalan selesai | Pembatalan pesanan sebelum pembayaran atau pembatalan persetujuan selesai |\n| `refund_requested` | Pengembalian dana diminta | Permohonan pengembalian dana setelah pembayaran diterima |\n| `refund_processing` | Pengembalian dana diproses | Sedang memproses persetujuan pengembalian dana atau pengembalian ke metode pembayaran |\n| `partially_refunded` | Pengembalian dana sebagian selesai | Hanya sebagian dari nilai pesanan yang dikembalikan |\n| `refunded` | Pengembalian dana selesai | Pemrosesan pengembalian dana selesai |\n| `expired` | Pesanan kedaluwarsa | Waktu tunggu pembayaran berlalu dan pesanan menjadi tidak valid |\n\n### Prinsip desain status\n\n- Status pesanan dan status pembayaran tidak dianggap sepenuhnya sama. Pesanan bisa ada tetapi pembayaran gagal, dan pembayaran bisa disetujui tetapi penyimpanan pesanan gagal.\n- Setiap perubahan status harus menyimpan waktu kejadian, pemroses, alasan, pengenal transaksi pembayaran, dan pengenal transaksi pengembalian dana.\n- Layar pelanggan, layar administrator, dan frasa respons pusat layanan pelanggan harus menggunakan definisi status yang sama.\n- Transisi status dirancang satu arah, dan pemulihan pengecualian diproses dengan mencatatnya melalui hak administrator terpisah.\n\n## 2. Pembatalan pembelian dan batas waktu pengembalian dana menurut hukum: bukan kebijakan, melainkan persyaratan hukum\n\nJika menjalankan e-commerce yang ditujukan kepada konsumen di Korea, perlu mempertimbangkan Undang-Undang Perlindungan Konsumen dalam Perdagangan Elektronik dan sebagainya. Secara umum, konsumen dapat membatalkan pembelian dalam periode tertentu, dan pelaku usaha harus mengembalikan pembayaran dalam batas waktu yang ditentukan setelah permintaan pengembalian dana atau prosedur pengembalian barang.\n\nStandar yang sangat penting dalam praktik adalah sebagai berikut.\n\n- Pada prinsipnya, konsumen dapat membatalkan pembelian dalam 7 hari sejak tanggal standar yang ditentukan hukum, seperti hari penerimaan barang dan sebagainya.\n- Pelaku usaha harus mengembalikan pembayaran dalam batas waktu hukum setelah alasan pengembalian dana terjadi, dan jika terlambat, dapat timbul masalah kompensasi keterlambatan atau bunga keterlambatan.\n- Konten digital, produk pesanan khusus, produk yang nilainya menurun secara signifikan karena penggunaan, dan sebagainya dapat menjadi pengecualian, tetapi untuk menerapkan pengecualian, persyaratan seperti pemberitahuan dan persetujuan sebelumnya harus diperiksa dengan hati-hati.\n- Penerapan sebenarnya dapat berbeda tergantung jenis produk, metode kontrak, pemberitahuan yang diberikan kepada konsumen, dan apakah penggunaan sudah dimulai, sehingga diperlukan tinjauan hukum.\n\n### Cara mengubahnya menjadi persyaratan pengembangan\n\nStandar hukum tidak cukup jika hanya ditulis dalam klausul syarat dan ketentuan. Standar tersebut juga harus diubah menjadi persyaratan sistem.\n\n| Persyaratan hukum·kebijakan | Persyaratan sistem |\n|---|---|\n| Menentukan apakah pembatalan pembelian dapat dilakukan dalam 7 hari | Menghitung otomatis periode pengembalian dana berdasarkan tanggal penerimaan pesanan atau tanggal penyediaan layanan |\n| Perlu memproses pengembalian dana dalam 3 hari kerja | Menampilkan tanggal permohonan pengembalian dana dan tenggat pemrosesan di layar administrator |\n| Risiko keterlambatan pengembalian dana | Menampilkan notifikasi mendekati tenggat dan melewati tenggat |\n| Perlu pemberitahuan untuk produk pengecualian | Menampilkan dengan jelas sebelum pembayaran bahwa produk memiliki pembatasan pengembalian dana dan menyimpan log persetujuan |\n| Perlu penanganan sengketa | Menyimpan versi syarat dan ketentuan, waktu pemberitahuan, waktu persetujuan, IP pelanggan atau log akun |\n\n## 3. Aturan pengembalian dana sebagian: kupon, ongkos kirim, dan pajak harus ditentukan terlebih dahulu\n\nPengembalian dana sebagian jauh lebih kompleks daripada pembatalan penuh. Jika beberapa produk dipesan sekaligus lalu hanya sebagian yang dikembalikan, harus diputuskan bagaimana membagi diskon dan ongkos kirim yang semula diterapkan.\n\n### Hal yang wajib ditentukan\n\n- Bagaimana mengalokasikan jumlah pembayaran per produk\n- Apakah kupon untuk seluruh pesanan akan dialokasikan secara proporsional per produk\n- Apakah kupon untuk produk tertentu hanya diterapkan pada produk tersebut\n- Apakah ongkos kirim akan dikurangkan ketika syarat gratis ongkir tidak lagi terpenuhi\n- Bagaimana membedakan ongkos kirim retur karena perubahan pikiran dan ongkos kirim retur karena cacat produk\n- Dalam urutan apa pembayaran dengan poin, saldo, dan kartu hadiah akan dikembalikan\n- Bagaimana mengubah faktur pajak, kuitansi tunai, dan tampilan kuitansi setelah pengembalian dana sebagian\n\n### Contoh perhitungan pengembalian dana sebagian\n\n| Item | Jumlah |\n|---|---:|\n| Produk A | 30,000원 |\n| Produk B | 70,000원 |\n| Kupon seluruh pesanan | -10,000원 |\n| Jumlah pembayaran aktual | 90,000원 |\n\nJika kupon dialokasikan berdasarkan proporsi nilai produk, diskon 3,000원 dialokasikan ke produk A dan 7,000원 ke produk B. Dalam hal ini, jika hanya produk A yang dikembalikan, jumlah dasar pengembalian dana bukan 30,000원, melainkan 27,000원. Jika ada syarat gratis ongkir, ongkos kirim retur, dan pembatasan pengembalian berdasarkan metode pembayaran, jumlah akhir pengembalian dana dapat berubah lagi.\n\nTidak ada satu jawaban benar. Yang penting adalah menetapkan aturan yang konsisten sebelumnya dan memberi pemberitahuan agar pelanggan dapat memahaminya sebelum pembayaran atau sebelum mengajukan pengembalian dana.\n\n## 4. Pencegahan pembayaran ganda: menonaktifkan tombol saja tidak cukup\n\nPembayaran ganda adalah insiden pembayaran yang paling cepat diketahui pelanggan. Pelanggan melihat pesan persetujuan kartu dan tagihan kartu lebih dahulu daripada status pesanan internal layanan. Jika pesanan yang sama dibayar dua kali, kepercayaan akan turun drastis.\n\n### Penyebab terjadinya\n\n- Pelanggan mengklik tombol pembayaran berulang kali\n- Pelanggan menyegarkan halaman atau menekan tombol kembali segera setelah pembayaran\n- Permintaan yang sama dikirim ulang karena keterlambatan jaringan seluler\n- Respons persetujuan pembayaran berhasil tetapi penyimpanan di server layanan gagal\n- Webhook dan redirect klien mengubah status pesanan secara bersamaan\n\n### Desain pertahanan\n\n| Mekanisme pertahanan | Penjelasan |\n|---|---|\n| Penguncian tombol klien | Mencegah klik ulang setelah tombol pembayaran diklik, tetapi hanya digunakan sebagai sarana pendukung |\n| Penguncian pesanan di sisi server | Memastikan permintaan persetujuan pembayaran tidak dijalankan bersamaan untuk ID pesanan yang sama |\n| Kunci idempotensi | Menggunakan pengenal agar meski permintaan pembayaran yang sama dikirim beberapa kali, hasil hanya dibuat satu kali |\n| Nomor transaksi unik | Mencegah penyimpanan duplikat nomor pesanan dan nomor transaksi pembayaran dengan constraint database |\n| Verifikasi berbasis status | Mencegah permintaan persetujuan tambahan untuk pesanan yang sudah `paid` |\n| Pemrosesan duplikat webhook | Memastikan perubahan status hanya terjadi satu kali meski event webhook yang sama datang beberapa kali |\n\nSaat meminta AI menulis kode pembayaran, sebaiknya nyatakan bukan “cegah klik duplikat,” melainkan “untuk pesanan yang sama, persetujuan pembayaran dan pemrosesan pembayaran selesai harus berjalan secara idempoten.”\n\n## 5. Teks panduan kegagalan pembayaran: kegagalan bukan insiden, melainkan alur normal\n\nKegagalan pembayaran adalah situasi normal yang terjadi setiap hari. Limit terlampaui, saldo tidak cukup, autentikasi kartu gagal, kesalahan kata sandi, autentikasi 3D Secure gagal, aplikasi pembayaran praktis tidak merespons, dan kesalahan jaringan semuanya adalah kasus umum.\n\nPanduan yang buruk adalah teks yang berhenti pada “Terjadi kesalahan.” Pelanggan tidak tahu apakah pembayaran sudah berhasil, apakah boleh menekan lagi, atau apakah pesanan akan hilang.\n\n### Contoh teks panduan\n\n| Situasi | Panduan yang direkomendasikan |\n|---|---|\n| Saldo tidak cukup | Pembayaran tidak selesai karena saldo metode pembayaran tidak mencukupi. Silakan pilih metode pembayaran lain atau periksa saldo lalu coba lagi. |\n| Limit terlampaui | Pembayaran gagal karena melebihi limit kartu atau limit pembayaran sekali transaksi. Silakan periksa limit di aplikasi penerbit kartu atau bayar dengan kartu lain. |\n| Autentikasi gagal | Pesanan tetap dalam status menunggu pembayaran karena autentikasi pembayaran belum selesai. Anda dapat membayar lagi dalam 30 menit. |\n| Kesalahan jaringan | Konfirmasi hasil pembayaran sedang tertunda. Untuk mencegah pembayaran ganda, silakan periksa riwayat pembayaran setelah beberapa saat. |\n| Pesanan kedaluwarsa | Pesanan kedaluwarsa karena waktu tunggu pembayaran telah berlalu. Silakan pilih produk lagi dan lakukan pemesanan. |\n\n### Elemen inti panduan kegagalan\n\n- Jelaskan dengan jelas apakah pembayaran benar-benar belum selesai.\n- Beri tahu berapa lama pesanan dipertahankan.\n- Pandu apakah pelanggan boleh mencoba lagi atau harus menggunakan metode pembayaran lain.\n- Tampilkan nomor pesanan yang diperlukan saat menghubungi pusat layanan pelanggan.\n- Jika hasil pembayaran tidak pasti, jangan langsung mendorong pembayaran ulang; sediakan status sedang dikonfirmasi.\n\n## 6. Halaman riwayat pembayaran: layar inti untuk mengurangi pusat layanan pelanggan\n\nJika tidak ada halaman riwayat pembayaran, pelanggan akan menghubungi pusat layanan pelanggan untuk memeriksa status pembayaran, pembatalan, dan pengembalian dana. Riwayat pembayaran bukan sekadar layar kuitansi, melainkan perangkat kepercayaan bagi pelanggan untuk memeriksa status uang mereka saat ini.\n\n### Informasi yang harus disertakan di halaman riwayat pembayaran\n\n- Nomor pesanan\n- Tanggal dan waktu pesanan serta tanggal dan waktu pembayaran\n- Nama produk, jumlah, opsi\n- Metode pembayaran dan nomor persetujuan atau pengenal transaksi\n- Nilai produk, diskon, ongkos kirim, jumlah poin yang digunakan, jumlah akhir pembayaran\n- Status pesanan saat ini dan status pengembalian dana\n- Tanggal permohonan pengembalian dana, tanggal persetujuan pengembalian dana, perkiraan tanggal penyelesaian pengembalian dana\n- Apakah pembatalan atau pengembalian dana tersedia\n- Tautan untuk memeriksa kuitansi, rincian transaksi, kuitansi tunai\n- Informasi yang diperlukan saat menghubungi pusat layanan pelanggan\n\n### Koneksi dengan layar operator\n\nLayar pelanggan dan layar administrator harus melihat data yang sama. Jika pelanggan melihat “pengembalian dana diproses” tetapi layar administrator menampilkan “pemrosesan selesai,” respons pusat layanan pelanggan akan kacau. Nama status boleh diekspresikan berbeda, tetapi kode status internal dan aturan transisinya harus satu.\n\n## 7. Lokasi pemberitahuan aturan pengembalian dana: jika disembunyikan, itu bukan kebijakan melainkan risiko\n\nAturan pengembalian dana tidak cukup jika hanya diletakkan di sudut halaman syarat dan ketentuan. Pada layar tempat pelanggan mengambil keputusan pembayaran, periode pengembalian dana, syarat pembatasan pengembalian dana, dan cara pembatalan harus dapat diperiksa dengan mudah.\n\n### Lokasi pemberitahuan yang baik\n\n- Di dekat harga atau tombol beli pada halaman detail produk\n- Layar keranjang atau formulir pesanan\n- Area persetujuan syarat dan ketentuan serta aturan pengembalian dana tepat di atas tombol pembayaran\n- Halaman pembayaran selesai\n- Layar detail pesanan di my page\n- Layar permohonan pengembalian dana\n\n### Desain yang harus dihindari\n\n- Desain yang memungkinkan pendaftaran dan pembayaran dilakukan sekaligus, tetapi penghentian atau pengembalian dana hanya dapat dilakukan melalui telepon pusat layanan pelanggan\n- Desain yang menyembunyikan tombol pembatalan di beberapa tahap bagian dalam\n- Desain yang baru menampilkan syarat pembatasan pengembalian dana setelah pembayaran\n- Desain yang menempatkan warna tombol, teks, dan urutan agar pelanggan salah paham\n- Desain yang tidak memberi tahu dengan jelas fakta pembayaran otomatis setelah uji coba gratis berakhir\n\nDesain seperti ini bukan hanya merusak pengalaman pelanggan, tetapi juga dapat dinilai sebagai dark pattern. Khususnya, lebih aman merancang tingkat kesulitan pembatalan dan penghentian agar tidak jauh berbeda dari tingkat kesulitan pendaftaran dan pembayaran.\n\n## Checklist yang harus dimasukkan dalam prompt untuk AI\n\nSaat meminta alat pengembangan AI mengimplementasikan fungsi pembayaran, sampaikan kebijakan terlebih dahulu seperti di bawah ini.\n\n### Contoh prompt fungsi pembayaran\n\n```text\nImplementasikan fungsi pembayaran untuk layanan e-commerce yang ditujukan kepada konsumen Korea.\nPastikan kebijakan berikut tercermin.\n\n1. Status pesanan menggunakan payment_pending, paid, payment_failed, cancel_requested, cancelled, refund_requested, refund_processing, partially_refunded, refunded, expired.\n2. Pesanan yang menunggu pembayaran diubah menjadi expired setelah 30 menit.\n3. Untuk pesanan yang sama, hanya 1 persetujuan pembayaran yang diizinkan, dan gunakan penguncian pesanan di sisi server serta kunci idempotensi.\n4. Webhook pembayaran dapat diterima secara duplikat, jadi ID event yang sama hanya diproses satu kali.\n5. Simpan tanggal permohonan pengembalian dana, tenggat pemrosesan pengembalian dana, pemroses, alasan, dan nomor transaksi pengembalian dana.\n6. Pengembalian dana sebagian dihitung berdasarkan jumlah pembayaran aktual per produk, dan kupon seluruh pesanan dialokasikan berdasarkan proporsi nilai produk.\n7. Saat pembayaran gagal, kembalikan teks panduan pelanggan sesuai alasan kegagalan.\n8. Buat agar pelanggan dapat memeriksa riwayat pembayaran dan status pengembalian dana di my page.\n9. Tampilkan tautan aturan pengembalian dana dan checkbox persetujuan sebelum pembayaran, lalu simpan waktu persetujuan dan versi syarat dan ketentuan.\n10. Jika ada kebijakan yang belum ditentukan, tanyakan terlebih dahulu sebelum menulis kode.\n```\n\nKalimat terakhir, “Jika ada kebijakan yang belum ditentukan, tanyakan terlebih dahulu,” penting. Ini dapat membuat AI menanyakan kembali kebijakan yang mudah terlewat oleh manusia, seperti apakah pengembalian dana disetujui otomatis, hak persetujuan administrator, dan cara pengurangan ongkos kirim.\n\n## Fungsi yang diperlukan pada layar operator\n\nFungsi pembayaran tidak selesai hanya dengan layar pelanggan. Pengembalian dana dan pembatalan adalah pekerjaan operasional yang diproses setiap hari, sehingga layar administrator wajib diperlukan.\n\n| Fungsi administrator | Alasan diperlukan |\n|---|---|\n| Daftar pengembalian dana menunggu | Diperlukan agar kasus pengembalian dana yang harus diproses tidak terlewat |\n| Tampilan batas waktu pemrosesan hukum | Diperlukan untuk mengurangi risiko keterlambatan pengembalian dana |\n| Peringatan mendekati·melewati tenggat | Diperlukan agar operator segera mengetahui standar internal seperti 3 hari kerja |\n| Pemilihan alasan pengembalian dana | Diperlukan untuk statistik dan alokasi biaya seperti perubahan pikiran, cacat produk, salah kirim |\n| Pratinjau perhitungan pengembalian dana sebagian | Diperlukan untuk mengurangi kesalahan perhitungan manual oleh operator |\n| Log pemrosesan | Diperlukan untuk menangani sengketa dan audit |\n| Manajemen hak akses | Diperlukan untuk membatasi persetujuan pengembalian dana dan perubahan status paksa |\n\n## Komposisi minimum model data pembayaran\n\nStruktur data berbeda untuk setiap layanan, tetapi setidaknya data pada tingkat berikut sebaiknya dipisahkan.\n\n| Tabel atau objek | Field inti |\n|---|---|\n| Pesanan | ID pesanan, ID pelanggan, status pesanan, nilai pesanan, nilai diskon, ongkos kirim, tanggal dan waktu pembuatan, tanggal dan waktu kedaluwarsa |\n| Produk pesanan | ID produk, nama produk, opsi, jumlah, nilai per produk, alokasi diskon per produk |\n| Pembayaran | ID pembayaran, ID pesanan, metode pembayaran, nomor persetujuan, jumlah persetujuan, status pembayaran, tanggal dan waktu persetujuan |\n| Pengembalian dana | ID pengembalian dana, ID pesanan, jumlah pengembalian dana, alasan pengembalian dana, status pengembalian dana, tanggal dan waktu permohonan, tanggal dan waktu selesai |\n| Riwayat status | ID target, status sebelumnya, status perubahan, pengubah, alasan perubahan, tanggal dan waktu perubahan |\n| Persetujuan syarat dan ketentuan | Jenis syarat dan ketentuan, versi syarat dan ketentuan, status persetujuan, tanggal dan waktu persetujuan, ID pelanggan |\n\nPoin pentingnya adalah tidak menimpa jumlah persetujuan pembayaran, jumlah pengembalian dana, dan total pesanan. Nilai yang terkait uang sebisa mungkin harus disimpan dalam bentuk riwayat dan unit transaksi agar kelak sesuai dengan pembukuan dan respons pelanggan.\n\n## Daftar pemeriksaan sebelum peluncuran\n\n- Apakah pembayaran hanya disetujui 1 kali meski tombol pembayaran ditekan 10 kali untuk pesanan yang sama?\n- Jika penyimpanan server gagal setelah persetujuan pembayaran, apakah dapat dipulihkan?\n- Apakah webhook pembayaran tidak diproses duplikat meski mengirim event yang sama beberapa kali?\n- Apakah pelanggan dapat memahami alasan kegagalan pembayaran dan cara mencoba ulang?\n- Apakah pesanan yang menunggu pembayaran otomatis kedaluwarsa setelah waktu tertentu?\n- Apakah jumlah pengembalian dana sebagian sesuai dengan kebijakan kupon, poin, dan ongkos kirim?\n- Apakah tanggal permohonan pengembalian dana hingga tenggat pemrosesan ditampilkan di layar administrator?\n- Apakah aturan pengembalian dana dapat diperiksa dengan mudah di layar sebelum pembayaran?\n- Apakah konten digital atau produk dengan pembatasan pengembalian dana memiliki pemberitahuan sebelumnya dan log persetujuan?\n- Apakah pelanggan dapat langsung memeriksa riwayat pembayaran dan status pengembalian dana di my page?\n\n## Kesimpulan\n\nAI dapat membuat kode fungsi pembayaran dengan cepat. Namun, sistem pembayaran yang beroperasi dengan aman dan legal dimulai dari keputusan kebijakan sebelum kode.\n\nJika status pesanan, batas waktu pengembalian dana menurut hukum, rumus perhitungan pengembalian dana sebagian, pencegahan pembayaran ganda, panduan kegagalan pembayaran, halaman riwayat pembayaran, dan lokasi pemberitahuan aturan pengembalian dana dirapikan terlebih dahulu lalu implementasinya diserahkan kepada AI, hasil yang jauh lebih stabil dapat diperoleh. Pembayaran harus dirancang dari sudut pandang bahwa ini bukan “fungsi untuk menerima uang,” melainkan “fungsi yang bertanggung jawab atas uang.”","content_html":"\u003ch2\u003e\n\u003ca href=\"#ringkasan-inti\" class=\"anchor\" id=\"ringkasan-inti\"\u003e\u003c/a\u003eRingkasan Inti\u003c/h2\u003e\n\u003cp\u003ePrompt paling berbahaya saat menyerahkan fungsi pembayaran kepada AI adalah meminta secara sederhana, “tambahkan pembayaran.” Pembayaran bukan sekadar kode untuk menerima uang, melainkan sistem operasional, akuntansi, dan dukungan pelanggan yang bertanggung jawab atas aliran uang.\u003c/p\u003e\n\u003cp\u003eSecara teknis, AI dapat dengan cepat mengimplementasikan integrasi jendela pembayaran, pemanggilan API persetujuan, penerimaan webhook, dan penyimpanan pesanan. Namun, jika kebijakan berikut belum ditentukan, dalam layanan nyata dapat muncul masalah seperti pesanan hantu, pembayaran ganda, keterlambatan pengembalian dana, lonjakan pusat layanan pelanggan, dan kelalaian pemberitahuan hukum.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eArea keputusan\u003c/th\u003e\n\u003cth\u003ePertanyaan yang harus ditentukan terlebih dahulu\u003c/th\u003e\n\u003cth\u003eRisiko jika gagal\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Area keputusan\"\u003eStatus pesanan\u003c/td\u003e\n\u003ctd data-label=\"Pertanyaan yang harus ditentukan terlebih dahulu\"\u003eStatus apa saja yang dilalui pesanan secara berurutan?\u003c/td\u003e\n\u003ctd data-label=\"Risiko jika gagal\"\u003eTerjadi pesanan hantu: pembayaran berhasil tetapi pesanan tidak ada\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Area keputusan\"\u003eBatas waktu pengembalian dana\u003c/td\u003e\n\u003ctd data-label=\"Pertanyaan yang harus ditentukan terlebih dahulu\"\u003eBagaimana mencerminkan batas waktu pembatalan pembelian dan pemrosesan pengembalian dana?\u003c/td\u003e\n\u003ctd data-label=\"Risiko jika gagal\"\u003ePelanggaran batas waktu hukum, bunga keterlambatan, risiko sengketa\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Area keputusan\"\u003ePengembalian dana sebagian\u003c/td\u003e\n\u003ctd data-label=\"Pertanyaan yang harus ditentukan terlebih dahulu\"\u003eBagaimana menghitung retur sebagian produk, kupon, dan ongkos kirim?\u003c/td\u003e\n\u003ctd data-label=\"Risiko jika gagal\"\u003eOperator harus menghitung manual setiap kali, pelanggan tidak percaya\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Area keputusan\"\u003ePembayaran ganda\u003c/td\u003e\n\u003ctd data-label=\"Pertanyaan yang harus ditentukan terlebih dahulu\"\u003eBagaimana mencegah pembayaran tercatat dua kali untuk pesanan yang sama?\u003c/td\u003e\n\u003ctd data-label=\"Risiko jika gagal\"\u003eKeluhan pelanggan berdasarkan tagihan kartu, kepercayaan menurun\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Area keputusan\"\u003ePanduan kegagalan\u003c/td\u003e\n\u003ctd data-label=\"Pertanyaan yang harus ditentukan terlebih dahulu\"\u003eBagaimana menjelaskan limit terlampaui, saldo tidak cukup, dan kegagalan autentikasi?\u003c/td\u003e\n\u003ctd data-label=\"Risiko jika gagal\"\u003eTingkat konversi percobaan ulang menurun, pertanyaan yang tidak perlu meningkat\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Area keputusan\"\u003eRiwayat pembayaran\u003c/td\u003e\n\u003ctd data-label=\"Pertanyaan yang harus ditentukan terlebih dahulu\"\u003eDi mana pelanggan memeriksa status pembayaran dan pengembalian dana?\u003c/td\u003e\n\u003ctd data-label=\"Risiko jika gagal\"\u003ePertanyaan ke pusat layanan pelanggan meningkat, status tidak transparan\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Area keputusan\"\u003ePemberitahuan pengembalian dana\u003c/td\u003e\n\u003ctd data-label=\"Pertanyaan yang harus ditentukan terlebih dahulu\"\u003eDi mana menempatkan aturan pengembalian dana dan tombol pembatalan?\u003c/td\u003e\n\u003ctd data-label=\"Risiko jika gagal\"\u003eKontroversi dark pattern, risiko regulasi\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#1-desain-status-pesanan-status-adalah-bahasa-operasional\" class=\"anchor\" id=\"1-desain-status-pesanan-status-adalah-bahasa-operasional\"\u003e\u003c/a\u003e1. Desain status pesanan: status adalah bahasa operasional\u003c/h2\u003e\n\u003cp\u003eSaat membuat fungsi pembayaran, status pesanan tidak boleh hanya berupa satu status “pesanan selesai.” Dalam praktiknya, pesanan melalui berbagai tahap seperti percobaan pembayaran, persetujuan, pembatalan, pengembalian dana, kegagalan, dan kedaluwarsa.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#contoh-status-yang-direkomendasikan\" class=\"anchor\" id=\"contoh-status-yang-direkomendasikan\"\u003e\u003c/a\u003eContoh status yang direkomendasikan\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eContoh kode status\u003c/th\u003e\n\u003cth\u003eStatus yang terlihat oleh pelanggan\u003c/th\u003e\n\u003cth\u003eMakna\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Contoh kode status\"\u003e\u003ccode\u003epayment_pending\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status yang terlihat oleh pelanggan\"\u003eMenunggu pembayaran\u003c/td\u003e\n\u003ctd data-label=\"Makna\"\u003ePesanan sudah dibuat tetapi pembayaran belum selesai\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Contoh kode status\"\u003e\u003ccode\u003epaid\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status yang terlihat oleh pelanggan\"\u003ePembayaran selesai\u003c/td\u003e\n\u003ctd data-label=\"Makna\"\u003ePersetujuan pembayaran selesai dan pesanan valid\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Contoh kode status\"\u003e\u003ccode\u003epayment_failed\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status yang terlihat oleh pelanggan\"\u003ePembayaran gagal\u003c/td\u003e\n\u003ctd data-label=\"Makna\"\u003ePercobaan pembayaran gagal dan perlu ditentukan apakah bisa dicoba ulang\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Contoh kode status\"\u003e\u003ccode\u003ecancel_requested\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status yang terlihat oleh pelanggan\"\u003ePembatalan diminta\u003c/td\u003e\n\u003ctd data-label=\"Makna\"\u003ePelanggan mengajukan pembatalan dan sedang menunggu pemrosesan\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Contoh kode status\"\u003e\u003ccode\u003ecancelled\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status yang terlihat oleh pelanggan\"\u003ePembatalan selesai\u003c/td\u003e\n\u003ctd data-label=\"Makna\"\u003ePembatalan pesanan sebelum pembayaran atau pembatalan persetujuan selesai\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Contoh kode status\"\u003e\u003ccode\u003erefund_requested\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status yang terlihat oleh pelanggan\"\u003ePengembalian dana diminta\u003c/td\u003e\n\u003ctd data-label=\"Makna\"\u003ePermohonan pengembalian dana setelah pembayaran diterima\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Contoh kode status\"\u003e\u003ccode\u003erefund_processing\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status yang terlihat oleh pelanggan\"\u003ePengembalian dana diproses\u003c/td\u003e\n\u003ctd data-label=\"Makna\"\u003eSedang memproses persetujuan pengembalian dana atau pengembalian ke metode pembayaran\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Contoh kode status\"\u003e\u003ccode\u003epartially_refunded\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status yang terlihat oleh pelanggan\"\u003ePengembalian dana sebagian selesai\u003c/td\u003e\n\u003ctd data-label=\"Makna\"\u003eHanya sebagian dari nilai pesanan yang dikembalikan\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Contoh kode status\"\u003e\u003ccode\u003erefunded\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status yang terlihat oleh pelanggan\"\u003ePengembalian dana selesai\u003c/td\u003e\n\u003ctd data-label=\"Makna\"\u003ePemrosesan pengembalian dana selesai\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Contoh kode status\"\u003e\u003ccode\u003eexpired\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Status yang terlihat oleh pelanggan\"\u003ePesanan kedaluwarsa\u003c/td\u003e\n\u003ctd data-label=\"Makna\"\u003eWaktu tunggu pembayaran berlalu dan pesanan menjadi tidak valid\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\n\u003ca href=\"#prinsip-desain-status\" class=\"anchor\" id=\"prinsip-desain-status\"\u003e\u003c/a\u003ePrinsip desain status\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eStatus pesanan dan status pembayaran tidak dianggap sepenuhnya sama. Pesanan bisa ada tetapi pembayaran gagal, dan pembayaran bisa disetujui tetapi penyimpanan pesanan gagal.\u003c/li\u003e\n\u003cli\u003eSetiap perubahan status harus menyimpan waktu kejadian, pemroses, alasan, pengenal transaksi pembayaran, dan pengenal transaksi pengembalian dana.\u003c/li\u003e\n\u003cli\u003eLayar pelanggan, layar administrator, dan frasa respons pusat layanan pelanggan harus menggunakan definisi status yang sama.\u003c/li\u003e\n\u003cli\u003eTransisi status dirancang satu arah, dan pemulihan pengecualian diproses dengan mencatatnya melalui hak administrator terpisah.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#2-pembatalan-pembelian-dan-batas-waktu-pengembalian-dana-menurut-hukum-bukan-kebijakan-melainkan-persyaratan-hukum\" class=\"anchor\" id=\"2-pembatalan-pembelian-dan-batas-waktu-pengembalian-dana-menurut-hukum-bukan-kebijakan-melainkan-persyaratan-hukum\"\u003e\u003c/a\u003e2. Pembatalan pembelian dan batas waktu pengembalian dana menurut hukum: bukan kebijakan, melainkan persyaratan hukum\u003c/h2\u003e\n\u003cp\u003eJika menjalankan e-commerce yang ditujukan kepada konsumen di Korea, perlu mempertimbangkan Undang-Undang Perlindungan Konsumen dalam Perdagangan Elektronik dan sebagainya. Secara umum, konsumen dapat membatalkan pembelian dalam periode tertentu, dan pelaku usaha harus mengembalikan pembayaran dalam batas waktu yang ditentukan setelah permintaan pengembalian dana atau prosedur pengembalian barang.\u003c/p\u003e\n\u003cp\u003eStandar yang sangat penting dalam praktik adalah sebagai berikut.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ePada prinsipnya, konsumen dapat membatalkan pembelian dalam 7 hari sejak tanggal standar yang ditentukan hukum, seperti hari penerimaan barang dan sebagainya.\u003c/li\u003e\n\u003cli\u003ePelaku usaha harus mengembalikan pembayaran dalam batas waktu hukum setelah alasan pengembalian dana terjadi, dan jika terlambat, dapat timbul masalah kompensasi keterlambatan atau bunga keterlambatan.\u003c/li\u003e\n\u003cli\u003eKonten digital, produk pesanan khusus, produk yang nilainya menurun secara signifikan karena penggunaan, dan sebagainya dapat menjadi pengecualian, tetapi untuk menerapkan pengecualian, persyaratan seperti pemberitahuan dan persetujuan sebelumnya harus diperiksa dengan hati-hati.\u003c/li\u003e\n\u003cli\u003ePenerapan sebenarnya dapat berbeda tergantung jenis produk, metode kontrak, pemberitahuan yang diberikan kepada konsumen, dan apakah penggunaan sudah dimulai, sehingga diperlukan tinjauan hukum.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#cara-mengubahnya-menjadi-persyaratan-pengembangan\" class=\"anchor\" id=\"cara-mengubahnya-menjadi-persyaratan-pengembangan\"\u003e\u003c/a\u003eCara mengubahnya menjadi persyaratan pengembangan\u003c/h3\u003e\n\u003cp\u003eStandar hukum tidak cukup jika hanya ditulis dalam klausul syarat dan ketentuan. Standar tersebut juga harus diubah menjadi persyaratan sistem.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003ePersyaratan hukum·kebijakan\u003c/th\u003e\n\u003cth\u003ePersyaratan sistem\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Persyaratan hukum·kebijakan\"\u003eMenentukan apakah pembatalan pembelian dapat dilakukan dalam 7 hari\u003c/td\u003e\n\u003ctd data-label=\"Persyaratan sistem\"\u003eMenghitung otomatis periode pengembalian dana berdasarkan tanggal penerimaan pesanan atau tanggal penyediaan layanan\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Persyaratan hukum·kebijakan\"\u003ePerlu memproses pengembalian dana dalam 3 hari kerja\u003c/td\u003e\n\u003ctd data-label=\"Persyaratan sistem\"\u003eMenampilkan tanggal permohonan pengembalian dana dan tenggat pemrosesan di layar administrator\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Persyaratan hukum·kebijakan\"\u003eRisiko keterlambatan pengembalian dana\u003c/td\u003e\n\u003ctd data-label=\"Persyaratan sistem\"\u003eMenampilkan notifikasi mendekati tenggat dan melewati tenggat\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Persyaratan hukum·kebijakan\"\u003ePerlu pemberitahuan untuk produk pengecualian\u003c/td\u003e\n\u003ctd data-label=\"Persyaratan sistem\"\u003eMenampilkan dengan jelas sebelum pembayaran bahwa produk memiliki pembatasan pengembalian dana dan menyimpan log persetujuan\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Persyaratan hukum·kebijakan\"\u003ePerlu penanganan sengketa\u003c/td\u003e\n\u003ctd data-label=\"Persyaratan sistem\"\u003eMenyimpan versi syarat dan ketentuan, waktu pemberitahuan, waktu persetujuan, IP pelanggan atau log akun\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#3-aturan-pengembalian-dana-sebagian-kupon-ongkos-kirim-dan-pajak-harus-ditentukan-terlebih-dahulu\" class=\"anchor\" id=\"3-aturan-pengembalian-dana-sebagian-kupon-ongkos-kirim-dan-pajak-harus-ditentukan-terlebih-dahulu\"\u003e\u003c/a\u003e3. Aturan pengembalian dana sebagian: kupon, ongkos kirim, dan pajak harus ditentukan terlebih dahulu\u003c/h2\u003e\n\u003cp\u003ePengembalian dana sebagian jauh lebih kompleks daripada pembatalan penuh. Jika beberapa produk dipesan sekaligus lalu hanya sebagian yang dikembalikan, harus diputuskan bagaimana membagi diskon dan ongkos kirim yang semula diterapkan.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#hal-yang-wajib-ditentukan\" class=\"anchor\" id=\"hal-yang-wajib-ditentukan\"\u003e\u003c/a\u003eHal yang wajib ditentukan\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eBagaimana mengalokasikan jumlah pembayaran per produk\u003c/li\u003e\n\u003cli\u003eApakah kupon untuk seluruh pesanan akan dialokasikan secara proporsional per produk\u003c/li\u003e\n\u003cli\u003eApakah kupon untuk produk tertentu hanya diterapkan pada produk tersebut\u003c/li\u003e\n\u003cli\u003eApakah ongkos kirim akan dikurangkan ketika syarat gratis ongkir tidak lagi terpenuhi\u003c/li\u003e\n\u003cli\u003eBagaimana membedakan ongkos kirim retur karena perubahan pikiran dan ongkos kirim retur karena cacat produk\u003c/li\u003e\n\u003cli\u003eDalam urutan apa pembayaran dengan poin, saldo, dan kartu hadiah akan dikembalikan\u003c/li\u003e\n\u003cli\u003eBagaimana mengubah faktur pajak, kuitansi tunai, dan tampilan kuitansi setelah pengembalian dana sebagian\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#contoh-perhitungan-pengembalian-dana-sebagian\" class=\"anchor\" id=\"contoh-perhitungan-pengembalian-dana-sebagian\"\u003e\u003c/a\u003eContoh perhitungan pengembalian dana sebagian\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eItem\u003c/th\u003e\n\u003cth\u003eJumlah\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003eProduk A\u003c/td\u003e\n\u003ctd data-label=\"Jumlah\"\u003e30,000원\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003eProduk B\u003c/td\u003e\n\u003ctd data-label=\"Jumlah\"\u003e70,000원\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003eKupon seluruh pesanan\u003c/td\u003e\n\u003ctd data-label=\"Jumlah\"\u003e-10,000원\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Item\"\u003eJumlah pembayaran aktual\u003c/td\u003e\n\u003ctd data-label=\"Jumlah\"\u003e90,000원\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eJika kupon dialokasikan berdasarkan proporsi nilai produk, diskon 3,000원 dialokasikan ke produk A dan 7,000원 ke produk B. Dalam hal ini, jika hanya produk A yang dikembalikan, jumlah dasar pengembalian dana bukan 30,000원, melainkan 27,000원. Jika ada syarat gratis ongkir, ongkos kirim retur, dan pembatasan pengembalian berdasarkan metode pembayaran, jumlah akhir pengembalian dana dapat berubah lagi.\u003c/p\u003e\n\u003cp\u003eTidak ada satu jawaban benar. Yang penting adalah menetapkan aturan yang konsisten sebelumnya dan memberi pemberitahuan agar pelanggan dapat memahaminya sebelum pembayaran atau sebelum mengajukan pengembalian dana.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#4-pencegahan-pembayaran-ganda-menonaktifkan-tombol-saja-tidak-cukup\" class=\"anchor\" id=\"4-pencegahan-pembayaran-ganda-menonaktifkan-tombol-saja-tidak-cukup\"\u003e\u003c/a\u003e4. Pencegahan pembayaran ganda: menonaktifkan tombol saja tidak cukup\u003c/h2\u003e\n\u003cp\u003ePembayaran ganda adalah insiden pembayaran yang paling cepat diketahui pelanggan. Pelanggan melihat pesan persetujuan kartu dan tagihan kartu lebih dahulu daripada status pesanan internal layanan. Jika pesanan yang sama dibayar dua kali, kepercayaan akan turun drastis.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#penyebab-terjadinya\" class=\"anchor\" id=\"penyebab-terjadinya\"\u003e\u003c/a\u003ePenyebab terjadinya\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003ePelanggan mengklik tombol pembayaran berulang kali\u003c/li\u003e\n\u003cli\u003ePelanggan menyegarkan halaman atau menekan tombol kembali segera setelah pembayaran\u003c/li\u003e\n\u003cli\u003ePermintaan yang sama dikirim ulang karena keterlambatan jaringan seluler\u003c/li\u003e\n\u003cli\u003eRespons persetujuan pembayaran berhasil tetapi penyimpanan di server layanan gagal\u003c/li\u003e\n\u003cli\u003eWebhook dan redirect klien mengubah status pesanan secara bersamaan\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#desain-pertahanan\" class=\"anchor\" id=\"desain-pertahanan\"\u003e\u003c/a\u003eDesain pertahanan\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eMekanisme pertahanan\u003c/th\u003e\n\u003cth\u003ePenjelasan\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Mekanisme pertahanan\"\u003ePenguncian tombol klien\u003c/td\u003e\n\u003ctd data-label=\"Penjelasan\"\u003eMencegah klik ulang setelah tombol pembayaran diklik, tetapi hanya digunakan sebagai sarana pendukung\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Mekanisme pertahanan\"\u003ePenguncian pesanan di sisi server\u003c/td\u003e\n\u003ctd data-label=\"Penjelasan\"\u003eMemastikan permintaan persetujuan pembayaran tidak dijalankan bersamaan untuk ID pesanan yang sama\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Mekanisme pertahanan\"\u003eKunci idempotensi\u003c/td\u003e\n\u003ctd data-label=\"Penjelasan\"\u003eMenggunakan pengenal agar meski permintaan pembayaran yang sama dikirim beberapa kali, hasil hanya dibuat satu kali\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Mekanisme pertahanan\"\u003eNomor transaksi unik\u003c/td\u003e\n\u003ctd data-label=\"Penjelasan\"\u003eMencegah penyimpanan duplikat nomor pesanan dan nomor transaksi pembayaran dengan constraint database\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Mekanisme pertahanan\"\u003eVerifikasi berbasis status\u003c/td\u003e\n\u003ctd data-label=\"Penjelasan\"\u003eMencegah permintaan persetujuan tambahan untuk pesanan yang sudah \u003ccode\u003epaid\u003c/code\u003e\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Mekanisme pertahanan\"\u003ePemrosesan duplikat webhook\u003c/td\u003e\n\u003ctd data-label=\"Penjelasan\"\u003eMemastikan perubahan status hanya terjadi satu kali meski event webhook yang sama datang beberapa kali\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eSaat meminta AI menulis kode pembayaran, sebaiknya nyatakan bukan “cegah klik duplikat,” melainkan “untuk pesanan yang sama, persetujuan pembayaran dan pemrosesan pembayaran selesai harus berjalan secara idempoten.”\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#5-teks-panduan-kegagalan-pembayaran-kegagalan-bukan-insiden-melainkan-alur-normal\" class=\"anchor\" id=\"5-teks-panduan-kegagalan-pembayaran-kegagalan-bukan-insiden-melainkan-alur-normal\"\u003e\u003c/a\u003e5. Teks panduan kegagalan pembayaran: kegagalan bukan insiden, melainkan alur normal\u003c/h2\u003e\n\u003cp\u003eKegagalan pembayaran adalah situasi normal yang terjadi setiap hari. Limit terlampaui, saldo tidak cukup, autentikasi kartu gagal, kesalahan kata sandi, autentikasi 3D Secure gagal, aplikasi pembayaran praktis tidak merespons, dan kesalahan jaringan semuanya adalah kasus umum.\u003c/p\u003e\n\u003cp\u003ePanduan yang buruk adalah teks yang berhenti pada “Terjadi kesalahan.” Pelanggan tidak tahu apakah pembayaran sudah berhasil, apakah boleh menekan lagi, atau apakah pesanan akan hilang.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#contoh-teks-panduan\" class=\"anchor\" id=\"contoh-teks-panduan\"\u003e\u003c/a\u003eContoh teks panduan\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eSituasi\u003c/th\u003e\n\u003cth\u003ePanduan yang direkomendasikan\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situasi\"\u003eSaldo tidak cukup\u003c/td\u003e\n\u003ctd data-label=\"Panduan yang direkomendasikan\"\u003ePembayaran tidak selesai karena saldo metode pembayaran tidak mencukupi. Silakan pilih metode pembayaran lain atau periksa saldo lalu coba lagi.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situasi\"\u003eLimit terlampaui\u003c/td\u003e\n\u003ctd data-label=\"Panduan yang direkomendasikan\"\u003ePembayaran gagal karena melebihi limit kartu atau limit pembayaran sekali transaksi. Silakan periksa limit di aplikasi penerbit kartu atau bayar dengan kartu lain.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situasi\"\u003eAutentikasi gagal\u003c/td\u003e\n\u003ctd data-label=\"Panduan yang direkomendasikan\"\u003ePesanan tetap dalam status menunggu pembayaran karena autentikasi pembayaran belum selesai. Anda dapat membayar lagi dalam 30 menit.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situasi\"\u003eKesalahan jaringan\u003c/td\u003e\n\u003ctd data-label=\"Panduan yang direkomendasikan\"\u003eKonfirmasi hasil pembayaran sedang tertunda. Untuk mencegah pembayaran ganda, silakan periksa riwayat pembayaran setelah beberapa saat.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situasi\"\u003ePesanan kedaluwarsa\u003c/td\u003e\n\u003ctd data-label=\"Panduan yang direkomendasikan\"\u003ePesanan kedaluwarsa karena waktu tunggu pembayaran telah berlalu. Silakan pilih produk lagi dan lakukan pemesanan.\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\n\u003ca href=\"#elemen-inti-panduan-kegagalan\" class=\"anchor\" id=\"elemen-inti-panduan-kegagalan\"\u003e\u003c/a\u003eElemen inti panduan kegagalan\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eJelaskan dengan jelas apakah pembayaran benar-benar belum selesai.\u003c/li\u003e\n\u003cli\u003eBeri tahu berapa lama pesanan dipertahankan.\u003c/li\u003e\n\u003cli\u003ePandu apakah pelanggan boleh mencoba lagi atau harus menggunakan metode pembayaran lain.\u003c/li\u003e\n\u003cli\u003eTampilkan nomor pesanan yang diperlukan saat menghubungi pusat layanan pelanggan.\u003c/li\u003e\n\u003cli\u003eJika hasil pembayaran tidak pasti, jangan langsung mendorong pembayaran ulang; sediakan status sedang dikonfirmasi.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#6-halaman-riwayat-pembayaran-layar-inti-untuk-mengurangi-pusat-layanan-pelanggan\" class=\"anchor\" id=\"6-halaman-riwayat-pembayaran-layar-inti-untuk-mengurangi-pusat-layanan-pelanggan\"\u003e\u003c/a\u003e6. Halaman riwayat pembayaran: layar inti untuk mengurangi pusat layanan pelanggan\u003c/h2\u003e\n\u003cp\u003eJika tidak ada halaman riwayat pembayaran, pelanggan akan menghubungi pusat layanan pelanggan untuk memeriksa status pembayaran, pembatalan, dan pengembalian dana. Riwayat pembayaran bukan sekadar layar kuitansi, melainkan perangkat kepercayaan bagi pelanggan untuk memeriksa status uang mereka saat ini.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#informasi-yang-harus-disertakan-di-halaman-riwayat-pembayaran\" class=\"anchor\" id=\"informasi-yang-harus-disertakan-di-halaman-riwayat-pembayaran\"\u003e\u003c/a\u003eInformasi yang harus disertakan di halaman riwayat pembayaran\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eNomor pesanan\u003c/li\u003e\n\u003cli\u003eTanggal dan waktu pesanan serta tanggal dan waktu pembayaran\u003c/li\u003e\n\u003cli\u003eNama produk, jumlah, opsi\u003c/li\u003e\n\u003cli\u003eMetode pembayaran dan nomor persetujuan atau pengenal transaksi\u003c/li\u003e\n\u003cli\u003eNilai produk, diskon, ongkos kirim, jumlah poin yang digunakan, jumlah akhir pembayaran\u003c/li\u003e\n\u003cli\u003eStatus pesanan saat ini dan status pengembalian dana\u003c/li\u003e\n\u003cli\u003eTanggal permohonan pengembalian dana, tanggal persetujuan pengembalian dana, perkiraan tanggal penyelesaian pengembalian dana\u003c/li\u003e\n\u003cli\u003eApakah pembatalan atau pengembalian dana tersedia\u003c/li\u003e\n\u003cli\u003eTautan untuk memeriksa kuitansi, rincian transaksi, kuitansi tunai\u003c/li\u003e\n\u003cli\u003eInformasi yang diperlukan saat menghubungi pusat layanan pelanggan\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#koneksi-dengan-layar-operator\" class=\"anchor\" id=\"koneksi-dengan-layar-operator\"\u003e\u003c/a\u003eKoneksi dengan layar operator\u003c/h3\u003e\n\u003cp\u003eLayar pelanggan dan layar administrator harus melihat data yang sama. Jika pelanggan melihat “pengembalian dana diproses” tetapi layar administrator menampilkan “pemrosesan selesai,” respons pusat layanan pelanggan akan kacau. Nama status boleh diekspresikan berbeda, tetapi kode status internal dan aturan transisinya harus satu.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#7-lokasi-pemberitahuan-aturan-pengembalian-dana-jika-disembunyikan-itu-bukan-kebijakan-melainkan-risiko\" class=\"anchor\" id=\"7-lokasi-pemberitahuan-aturan-pengembalian-dana-jika-disembunyikan-itu-bukan-kebijakan-melainkan-risiko\"\u003e\u003c/a\u003e7. Lokasi pemberitahuan aturan pengembalian dana: jika disembunyikan, itu bukan kebijakan melainkan risiko\u003c/h2\u003e\n\u003cp\u003eAturan pengembalian dana tidak cukup jika hanya diletakkan di sudut halaman syarat dan ketentuan. Pada layar tempat pelanggan mengambil keputusan pembayaran, periode pengembalian dana, syarat pembatasan pengembalian dana, dan cara pembatalan harus dapat diperiksa dengan mudah.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#lokasi-pemberitahuan-yang-baik\" class=\"anchor\" id=\"lokasi-pemberitahuan-yang-baik\"\u003e\u003c/a\u003eLokasi pemberitahuan yang baik\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eDi dekat harga atau tombol beli pada halaman detail produk\u003c/li\u003e\n\u003cli\u003eLayar keranjang atau formulir pesanan\u003c/li\u003e\n\u003cli\u003eArea persetujuan syarat dan ketentuan serta aturan pengembalian dana tepat di atas tombol pembayaran\u003c/li\u003e\n\u003cli\u003eHalaman pembayaran selesai\u003c/li\u003e\n\u003cli\u003eLayar detail pesanan di my page\u003c/li\u003e\n\u003cli\u003eLayar permohonan pengembalian dana\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#desain-yang-harus-dihindari\" class=\"anchor\" id=\"desain-yang-harus-dihindari\"\u003e\u003c/a\u003eDesain yang harus dihindari\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eDesain yang memungkinkan pendaftaran dan pembayaran dilakukan sekaligus, tetapi penghentian atau pengembalian dana hanya dapat dilakukan melalui telepon pusat layanan pelanggan\u003c/li\u003e\n\u003cli\u003eDesain yang menyembunyikan tombol pembatalan di beberapa tahap bagian dalam\u003c/li\u003e\n\u003cli\u003eDesain yang baru menampilkan syarat pembatasan pengembalian dana setelah pembayaran\u003c/li\u003e\n\u003cli\u003eDesain yang menempatkan warna tombol, teks, dan urutan agar pelanggan salah paham\u003c/li\u003e\n\u003cli\u003eDesain yang tidak memberi tahu dengan jelas fakta pembayaran otomatis setelah uji coba gratis berakhir\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eDesain seperti ini bukan hanya merusak pengalaman pelanggan, tetapi juga dapat dinilai sebagai dark pattern. Khususnya, lebih aman merancang tingkat kesulitan pembatalan dan penghentian agar tidak jauh berbeda dari tingkat kesulitan pendaftaran dan pembayaran.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#checklist-yang-harus-dimasukkan-dalam-prompt-untuk-ai\" class=\"anchor\" id=\"checklist-yang-harus-dimasukkan-dalam-prompt-untuk-ai\"\u003e\u003c/a\u003eChecklist yang harus dimasukkan dalam prompt untuk AI\u003c/h2\u003e\n\u003cp\u003eSaat meminta alat pengembangan AI mengimplementasikan fungsi pembayaran, sampaikan kebijakan terlebih dahulu seperti di bawah ini.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#contoh-prompt-fungsi-pembayaran\" class=\"anchor\" id=\"contoh-prompt-fungsi-pembayaran\"\u003e\u003c/a\u003eContoh prompt fungsi pembayaran\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eImplementasikan fungsi pembayaran untuk layanan e-commerce yang ditujukan kepada konsumen Korea.\n\u003c/span\u003e\u003cspan\u003ePastikan kebijakan berikut tercermin.\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e1. Status pesanan menggunakan payment_pending, paid, payment_failed, cancel_requested, cancelled, refund_requested, refund_processing, partially_refunded, refunded, expired.\n\u003c/span\u003e\u003cspan\u003e2. Pesanan yang menunggu pembayaran diubah menjadi expired setelah 30 menit.\n\u003c/span\u003e\u003cspan\u003e3. Untuk pesanan yang sama, hanya 1 persetujuan pembayaran yang diizinkan, dan gunakan penguncian pesanan di sisi server serta kunci idempotensi.\n\u003c/span\u003e\u003cspan\u003e4. Webhook pembayaran dapat diterima secara duplikat, jadi ID event yang sama hanya diproses satu kali.\n\u003c/span\u003e\u003cspan\u003e5. Simpan tanggal permohonan pengembalian dana, tenggat pemrosesan pengembalian dana, pemroses, alasan, dan nomor transaksi pengembalian dana.\n\u003c/span\u003e\u003cspan\u003e6. Pengembalian dana sebagian dihitung berdasarkan jumlah pembayaran aktual per produk, dan kupon seluruh pesanan dialokasikan berdasarkan proporsi nilai produk.\n\u003c/span\u003e\u003cspan\u003e7. Saat pembayaran gagal, kembalikan teks panduan pelanggan sesuai alasan kegagalan.\n\u003c/span\u003e\u003cspan\u003e8. Buat agar pelanggan dapat memeriksa riwayat pembayaran dan status pengembalian dana di my page.\n\u003c/span\u003e\u003cspan\u003e9. Tampilkan tautan aturan pengembalian dana dan checkbox persetujuan sebelum pembayaran, lalu simpan waktu persetujuan dan versi syarat dan ketentuan.\n\u003c/span\u003e\u003cspan\u003e10. Jika ada kebijakan yang belum ditentukan, tanyakan terlebih dahulu sebelum menulis kode.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eKalimat terakhir, “Jika ada kebijakan yang belum ditentukan, tanyakan terlebih dahulu,” penting. Ini dapat membuat AI menanyakan kembali kebijakan yang mudah terlewat oleh manusia, seperti apakah pengembalian dana disetujui otomatis, hak persetujuan administrator, dan cara pengurangan ongkos kirim.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#fungsi-yang-diperlukan-pada-layar-operator\" class=\"anchor\" id=\"fungsi-yang-diperlukan-pada-layar-operator\"\u003e\u003c/a\u003eFungsi yang diperlukan pada layar operator\u003c/h2\u003e\n\u003cp\u003eFungsi pembayaran tidak selesai hanya dengan layar pelanggan. Pengembalian dana dan pembatalan adalah pekerjaan operasional yang diproses setiap hari, sehingga layar administrator wajib diperlukan.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eFungsi administrator\u003c/th\u003e\n\u003cth\u003eAlasan diperlukan\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Fungsi administrator\"\u003eDaftar pengembalian dana menunggu\u003c/td\u003e\n\u003ctd data-label=\"Alasan diperlukan\"\u003eDiperlukan agar kasus pengembalian dana yang harus diproses tidak terlewat\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Fungsi administrator\"\u003eTampilan batas waktu pemrosesan hukum\u003c/td\u003e\n\u003ctd data-label=\"Alasan diperlukan\"\u003eDiperlukan untuk mengurangi risiko keterlambatan pengembalian dana\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Fungsi administrator\"\u003ePeringatan mendekati·melewati tenggat\u003c/td\u003e\n\u003ctd data-label=\"Alasan diperlukan\"\u003eDiperlukan agar operator segera mengetahui standar internal seperti 3 hari kerja\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Fungsi administrator\"\u003ePemilihan alasan pengembalian dana\u003c/td\u003e\n\u003ctd data-label=\"Alasan diperlukan\"\u003eDiperlukan untuk statistik dan alokasi biaya seperti perubahan pikiran, cacat produk, salah kirim\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Fungsi administrator\"\u003ePratinjau perhitungan pengembalian dana sebagian\u003c/td\u003e\n\u003ctd data-label=\"Alasan diperlukan\"\u003eDiperlukan untuk mengurangi kesalahan perhitungan manual oleh operator\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Fungsi administrator\"\u003eLog pemrosesan\u003c/td\u003e\n\u003ctd data-label=\"Alasan diperlukan\"\u003eDiperlukan untuk menangani sengketa dan audit\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Fungsi administrator\"\u003eManajemen hak akses\u003c/td\u003e\n\u003ctd data-label=\"Alasan diperlukan\"\u003eDiperlukan untuk membatasi persetujuan pengembalian dana dan perubahan status paksa\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#komposisi-minimum-model-data-pembayaran\" class=\"anchor\" id=\"komposisi-minimum-model-data-pembayaran\"\u003e\u003c/a\u003eKomposisi minimum model data pembayaran\u003c/h2\u003e\n\u003cp\u003eStruktur data berbeda untuk setiap layanan, tetapi setidaknya data pada tingkat berikut sebaiknya dipisahkan.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eTabel atau objek\u003c/th\u003e\n\u003cth\u003eField inti\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabel atau objek\"\u003ePesanan\u003c/td\u003e\n\u003ctd data-label=\"Field inti\"\u003eID pesanan, ID pelanggan, status pesanan, nilai pesanan, nilai diskon, ongkos kirim, tanggal dan waktu pembuatan, tanggal dan waktu kedaluwarsa\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabel atau objek\"\u003eProduk pesanan\u003c/td\u003e\n\u003ctd data-label=\"Field inti\"\u003eID produk, nama produk, opsi, jumlah, nilai per produk, alokasi diskon per produk\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabel atau objek\"\u003ePembayaran\u003c/td\u003e\n\u003ctd data-label=\"Field inti\"\u003eID pembayaran, ID pesanan, metode pembayaran, nomor persetujuan, jumlah persetujuan, status pembayaran, tanggal dan waktu persetujuan\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabel atau objek\"\u003ePengembalian dana\u003c/td\u003e\n\u003ctd data-label=\"Field inti\"\u003eID pengembalian dana, ID pesanan, jumlah pengembalian dana, alasan pengembalian dana, status pengembalian dana, tanggal dan waktu permohonan, tanggal dan waktu selesai\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabel atau objek\"\u003eRiwayat status\u003c/td\u003e\n\u003ctd data-label=\"Field inti\"\u003eID target, status sebelumnya, status perubahan, pengubah, alasan perubahan, tanggal dan waktu perubahan\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Tabel atau objek\"\u003ePersetujuan syarat dan ketentuan\u003c/td\u003e\n\u003ctd data-label=\"Field inti\"\u003eJenis syarat dan ketentuan, versi syarat dan ketentuan, status persetujuan, tanggal dan waktu persetujuan, ID pelanggan\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003ePoin pentingnya adalah tidak menimpa jumlah persetujuan pembayaran, jumlah pengembalian dana, dan total pesanan. Nilai yang terkait uang sebisa mungkin harus disimpan dalam bentuk riwayat dan unit transaksi agar kelak sesuai dengan pembukuan dan respons pelanggan.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#daftar-pemeriksaan-sebelum-peluncuran\" class=\"anchor\" id=\"daftar-pemeriksaan-sebelum-peluncuran\"\u003e\u003c/a\u003eDaftar pemeriksaan sebelum peluncuran\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApakah pembayaran hanya disetujui 1 kali meski tombol pembayaran ditekan 10 kali untuk pesanan yang sama?\u003c/li\u003e\n\u003cli\u003eJika penyimpanan server gagal setelah persetujuan pembayaran, apakah dapat dipulihkan?\u003c/li\u003e\n\u003cli\u003eApakah webhook pembayaran tidak diproses duplikat meski mengirim event yang sama beberapa kali?\u003c/li\u003e\n\u003cli\u003eApakah pelanggan dapat memahami alasan kegagalan pembayaran dan cara mencoba ulang?\u003c/li\u003e\n\u003cli\u003eApakah pesanan yang menunggu pembayaran otomatis kedaluwarsa setelah waktu tertentu?\u003c/li\u003e\n\u003cli\u003eApakah jumlah pengembalian dana sebagian sesuai dengan kebijakan kupon, poin, dan ongkos kirim?\u003c/li\u003e\n\u003cli\u003eApakah tanggal permohonan pengembalian dana hingga tenggat pemrosesan ditampilkan di layar administrator?\u003c/li\u003e\n\u003cli\u003eApakah aturan pengembalian dana dapat diperiksa dengan mudah di layar sebelum pembayaran?\u003c/li\u003e\n\u003cli\u003eApakah konten digital atau produk dengan pembatasan pengembalian dana memiliki pemberitahuan sebelumnya dan log persetujuan?\u003c/li\u003e\n\u003cli\u003eApakah pelanggan dapat langsung memeriksa riwayat pembayaran dan status pengembalian dana di my page?\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#kesimpulan\" class=\"anchor\" id=\"kesimpulan\"\u003e\u003c/a\u003eKesimpulan\u003c/h2\u003e\n\u003cp\u003eAI dapat membuat kode fungsi pembayaran dengan cepat. Namun, sistem pembayaran yang beroperasi dengan aman dan legal dimulai dari keputusan kebijakan sebelum kode.\u003c/p\u003e\n\u003cp\u003eJika status pesanan, batas waktu pengembalian dana menurut hukum, rumus perhitungan pengembalian dana sebagian, pencegahan pembayaran ganda, panduan kegagalan pembayaran, halaman riwayat pembayaran, dan lokasi pemberitahuan aturan pengembalian dana dirapikan terlebih dahulu lalu implementasinya diserahkan kepada AI, hasil yang jauh lebih stabil dapat diperoleh. Pembayaran harus dirancang dari sudut pandang bahwa ini bukan “fungsi untuk menerima uang,” melainkan “fungsi yang bertanggung jawab atas uang.”\u003c/p\u003e\n","tags":["Pengembangan AI","Sistem pembayaran","Kebijakan pengembalian dana","Hukum e commerce","Pola gelap"],"faqs":[{"question":"Apa hal pertama yang harus ditentukan saat meminta AI membuat fitur pembayaran?","answer":"Hal pertama yang harus ditentukan adalah alur status pesanan dan status pembayaran. Status seperti menunggu pembayaran, pembayaran selesai, pembayaran gagal, permintaan pembatalan, pengembalian dana sedang diproses, dan pengembalian dana selesai harus didefinisikan agar AI dapat membuat struktur data dan alur layar yang aman."},{"question":"Mengapa berbahaya jika status pesanan hanya dibuat sederhana sebagai pesanan selesai?","answer":"Karena pembayaran nyata memiliki banyak alur pengecualian seperti gagal, batal, pengembalian dana, dan kedaluwarsa. Jika statusnya terlalu sederhana, dapat muncul masalah seperti pembayaran berhasil tetapi tidak ada riwayat pesanan, atau pengembalian dana sudah selesai tetapi di layar pelanggan masih tertulis pembayaran selesai."},{"question":"Apakah aturan pembatalan pembelian dalam 7 hari selalu berlaku dalam e-commerce Korea?","answer":"Secara umum, konsumen dapat membatalkan pembelian dalam waktu 7 hari sejak tanggal acuan yang ditetapkan oleh hukum. Namun, konten digital, produk yang dibuat khusus, produk yang nilainya berkurang karena penggunaan, dan sejenisnya dapat menjadi pengecualian, sehingga perlu ditinjau secara individual termasuk persyaratan pemberitahuan sebelumnya dan persetujuan."},{"question":"Sampai kapan pengembalian dana harus diproses?","answer":"Dalam e-commerce Korea, pelaku usaha harus mengembalikan pembayaran dalam batas waktu hukum setelah alasan pengembalian dana terjadi, dan dalam praktiknya lebih aman untuk mencerminkan standar 3 hari kerja pada layar admin dan notifikasi. Jika terjadi keterlambatan, dapat timbul masalah kompensasi keterlambatan, sehingga sebaiknya disediakan fitur peringatan otomatis."},{"question":"Apa item yang paling sering menjadi masalah dalam pengembalian dana sebagian?","answer":"Kupon untuk seluruh pesanan, syarat gratis ongkir, biaya pengiriman retur, jumlah poin yang digunakan, dan alokasi diskon per produk sering menjadi masalah. Agar operator tidak perlu menilai setiap kali ada permintaan pengembalian dana, aturan seperti berdasarkan jumlah pembayaran aktual per produk atau metode pembagian proporsional harus ditetapkan terlebih dahulu."},{"question":"Apakah pembayaran ganda dapat dicegah hanya dengan menonaktifkan tombol di frontend?","answer":"Menonaktifkan tombol memang membantu, tetapi tidak cukup. Karena dapat terjadi percobaan ulang jaringan, refresh, dan penerimaan webhook berulang, diperlukan juga penguncian pesanan di sisi server, kunci idempotensi, batasan nomor transaksi unik, serta verifikasi berbasis status."},{"question":"Apa saja yang harus ada dalam teks pemberitahuan pembayaran gagal?","answer":"Harus mencakup apakah pembayaran belum selesai, apa alasan kegagalannya, apakah boleh mencoba lagi, berapa lama pesanan dipertahankan, dan nomor pesanan apa yang diperlukan saat menghubungi layanan. Jika hanya menampilkan teks bahwa terjadi kesalahan, pelanggan dapat pergi dan jumlah pertanyaan akan meningkat."},{"question":"Mengapa halaman riwayat pembayaran wajib ada?","answer":"Karena pelanggan harus dapat memeriksa sendiri kapan dan berapa jumlah yang dibayarkan serta sejauh mana pengembalian dana telah diproses. Jika tidak ada halaman riwayat pembayaran, semua permintaan konfirmasi akan menumpuk di pusat layanan pelanggan, dan pelanggan dapat merasa bahwa layanan tidak mengelola alur uang dengan baik."},{"question":"Apakah cukup jika aturan pengembalian dana hanya ada di halaman syarat dan ketentuan?","answer":"Tidak cukup. Pelanggan harus dapat dengan mudah memeriksa periode pengembalian dana yang tersedia dan ketentuan pembatasan di halaman detail produk, formulir pesanan, dan dekat tombol pembayaran saat mereka memutuskan untuk membeli. Jika aturan pengembalian dana disembunyikan atau tombol pembatalan dibuat sulit ditemukan, dapat muncul kontroversi dark pattern."},{"question":"Kalimat apa yang wajib dimasukkan dalam prompt AI?","answer":"Sebaiknya masukkan kalimat yang meminta AI untuk bertanya terlebih dahulu sebelum menulis kode jika ada kebijakan yang belum ditentukan. Kalimat ini adalah pengaman yang membuat AI menanyakan kembali kebijakan yang mudah terlewat, seperti metode persetujuan pengembalian dana, standar pemotongan biaya pengiriman, dan pengecualian transisi status."},{"question":"Fitur pengembalian dana apa saja yang diperlukan pada layar admin?","answer":"Diperlukan daftar pengembalian dana yang menunggu, tanggal pengajuan, tenggat pemrosesan, notifikasi mendekati tenggat, pratinjau perhitungan pengembalian dana sebagian, alasan pengembalian dana, log petugas pemroses, dan manajemen hak akses. Karena pengembalian dana adalah pekerjaan operasional berulang, jika layar admin kurang memadai, sulit untuk memenuhi tenggat hukum dan menjaga kualitas respons pelanggan."},{"question":"Apakah aturan pengembalian dana dapat diterapkan sama untuk pembayaran konten digital?","answer":"Pada konten digital, pembatasan pembatalan pembelian dapat menjadi masalah tergantung pada apakah penyediaan sudah dimulai, pemberitahuan sebelumnya, dan persetujuan pelanggan. Karena itu, pada layar sebelum pembayaran, ketentuan pembatasan pengembalian dana harus diberitahukan dengan jelas, dan implementasinya harus mencatat waktu persetujuan serta versi syarat dan ketentuan."}],"sources":[{"url":"https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률","title":"Pusat Informasi Hukum Nasional: Undang-Undang tentang Perlindungan Konsumen dalam Perdagangan Elektronik, dll.","type":"source"},{"url":"https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률시행령","title":"Pusat Informasi Hukum Nasional: Peraturan Pelaksanaan Undang-Undang tentang Perlindungan Konsumen dalam Perdagangan Elektronik, dll.","type":"source"},{"url":"https://stripe.com/docs/idempotency","title":"Stripe Docs: Permintaan idempoten","type":"source"},{"url":"https://docs.tosspayments.com/guides/v2/get-started/payment-flow","title":"Toss Payments Docs: Alur integrasi pembayaran","type":"source"},{"url":"https://www.ftc.go.kr/","title":"Komisi Perdagangan Adil","type":"source"}],"images":[{"id":252,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjQ5NCwicHVyIjoiYmxvYl9pZCJ9fQ==--29af039afe5bc5fc5481b1fee11ed2dbd406a900/ai-bac80653.webp","is_representative":true,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"결제·배송·보안 아이콘과 연결된 중앙의 AI 두뇌 일러스트","caption":"AI 두뇌가 쇼핑, 카드 결제, 배송, 보안 등 결제 흐름의 요소와 연결되어 있다.","description":null},"en":{"alt":"Central AI brain connected to payment, shopping, delivery, security, and support icons","caption":"The illustration links an AI brain to key parts of an online payment flow.","description":null},"ja":{"alt":"決済、買い物、配送、セキュリティのアイコンにつながる中央のAI脳","caption":"AIの脳がオンライン決済フローの主要な要素につながっている。","description":null},"es":{"alt":"Cerebro de IA central conectado a iconos de pago, compras, entrega, seguridad y soporte","caption":"La ilustración conecta un cerebro de IA con partes clave del flujo de pago en línea.","description":null},"id":{"alt":"Otak AI di tengah terhubung ke ikon pembayaran, belanja, pengiriman, keamanan, dan dukungan","caption":"Ilustrasi ini menghubungkan otak AI dengan bagian penting dalam alur pembayaran online.","description":null},"pt":{"alt":"Cérebro de IA central conectado a ícones de pagamento, compras, entrega, segurança e suporte","caption":"A ilustração liga um cérebro de IA a etapas importantes do fluxo de pagamento online.","description":null},"zh-hant":{"alt":"中央 AI 大腦連接付款、購物、配送、安全與客服圖示","caption":"插圖呈現 AI 大腦與線上付款流程中的關鍵元素相連。","description":null}}},{"id":253,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjUwMCwicHVyIjoiYmxvYl9pZCJ9fQ==--a75febd0315285ecae10a5682f4409174d119e4c/ai-363d820f.webp","is_representative":false,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"결제 화면을 중심으로 보안, 분석, 구독, 배송, 오류 흐름이 연결된 일러스트","caption":"AI로 결제 기능을 설계할 때 고려할 핵심 요소들을 한눈에 보여준다.","description":null},"en":{"alt":"Checkout screen connected to panels for security, analytics, subscriptions, delivery, and errors","caption":"The illustration summarizes key areas to decide before building AI-powered payments.","description":null},"ja":{"alt":"決済画面を中心に、セキュリティ、分析、定期課金、配送、エラーがつながるイラスト","caption":"AIで決済機能を作る前に決めるべき要素を整理して示している。","description":null},"es":{"alt":"Pantalla de pago conectada con paneles de seguridad, análisis, suscripción, envío y errores","caption":"La ilustración resume aspectos clave antes de crear pagos con IA.","description":null},"id":{"alt":"Layar checkout terhubung ke panel keamanan, analitik, langganan, pengiriman, dan kesalahan","caption":"Ilustrasi ini merangkum hal penting sebelum membangun pembayaran dengan AI.","description":null},"pt":{"alt":"Tela de checkout conectada a painéis de segurança, análise, assinatura, entrega e erros","caption":"A ilustração resume decisões importantes antes de criar pagamentos com IA.","description":null},"zh-hant":{"alt":"結帳畫面連接安全、分析、訂閱、配送與錯誤流程面板的插圖","caption":"這張插圖概述用 AI 建立付款功能前需先決定的重點。","description":null}}}],"published_at":"2026-07-22T08:42:09+09:00","updated_at":"2026-07-22T08:42:09+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant"],"url":"https://injoys.com/en/articles/ai-payment-feature-7-core-decisions"}