---
title: "7 hal yang perlu ditentukan terlebih dahulu saat membuat fitur pembayaran dengan AI"
locale: id
category: how_to
category_name: "Panduan"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/ai-payment-feature-7-core-decisions
published_at: 2026-07-22T08:42:09+09:00
---

# 7 hal yang perlu ditentukan terlebih dahulu saat membuat fitur pembayaran dengan AI

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

## 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.

## Ringkasan Inti

Prompt 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.

Secara 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.

| Area keputusan | Pertanyaan yang harus ditentukan terlebih dahulu | Risiko jika gagal |
|---|---|---|
| Status pesanan | Status apa saja yang dilalui pesanan secara berurutan? | Terjadi pesanan hantu: pembayaran berhasil tetapi pesanan tidak ada |
| Batas waktu pengembalian dana | Bagaimana mencerminkan batas waktu pembatalan pembelian dan pemrosesan pengembalian dana? | Pelanggaran batas waktu hukum, bunga keterlambatan, risiko sengketa |
| Pengembalian dana sebagian | Bagaimana menghitung retur sebagian produk, kupon, dan ongkos kirim? | Operator harus menghitung manual setiap kali, pelanggan tidak percaya |
| Pembayaran ganda | Bagaimana mencegah pembayaran tercatat dua kali untuk pesanan yang sama? | Keluhan pelanggan berdasarkan tagihan kartu, kepercayaan menurun |
| Panduan kegagalan | Bagaimana menjelaskan limit terlampaui, saldo tidak cukup, dan kegagalan autentikasi? | Tingkat konversi percobaan ulang menurun, pertanyaan yang tidak perlu meningkat |
| Riwayat pembayaran | Di mana pelanggan memeriksa status pembayaran dan pengembalian dana? | Pertanyaan ke pusat layanan pelanggan meningkat, status tidak transparan |
| Pemberitahuan pengembalian dana | Di mana menempatkan aturan pengembalian dana dan tombol pembatalan? | Kontroversi dark pattern, risiko regulasi |

## 1. Desain status pesanan: status adalah bahasa operasional

Saat 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.

### Contoh status yang direkomendasikan

| Contoh kode status | Status yang terlihat oleh pelanggan | Makna |
|---|---|---|
| `payment_pending` | Menunggu pembayaran | Pesanan sudah dibuat tetapi pembayaran belum selesai |
| `paid` | Pembayaran selesai | Persetujuan pembayaran selesai dan pesanan valid |
| `payment_failed` | Pembayaran gagal | Percobaan pembayaran gagal dan perlu ditentukan apakah bisa dicoba ulang |
| `cancel_requested` | Pembatalan diminta | Pelanggan mengajukan pembatalan dan sedang menunggu pemrosesan |
| `cancelled` | Pembatalan selesai | Pembatalan pesanan sebelum pembayaran atau pembatalan persetujuan selesai |
| `refund_requested` | Pengembalian dana diminta | Permohonan pengembalian dana setelah pembayaran diterima |
| `refund_processing` | Pengembalian dana diproses | Sedang memproses persetujuan pengembalian dana atau pengembalian ke metode pembayaran |
| `partially_refunded` | Pengembalian dana sebagian selesai | Hanya sebagian dari nilai pesanan yang dikembalikan |
| `refunded` | Pengembalian dana selesai | Pemrosesan pengembalian dana selesai |
| `expired` | Pesanan kedaluwarsa | Waktu tunggu pembayaran berlalu dan pesanan menjadi tidak valid |

### Prinsip desain status

- Status pesanan dan status pembayaran tidak dianggap sepenuhnya sama. Pesanan bisa ada tetapi pembayaran gagal, dan pembayaran bisa disetujui tetapi penyimpanan pesanan gagal.
- Setiap perubahan status harus menyimpan waktu kejadian, pemroses, alasan, pengenal transaksi pembayaran, dan pengenal transaksi pengembalian dana.
- Layar pelanggan, layar administrator, dan frasa respons pusat layanan pelanggan harus menggunakan definisi status yang sama.
- Transisi status dirancang satu arah, dan pemulihan pengecualian diproses dengan mencatatnya melalui hak administrator terpisah.

