Panduan Narrapedia

Cara Mengirim Produk Digital Otomatis setelah Pembayaran

Pengiriman produk digital otomatis terjadi ketika sistem menghubungkan pembayaran yang sudah terverifikasi dengan stok atau file yang boleh diakses pembeli. Alurnya bukan sekadar membuat tombol download: aplikasi perlu memeriksa signature atau status transaksi, mencegah event ganda, membuat akses terbatas, dan memberi jalur pemulihan ketika email atau provider bermasalah.

Topik utama: cara mengirim produk digital otomatis setelah pembayaranpengiriman produk digital otomatisauto download setelah bayarlink download produk digital

Alur otomatis dari invoice sampai akses pembeli

Pembeli membuat order dan menerima invoice. Payment gateway kemudian memproses transaksi dan mengirim callback atau menyediakan endpoint status. Server toko memverifikasi data tersebut, mengubah status order menjadi paid, lalu membuat akses yang terhubung dengan produk atau stok.

Urutan ini penting karena halaman browser pembeli dapat ditutup, dimuat ulang, atau dimanipulasi. Sumber kebenaran pembayaran harus berasal dari server dan provider, bukan dari parameter URL atau tombol yang diklik pengguna.

  1. Buat order dengan merchant reference yang unik.
  2. Buat invoice menggunakan nominal yang dihitung ulang di server.
  3. Terima callback atau polling status dari gateway.
  4. Verifikasi signature, reference, nominal, dan status pembayaran.
  5. Alokasikan stok, buat token, kirim email, dan catat hasilnya.

Mengapa webhook harus idempotent?

Provider dapat mengirim callback lebih dari sekali karena retry jaringan atau timeout. Jika setiap callback membuat token dan mengurangi stok tanpa pemeriksaan, satu pembayaran dapat menghasilkan dua pengiriman atau stok negatif.

Simpan event ID atau kombinasi reference dan status yang sudah diproses. Gunakan transaksi database untuk memastikan hanya satu proses yang mengubah order menjadi paid dan mengambil stok. Bila event yang sama masuk lagi, balas sukses tanpa mengulang fulfillment.

  • Reference order harus unik dan tidak dapat dipakai untuk order lain.
  • Signature diverifikasi menggunakan secret di server.
  • Perubahan status dan alokasi stok dilakukan dalam transaksi.
  • Event yang sudah diproses dapat dikenali saat retry.

Rancang token download dengan expiry dan kuota

Token download adalah lapisan akses setelah pembayaran, bukan pengganti otorisasi pembayaran. Endpoint harus memeriksa bahwa token valid, order lunas, token belum kedaluwarsa, dan jumlah unduhan belum melebihi batas. Rate limit membantu mengurangi percobaan otomatis.

Masa berlaku dan kuota harus dijelaskan kepada pembeli melalui halaman status dan email. Sediakan cara membuat link baru setelah token kedaluwarsa tanpa membuat order baru, tetapi pastikan kebijakan tersebut tercatat dan tidak membuka akses ke order orang lain.

KontrolTujuan
Token acakMencegah akses dengan ID order yang mudah ditebak.
ExpiryMembatasi masa akses link yang dibagikan.
Download counterMembatasi jumlah pemakaian sesuai kebijakan produk.
Rate limitMengurangi scraping dan permintaan berulang.
No-store headersMencegah cache browser atau proxy menyimpan respons sensitif.

Email otomatis harus dapat dipulihkan

Email dapat terlambat, masuk spam, atau gagal karena provider sedang bermasalah. Simpan status pengiriman dan sediakan tombol kirim ulang untuk admin. Tombol tersebut harus menggunakan token atau fulfillment yang sama jika aksesnya masih sah, bukan selalu menerbitkan akses baru.

Isi email sebaiknya ringkas: nama produk, nomor order, tombol akses, masa berlaku, batas unduhan, dan kontak bantuan. Jangan menulis secret, private key, atau credential provider ke dalam email.

Siapkan jalur failure dan manual review

