AWAITING_USER: Remediasi Otomatis untuk Transaksi yang Ditandai (ID)

Bagian tersulit dari pemantauan transaksi bukanlah menangkap pembayaran yang mencurigakan — melainkan apa yang Anda lakukan selanjutnya. Menolaknya secara langsung berarti Anda memblokir pelanggan berbayar yang mungkin sepenuhnya sah. Membiarkannya berarti Anda telah menerima risiko yang baru saja Anda tandai. Sebagian besar tim menyelesaikan ini dengan antrean manual: seorang analis mengirim email kepada pengguna, menunggu berhari-hari untuk dokumen, dan transaksi tetap beku selama itu.

API Pemantauan Transaksi Didit memiliki status keempat yang dibangun tepat untuk celah ini: AWAITING_USER. Alih-alih persetujuan atau penolakan biner, transaksi yang ditandai dapat dijeda, meminta tindakan spesifik dari pengguna — verifikasi ulang identitas, berikan bukti dana — dan dilanjutkan secara otomatis saat mereka menyelesaikannya. Gesekan hanya terjadi di mana ada risiko, dan biayanya sama $0,02 per transaksi seperti yang lainnya.

Panduan ini menjelaskan bagaimana jalur AWAITING_USER bekerja dan cara mengintegrasikannya ke dalam alur Anda.

Poin-poin Penting

• AWAITING_USER adalah salah satu dari empat status transaksi — bersama dengan APPROVED, IN_REVIEW, dan DECLINED — sehingga remediasi adalah hasil kelas satu, bukan solusi sementara.
• Transaksi yang ditandai dijeda alih-alih gagal, meminta tindakan lanjutan dari pengguna, dan dilanjutkan secara otomatis setelah tindakan diselesaikan.
• Tindakan lanjutan dapat berupa re-KYC, unggahan bukti dana, atau langkah verifikasi apa pun yang dihasilkan pada API /v3/ terpadu.
• Webhook menggerakkan loop — transaction.status.updated aktif ketika transaksi masuk dan keluar AWAITING_USER.
• Status yang sama ada dalam manajemen kasus, sehingga analis dapat memindahkan peringatan ke AWAITING_USER dan membiarkan pengguna menyelesaikannya.
• $0,02 per transaksi, tanpa minimum. Pemeriksaan re-KYC atau AML yang dihasilkan selama remediasi ditagih dengan tarif yang diterbitkan sendiri.

Apa yang dilakukan AWAITING_USER

Ketika suatu aturan aktif, mesin menetapkan status. Tiga dari empat status sudah dikenal: APPROVED memungkinkan transaksi, IN_REVIEW membuka peringatan untuk analis, dan DECLINED memblokirnya. Yang keempat, AWAITING_USER, melakukan sesuatu yang berbeda — menangguhkan transaksi dan memberi sinyal bahwa pengguna harus melakukan sesuatu sebelum dapat diselesaikan.

Secara konkret: transfer memicu aturan nilai tinggi atau kecepatan tinggi, mesin mengembalikan AWAITING_USER, aplikasi Anda meminta pengguna untuk menyelesaikan langkah yang diminta (pemeriksaan liveness baru, unggahan dokumen, deklarasi sumber dana), dan sesi verifikasi diumpankan kembali ke platform. Setelah langkah selesai, transaksi dievaluasi ulang dan berpindah ke APPROVED (atau eskalasi jika bukti baru memperburuk keadaan). Tidak ada analis yang harus mengawasinya.

Mengapa itu penting

Penolakan keras itu mahal. Setiap pemblokiran positif palsu adalah pelanggan sah yang frustrasi, tiket dukungan, dan seringkali akun yang di-churn. Tetapi membiarkan pembayaran yang ditandai berarti perusahaan akan berakhir dalam tindakan penegakan. Perbaikan konvensional — antrean remediasi manual — menukar satu biaya dengan biaya lainnya: waktu analis, waktu penyelesaian yang lambat, dan transaksi yang dibekukan selama berhari-hari.

AWAITING_USER menghilangkan pertukaran itu. Pengguna melakukan pekerjaan, saat itu juga, pada titik gesekan — tepat ketika mereka termotivasi untuk menyelesaikannya karena transaksi mereka sendiri sedang menunggu. Anda menangkap risiko, Anda mempertahankan pelanggan, dan Anda tidak membayar analis untuk mengejar dokumen. Ini adalah perbedaan antara kontrol kepatuhan yang merugikan pelanggan dan yang diam-diam melakukan tugasnya.

Detail teknis

Transaksi yang diarahkan mesin ke remediasi kembali dengan status AWAITING_USER dan aturan yang memicunya:

{
  "transaction_id": "txn_77c9e2",
  "status": "AWAITING_USER",
  "risk_score": 71,
  "triggered_rules": [
    { "name": "Transfer bernilai tinggi — 30 hari pertama", "bundle": "AML/CTF", "action": "CHANGE_STATUS" }
  ],
  "required_action": "PROOF_OF_FUNDS",
  "alert_id": "alrt_5e3f10"
}

Anda bereaksi dengan meminta pengguna dan menghasilkan langkah verifikasi pada API /v3/ terpadu. Ketika langkah selesai, webhook memberi tahu Anda bahwa transaksi telah berlanjut:

# payload webhook: transaction.status.updated
{
  "event": "transaction.status.updated",
  "transaction_id": "txn_77c9e2",
  "previous_status": "AWAITING_USER",
  "status": "APPROVED"
}