## 2. Pembatalan pembelian dan batas waktu pengembalian dana menurut hukum: bukan kebijakan, melainkan persyaratan hukum

Jika 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.

Standar yang sangat penting dalam praktik adalah sebagai berikut.

- Pada prinsipnya, konsumen dapat membatalkan pembelian dalam 7 hari sejak tanggal standar yang ditentukan hukum, seperti hari penerimaan barang dan sebagainya.
- 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.
- 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.
- Penerapan sebenarnya dapat berbeda tergantung jenis produk, metode kontrak, pemberitahuan yang diberikan kepada konsumen, dan apakah penggunaan sudah dimulai, sehingga diperlukan tinjauan hukum.

### Cara mengubahnya menjadi persyaratan pengembangan

Standar hukum tidak cukup jika hanya ditulis dalam klausul syarat dan ketentuan. Standar tersebut juga harus diubah menjadi persyaratan sistem.

| Persyaratan hukum·kebijakan | Persyaratan sistem |
|---|---|
| Menentukan apakah pembatalan pembelian dapat dilakukan dalam 7 hari | Menghitung otomatis periode pengembalian dana berdasarkan tanggal penerimaan pesanan atau tanggal penyediaan layanan |
| Perlu memproses pengembalian dana dalam 3 hari kerja | Menampilkan tanggal permohonan pengembalian dana dan tenggat pemrosesan di layar administrator |
| Risiko keterlambatan pengembalian dana | Menampilkan notifikasi mendekati tenggat dan melewati tenggat |
| Perlu pemberitahuan untuk produk pengecualian | Menampilkan dengan jelas sebelum pembayaran bahwa produk memiliki pembatasan pengembalian dana dan menyimpan log persetujuan |
| Perlu penanganan sengketa | Menyimpan versi syarat dan ketentuan, waktu pemberitahuan, waktu persetujuan, IP pelanggan atau log akun |

## 3. Aturan pengembalian dana sebagian: kupon, ongkos kirim, dan pajak harus ditentukan terlebih dahulu

Pengembalian 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.

### Hal yang wajib ditentukan

- Bagaimana mengalokasikan jumlah pembayaran per produk
- Apakah kupon untuk seluruh pesanan akan dialokasikan secara proporsional per produk
- Apakah kupon untuk produk tertentu hanya diterapkan pada produk tersebut
- Apakah ongkos kirim akan dikurangkan ketika syarat gratis ongkir tidak lagi terpenuhi
- Bagaimana membedakan ongkos kirim retur karena perubahan pikiran dan ongkos kirim retur karena cacat produk
- Dalam urutan apa pembayaran dengan poin, saldo, dan kartu hadiah akan dikembalikan
- Bagaimana mengubah faktur pajak, kuitansi tunai, dan tampilan kuitansi setelah pengembalian dana sebagian

### Contoh perhitungan pengembalian dana sebagian

| Item | Jumlah |
|---|---:|
| Produk A | 30,000원 |
| Produk B | 70,000원 |
| Kupon seluruh pesanan | -10,000원 |
| Jumlah pembayaran aktual | 90,000원 |

Jika 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.

Tidak 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.

## 4. Pencegahan pembayaran ganda: menonaktifkan tombol saja tidak cukup

Pembayaran 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.

### Penyebab terjadinya

- Pelanggan mengklik tombol pembayaran berulang kali
- Pelanggan menyegarkan halaman atau menekan tombol kembali segera setelah pembayaran
- Permintaan yang sama dikirim ulang karena keterlambatan jaringan seluler
- Respons persetujuan pembayaran berhasil tetapi penyimpanan di server layanan gagal
- Webhook dan redirect klien mengubah status pesanan secara bersamaan

### Desain pertahanan

| Mekanisme pertahanan | Penjelasan |
|---|---|
| Penguncian tombol klien | Mencegah klik ulang setelah tombol pembayaran diklik, tetapi hanya digunakan sebagai sarana pendukung |
| Penguncian pesanan di sisi server | Memastikan permintaan persetujuan pembayaran tidak dijalankan bersamaan untuk ID pesanan yang sama |
| Kunci idempotensi | Menggunakan pengenal agar meski permintaan pembayaran yang sama dikirim beberapa kali, hasil hanya dibuat satu kali |
| Nomor transaksi unik | Mencegah penyimpanan duplikat nomor pesanan dan nomor transaksi pembayaran dengan constraint database |
| Verifikasi berbasis status | Mencegah permintaan persetujuan tambahan untuk pesanan yang sudah `paid` |
| Pemrosesan duplikat webhook | Memastikan perubahan status hanya terjadi satu kali meski event webhook yang sama datang beberapa kali |