Otomatisasi yang baik tidak memaksa sistem mengambil keputusan ketika datanya ambigu. Payment callback dengan nominal berbeda, produk tanpa stok, file Drive yang tidak dapat diakses, atau email yang ditolak harus masuk ke status yang dapat ditinjau admin. Jangan mengirim file secara otomatis jika bukti pembayaran belum lengkap.

Buat daftar alasan manual review dan tindakan untuk masing-masing alasan. Admin perlu melihat reference, response provider, waktu kejadian, serta tindakan yang sudah dicoba. Setelah masalah selesai, simpan hasilnya agar kasus serupa dapat diproses dengan aturan yang lebih baik.

  • Callback invalid: tolak dan simpan alasan tanpa mengubah order.
  • Nominal berbeda: tahan fulfillment sampai rekonsiliasi selesai.
  • Stok kosong: tandai order untuk refund atau penggantian yang disetujui.
  • Email gagal: retry dengan backoff dan sediakan kirim ulang manual.
  • File tidak tersedia: hentikan link dan beri pesan dukungan yang jelas.

Pilih arsitektur storage sesuai tingkat risiko

Untuk katalog kecil dengan file yang tidak sangat sensitif, Google Drive dapat mengurangi kebutuhan mengelola storage. Untuk source code berlisensi, data pelanggan, atau file yang bernilai tinggi, kontrol akses yang lebih ketat mungkin sepadan dengan biaya storage dan bandwidth tambahan.

Bandingkan bukan hanya harga penyimpanan, tetapi juga signed URL, expiry di sisi storage, logging, backup, bandwidth, pemulihan, dan kemampuan memindahkan file. Keputusan storage adalah bagian dari model keamanan dan support, bukan detail implementasi yang boleh dibiarkan tanpa dokumentasi.

Rekonsiliasi pembayaran dan delivery secara berkala

Laporan harian sebaiknya dapat menjawab tiga angka: berapa invoice dibuat, berapa yang benar-benar paid, dan berapa yang sudah menerima akses. Perbedaan di antara angka tersebut tidak selalu merupakan bug, tetapi harus memiliki alasan seperti menunggu callback, email retry, refund, atau manual review.

Jalankan rekonsiliasi menggunakan reference provider dan order internal. Jangan menandai semua order pending sebagai lunas hanya untuk menghapus daftar. Perubahan status harus memiliki jejak siapa atau proses mana yang mengubahnya, kapan dilakukan, dan bukti apa yang digunakan.

  • Bandingkan total nominal provider dengan order paid di database.
  • Cari order paid tanpa fulfillment atau token aktif.
  • Periksa token yang terlalu sering dicoba atau gagal berulang.
  • Catat refund dan penggantian file dalam audit trail.

Google Drive sebagai sumber file: manfaat dan batasan

Google Drive dapat menjadi pilihan sederhana untuk menyimpan ZIP atau berkas besar tanpa mengelola storage sendiri. Aplikasi dapat memvalidasi link berbagi, mengubahnya menjadi direct-download, lalu mengarahkan pembeli setelah token aplikasi lolos pemeriksaan.

Perlu dipahami bahwa setelah redirect, URL Google Drive dapat disalin dan dipakai ulang selama izin file masih terbuka. Untuk file yang membutuhkan proteksi lebih ketat, gunakan storage yang mendukung signed URL atau proxy download dengan kontrol expiry di sisi storage. Pilihan ini memengaruhi biaya dan kompleksitas.

Checklist pengujian sebelum otomatisasi diaktifkan

Uji pembayaran berhasil, gagal, expired, callback ganda, callback terlambat, stok habis, email gagal, token expired, dan batas unduhan. Pastikan admin dapat menemukan order berdasarkan reference dan melihat alasan ketika fulfillment tidak selesai.

Pada DigiStore, pengiriman dilakukan setelah order dinyatakan lunas dan token download memiliki expiry serta kuota. Detail provider, file Google Drive, email, dan deployment tetap harus dikonfigurasi dengan benar pada environment Anda.

  • Gunakan sandbox atau nominal uji yang aman.
  • Simpan log correlation ID tanpa secret.
  • Siapkan retry dan dead-letter atau daftar manual review.
  • Uji backup database dan pemulihan order.

Rujukan dan dokumentasi