Webhook. Berlangganan transaction.created dan transaction.status.updated. Peristiwa status-updated aktif baik ketika transaksi masuk AWAITING_USER maupun ketika keluar — sehingga buku besar dan UI Anda tetap sinkron tanpa polling.

Harga. $0,02 per transaksi. Langkah remediasi itu sendiri ditagih dengan tarif yang diterbitkan sendiri: re-KYC dengan tarif Verifikasi Pengguna, pemeriksaan AML pada pihak yang ditandai dengan $0,20.

Loop remediasi, langkah demi langkah

1. Memicu aturan. Sebuah transaksi melewati ambang batas yang menurut kebijakan Anda harus diremediasi daripada ditolak — misalnya, transfer bernilai tinggi pertama dari akun baru.
2. Jeda, jangan gagal. Mesin mengembalikan AWAITING_USER alih-alih DECLINED, dengan tindakan yang diperlukan terlampir.
3. Minta pengguna. Aplikasi Anda menampilkan langkah lanjutan — pemeriksaan ulang liveness, unggahan dokumen, deklarasi sumber dana — dan menghasilkan sesi verifikasi.
4. Pengguna menyelesaikannya. Pengguna menyelesaikan langkah dalam alur yang sama dengan yang sudah mereka gunakan.
5. Lanjutkan secara otomatis. Transaksi dievaluasi ulang dengan bukti baru dan berpindah ke APPROVED — atau eskalasi ke IN_REVIEW/DECLINED jika bukti meningkatkan risiko. Webhook transaction.status.updated memberi tahu backend Anda dalam kedua kasus.

Karena status AWAITING_USER yang sama ada dalam manajemen kasus, seorang analis yang menangani peringatan IN_REVIEW juga dapat mengembalikannya kepada pengguna alih-alih menyelesaikannya sendiri — peringatan bergerak melalui OPEN → INVESTIGATING → AWAITING_USER dan diselesaikan setelah pengguna merespons.

Contoh kasus penggunaan

• Fintech — transfer bernilai tinggi pertama dari akun yang baru di-onboard dijeda untuk bukti dana daripada memblokir pelanggan.
• Kripto — transfer keluar ke dompet dengan eksposur tinggi dijeda untuk deklarasi sumber dana sebelum diselesaikan.
• Pinjaman — pencairan yang memicu sinyal identitas sintetis dijeda untuk pemeriksaan liveness re-KYC.
• Marketplace — pembayaran penjual yang memicu aturan kecepatan dijeda untuk verifikasi ulang sebelum dana dilepaskan.
• iGaming — lonjakan kecepatan deposit dijeda untuk pemeriksaan bertingkat, yang juga berfungsi sebagai titik kontak permainan yang bertanggung jawab.

Bagaimana cara berintegrasi dengan Didit

1. Tentukan kebijakan remediasi Anda. Di Konsol Bisnis, atur aturan mana yang diarahkan ke AWAITING_USER alih-alih DECLINED, dan tindakan lanjutan mana yang diminta oleh masing-masing.
2. Kirim transaksi. POST /v3/transactions/ saat uang bergerak, dengan transaction_id yang stabil dan vendor_data yang menghubungkan setiap transaksi ke penggunanya.
3. Tangani jeda. Ketika transaksi mengembalikan AWAITING_USER, minta pengguna dan hasilkan langkah verifikasi pada API /v3/.
4. Dengarkan untuk melanjutkan. Bereaksi terhadap transaction.status.updated untuk melepaskan atau menahan transaksi setelah pengguna menyelesaikan langkah.

Karena semuanya ada di API /v3/ terpadu, KYC remediasi yang dihasilkan oleh transaksi yang ditandai adalah KYC yang sama yang Anda gunakan untuk meng-onboard pengguna — satu platform identitas dan penipuan, dari awal hingga akhir.

Pertanyaan yang sering diajukan

Apa itu AWAITING_USER?

Ini adalah salah satu dari empat status transaksi. Alih-alih penolakan langsung, transaksi yang ditandai dijeda dan meminta tindakan pengguna — verifikasi ulang atau bukti dana — kemudian dilanjutkan secara otomatis setelah pengguna menyelesaikannya.

Apakah transaksi dilanjutkan dengan sendirinya?

Ya. Setelah langkah yang diminta selesai, transaksi dievaluasi ulang dan berpindah ke APPROVED secara otomatis — atau eskalasi jika bukti baru meningkatkan risiko. Webhook transaction.status.updated aktif pada perubahan tersebut.

Apa saja yang bisa menjadi langkah lanjutan?

Langkah verifikasi apa pun pada API /v3/ terpadu — pemeriksaan liveness re-KYC, verifikasi ulang dokumen, pemeriksaan AML, atau unggahan bukti dana.

Apakah analis harus terlibat?

Tidak. Loop remediasi otomatis berjalan tanpa analis. Tetapi status AWAITING_USER yang sama ada dalam manajemen kasus, sehingga analis juga dapat mengembalikan peringatan kepada pengguna ketika mereka memilih untuk melakukannya.

Berapa biayanya?

$0,02 per transaksi. Langkah remediasi ditagih dengan tarifnya sendiri — re-KYC dengan tarif Verifikasi Pengguna, pemeriksaan AML dengan $0,20.

Siap untuk memulai?

Baca Ikhtisar Pemantauan Transaksi di dokumen, lihat bagaimana itu sesuai dengan bagian lain dari platform di halaman produk Pemantauan Transaksi, dan periksa harga transparan per panggilan di halaman harga. Ketika Anda siap, mulai gratis — 500 pemeriksaan KYC gratis setiap bulan, dan pemantauan transaksi dengan $0,02 per panggilan.