Saat 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.”

## 5. Teks panduan kegagalan pembayaran: kegagalan bukan insiden, melainkan alur normal

Kegagalan 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.

Panduan 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.

### Contoh teks panduan

| Situasi | Panduan yang direkomendasikan |
|---|---|
| Saldo tidak cukup | Pembayaran tidak selesai karena saldo metode pembayaran tidak mencukupi. Silakan pilih metode pembayaran lain atau periksa saldo lalu coba lagi. |
| 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. |
| Autentikasi gagal | Pesanan tetap dalam status menunggu pembayaran karena autentikasi pembayaran belum selesai. Anda dapat membayar lagi dalam 30 menit. |
| Kesalahan jaringan | Konfirmasi hasil pembayaran sedang tertunda. Untuk mencegah pembayaran ganda, silakan periksa riwayat pembayaran setelah beberapa saat. |
| Pesanan kedaluwarsa | Pesanan kedaluwarsa karena waktu tunggu pembayaran telah berlalu. Silakan pilih produk lagi dan lakukan pemesanan. |

### Elemen inti panduan kegagalan

- Jelaskan dengan jelas apakah pembayaran benar-benar belum selesai.
- Beri tahu berapa lama pesanan dipertahankan.
- Pandu apakah pelanggan boleh mencoba lagi atau harus menggunakan metode pembayaran lain.
- Tampilkan nomor pesanan yang diperlukan saat menghubungi pusat layanan pelanggan.
- Jika hasil pembayaran tidak pasti, jangan langsung mendorong pembayaran ulang; sediakan status sedang dikonfirmasi.

## 6. Halaman riwayat pembayaran: layar inti untuk mengurangi pusat layanan pelanggan

Jika 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.

### Informasi yang harus disertakan di halaman riwayat pembayaran

- Nomor pesanan
- Tanggal dan waktu pesanan serta tanggal dan waktu pembayaran
- Nama produk, jumlah, opsi
- Metode pembayaran dan nomor persetujuan atau pengenal transaksi
- Nilai produk, diskon, ongkos kirim, jumlah poin yang digunakan, jumlah akhir pembayaran
- Status pesanan saat ini dan status pengembalian dana
- Tanggal permohonan pengembalian dana, tanggal persetujuan pengembalian dana, perkiraan tanggal penyelesaian pengembalian dana
- Apakah pembatalan atau pengembalian dana tersedia
- Tautan untuk memeriksa kuitansi, rincian transaksi, kuitansi tunai
- Informasi yang diperlukan saat menghubungi pusat layanan pelanggan

### Koneksi dengan layar operator

Layar 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.

## 7. Lokasi pemberitahuan aturan pengembalian dana: jika disembunyikan, itu bukan kebijakan melainkan risiko

Aturan 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.

### Lokasi pemberitahuan yang baik

- Di dekat harga atau tombol beli pada halaman detail produk
- Layar keranjang atau formulir pesanan
- Area persetujuan syarat dan ketentuan serta aturan pengembalian dana tepat di atas tombol pembayaran
- Halaman pembayaran selesai
- Layar detail pesanan di my page
- Layar permohonan pengembalian dana

### Desain yang harus dihindari

- Desain yang memungkinkan pendaftaran dan pembayaran dilakukan sekaligus, tetapi penghentian atau pengembalian dana hanya dapat dilakukan melalui telepon pusat layanan pelanggan
- Desain yang menyembunyikan tombol pembatalan di beberapa tahap bagian dalam
- Desain yang baru menampilkan syarat pembatasan pengembalian dana setelah pembayaran
- Desain yang menempatkan warna tombol, teks, dan urutan agar pelanggan salah paham
- Desain yang tidak memberi tahu dengan jelas fakta pembayaran otomatis setelah uji coba gratis berakhir

Desain 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.

## Checklist yang harus dimasukkan dalam prompt untuk AI

Saat meminta alat pengembangan AI mengimplementasikan fungsi pembayaran, sampaikan kebijakan terlebih dahulu seperti di bawah ini.

### Contoh prompt fungsi pembayaran

```text
Implementasikan fungsi pembayaran untuk layanan e-commerce yang ditujukan kepada konsumen Korea.
Pastikan kebijakan berikut tercermin.

1. Status pesanan menggunakan payment_pending, paid, payment_failed, cancel_requested, cancelled, refund_requested, refund_processing, partially_refunded, refunded, expired.
2. Pesanan yang menunggu pembayaran diubah menjadi expired setelah 30 menit.
3. Untuk pesanan yang sama, hanya 1 persetujuan pembayaran yang diizinkan, dan gunakan penguncian pesanan di sisi server serta kunci idempotensi.
4. Webhook pembayaran dapat diterima secara duplikat, jadi ID event yang sama hanya diproses satu kali.
5. Simpan tanggal permohonan pengembalian dana, tenggat pemrosesan pengembalian dana, pemroses, alasan, dan nomor transaksi pengembalian dana.
6. Pengembalian dana sebagian dihitung berdasarkan jumlah pembayaran aktual per produk, dan kupon seluruh pesanan dialokasikan berdasarkan proporsi nilai produk.
7. Saat pembayaran gagal, kembalikan teks panduan pelanggan sesuai alasan kegagalan.
8. Buat agar pelanggan dapat memeriksa riwayat pembayaran dan status pengembalian dana di my page.
9. Tampilkan tautan aturan pengembalian dana dan checkbox persetujuan sebelum pembayaran, lalu simpan waktu persetujuan dan versi syarat dan ketentuan.
10. Jika ada kebijakan yang belum ditentukan, tanyakan terlebih dahulu sebelum menulis kode.
```

Kalimat 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.

## Fungsi yang diperlukan pada layar operator

Fungsi pembayaran tidak selesai hanya dengan layar pelanggan. Pengembalian dana dan pembatalan adalah pekerjaan operasional yang diproses setiap hari, sehingga layar administrator wajib diperlukan.

| Fungsi administrator | Alasan diperlukan |
|---|---|
| Daftar pengembalian dana menunggu | Diperlukan agar kasus pengembalian dana yang harus diproses tidak terlewat |
| Tampilan batas waktu pemrosesan hukum | Diperlukan untuk mengurangi risiko keterlambatan pengembalian dana |
| Peringatan mendekati·melewati tenggat | Diperlukan agar operator segera mengetahui standar internal seperti 3 hari kerja |
| Pemilihan alasan pengembalian dana | Diperlukan untuk statistik dan alokasi biaya seperti perubahan pikiran, cacat produk, salah kirim |
| Pratinjau perhitungan pengembalian dana sebagian | Diperlukan untuk mengurangi kesalahan perhitungan manual oleh operator |
| Log pemrosesan | Diperlukan untuk menangani sengketa dan audit |
| Manajemen hak akses | Diperlukan untuk membatasi persetujuan pengembalian dana dan perubahan status paksa |

## Komposisi minimum model data pembayaran

Struktur data berbeda untuk setiap layanan, tetapi setidaknya data pada tingkat berikut sebaiknya dipisahkan.

| Tabel atau objek | Field inti |
|---|---|
| Pesanan | ID pesanan, ID pelanggan, status pesanan, nilai pesanan, nilai diskon, ongkos kirim, tanggal dan waktu pembuatan, tanggal dan waktu kedaluwarsa |
| Produk pesanan | ID produk, nama produk, opsi, jumlah, nilai per produk, alokasi diskon per produk |
| Pembayaran | ID pembayaran, ID pesanan, metode pembayaran, nomor persetujuan, jumlah persetujuan, status pembayaran, tanggal dan waktu persetujuan |
| Pengembalian dana | ID pengembalian dana, ID pesanan, jumlah pengembalian dana, alasan pengembalian dana, status pengembalian dana, tanggal dan waktu permohonan, tanggal dan waktu selesai |
| Riwayat status | ID target, status sebelumnya, status perubahan, pengubah, alasan perubahan, tanggal dan waktu perubahan |
| Persetujuan syarat dan ketentuan | Jenis syarat dan ketentuan, versi syarat dan ketentuan, status persetujuan, tanggal dan waktu persetujuan, ID pelanggan |

Poin 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.

## Daftar pemeriksaan sebelum peluncuran

- Apakah pembayaran hanya disetujui 1 kali meski tombol pembayaran ditekan 10 kali untuk pesanan yang sama?
- Jika penyimpanan server gagal setelah persetujuan pembayaran, apakah dapat dipulihkan?
- Apakah webhook pembayaran tidak diproses duplikat meski mengirim event yang sama beberapa kali?
- Apakah pelanggan dapat memahami alasan kegagalan pembayaran dan cara mencoba ulang?
- Apakah pesanan yang menunggu pembayaran otomatis kedaluwarsa setelah waktu tertentu?
- Apakah jumlah pengembalian dana sebagian sesuai dengan kebijakan kupon, poin, dan ongkos kirim?
- Apakah tanggal permohonan pengembalian dana hingga tenggat pemrosesan ditampilkan di layar administrator?
- Apakah aturan pengembalian dana dapat diperiksa dengan mudah di layar sebelum pembayaran?
- Apakah konten digital atau produk dengan pembatasan pengembalian dana memiliki pemberitahuan sebelumnya dan log persetujuan?
- Apakah pelanggan dapat langsung memeriksa riwayat pembayaran dan status pengembalian dana di my page?

## Kesimpulan

AI dapat membuat kode fungsi pembayaran dengan cepat. Namun, sistem pembayaran yang beroperasi dengan aman dan legal dimulai dari keputusan kebijakan sebelum kode.

Jika 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.”

## FAQ

### Apa hal pertama yang harus ditentukan saat meminta AI membuat fitur pembayaran?
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.

### Mengapa berbahaya jika status pesanan hanya dibuat sederhana sebagai pesanan selesai?
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.

### Apakah aturan pembatalan pembelian dalam 7 hari selalu berlaku dalam e-commerce Korea?
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.

### Sampai kapan pengembalian dana harus diproses?
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.

### Apa item yang paling sering menjadi masalah dalam pengembalian dana sebagian?
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.

### Apakah pembayaran ganda dapat dicegah hanya dengan menonaktifkan tombol di frontend?
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.

### Apa saja yang harus ada dalam teks pemberitahuan pembayaran gagal?
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.

### Mengapa halaman riwayat pembayaran wajib ada?
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.

### Apakah cukup jika aturan pengembalian dana hanya ada di halaman syarat dan ketentuan?
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.

### Kalimat apa yang wajib dimasukkan dalam prompt AI?
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.

### Fitur pengembalian dana apa saja yang diperlukan pada layar admin?
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.

### Apakah aturan pengembalian dana dapat diterapkan sama untuk pembayaran konten digital?
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

- [Pusat Informasi Hukum Nasional: Undang-Undang tentang Perlindungan Konsumen dalam Perdagangan Elektronik, dll.](https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률)
- [Pusat Informasi Hukum Nasional: Peraturan Pelaksanaan Undang-Undang tentang Perlindungan Konsumen dalam Perdagangan Elektronik, dll.](https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률시행령)
- [Stripe Docs: Permintaan idempoten](https://stripe.com/docs/idempotency)
- [Toss Payments Docs: Alur integrasi pembayaran](https://docs.tosspayments.com/guides/v2/get-started/payment-flow)
- [Komisi Perdagangan Adil](https://www.ftc.go.kr/)

## Images

![Otak AI di tengah terhubung ke ikon pembayaran, belanja, pengiriman, keamanan, dan dukungan](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjQ5NCwicHVyIjoiYmxvYl9pZCJ9fQ==--29af039afe5bc5fc5481b1fee11ed2dbd406a900/ai-bac80653.webp)
![Layar checkout terhubung ke panel keamanan, analitik, langganan, pengiriman, dan kesalahan](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjUwMCwicHVyIjoiYmxvYl9pZCJ9fQ==--a75febd0315285ecae10a5682f4409174d119e4c/ai-363d820f.webp)