Loading
Authorized dan captured: fahami pegangan dana sebelum menganggap pesanan sudah dibayar
TrustFinance Research Team
Okt 12, 2026
5 min read
6
Authorized lazimnya bermaksud aliran pembayaran yang layak telah meluluskan dan menahan suatu jumlah pada kaedah pembayaran pelanggan. Captured bermaksud kutipan telah bergerak melepasi peringkat kebenaran sahaja. Kedua-duanya tidak membuktikan wang sudah masuk ke bank peniaga.
Baca takrif penyedia sebelum bertindak. Permintaan capture, penerimaan permintaan dan hasil pemprosesan akhirnya boleh menjadi peristiwa berbeza. Nama dalam panduan ini menerangkan peringkat, bukan mendakwa semua sistem menggunakan status serupa.
Baca pembayaran mengikut urutan
Penyata kad boleh memaparkan pegangan sementara seperti caj yang telah selesai. Tangkapan skrin pelanggan membantu semakan, tetapi padankan dengan sejarah pembayaran penyedia sebelum menandakan pesanan dibayar berdasarkan rupa semata-mata.
Hubungkan nombor pesanan, rujukan kebenaran dan rujukan capture. Padankan rekod penyelesaian dan pembayaran keluar secara berasingan. Satu jumlah jualan pada papan pemuka tidak menunjukkan sama ada setiap transaksi sudah diterima bank.
| Peringkat | Perkara disemak | Perkara belum dibuktikan |
|---|---|---|
| Authorized | Tempahan dana yang layak dan masa luput | Wang diterima bank peniaga |
| Permintaan capture | Rujukan permintaan dan hasil pemprosesan | Kejayaan daripada penerimaan sahaja |
| Captured | Status capture disahkan dan sejarah seterusnya | Penyelesaian, pembayaran keluar atau tiada pertikaian |
| Penyelesaian | Rekod baki atau penyelesaian penyedia | Wang sudah dikreditkan ke bank |
| Pembayaran keluar | Rujukan pembayaran dipadankan dengan penerimaan bank | Wang diterima hanya kerana pembayaran dihantar |
Semak sokongan, jumlah dan tamat tempoh
Semak dahulu sama ada kaedah pembayaran, akaun peniaga dan transaksi menyokong capture berasingan. Sesetengah kaedah membuat kutipan automatik atau tidak menyediakan capture manual. Keupayaan kad tidak semestinya tersedia untuk semua debit bank atau dompet.
Pastikan tetapan capture bagi transaksi sebenar. Capture automatik, automatik tertangguh dan manual mempunyai tanggungjawab susulan yang berbeza. Tetapan lalai akaun mungkin berbeza daripada tetapan transaksi yang dibenarkan; pengesahan pesanan tidak menggantikan semakan.
Cari masa tamat tempoh transaksi dan zon waktu sebenar. Rangkaian kad, jenis transaksi, negara dan peraturan penyedia boleh mempengaruhi tempoh sah. Jangan gunakan tujuh hari atau 28 hari sebagai tarikh akhir sejagat.
Kebenaran lanjutan dan beberapa capture separa mempunyai syarat. Semak kelayakan serta tetapan yang diaktifkan sebelum bergantung padanya. Jadual penghantaran yang panjang tidak memanjangkan pegangan sedia ada dengan sendirinya.
Semak mata wang, jumlah diluluskan, jumlah yang masih boleh dikutip dan rujukan yang sepadan. Kebenaran dibatalkan atau luput, jumlah tidak disokong atau mata wang berbeza boleh menyebabkan operasi gagal.
Pengakuan penerimaan secara tak segerak bukan bukti selesai. Adyen, misalnya, membezakan permintaan diterima daripada hasil webhook dan menerangkan kemungkinan CAPTURE_FAILED kemudian. Semak hasil sebenar serta sejarah selepasnya.
Contoh hipotetikal pesanan 1,200 unit
Bayangkan pesanan kad yang layak sebanyak 1,200 unit mata wang. Kebenaran berlaku Hari 1 pada 10:00 UTC; contoh capture berlaku Hari 2 pada 10:00 UTC. Anggap tamat tempoh Hari 3 pada 18:00 UTC. Semua angka dan waktu adalah rekaan.
Pada peringkat awal, rekodkan 1,200 diluluskan dan sifar dikutip. Ini tempahan dana di pihak pelanggan, bukan tunai peniaga 1,200 atau rizab pemproses. Fi dan cukai dikecualikan daripada model untuk kejelasan, bukan dinyatakan percuma.
Dalam pilihan capture separa, anggap penyedia mengesahkan pemprosesan kutipan 900 dan aliran rekaan hanya membenarkan satu capture separa. Baki tidak digunakan sebanyak 300 dibatalkan atau dilepaskan menurut andaian itu: 1,200 tolak 900 ialah 300.
Dalam pilihan lain, peniaga membatalkan seluruh kebenaran sebelum sebarang capture. Pegangan 1,200 melalui proses pembatalan atau pelepasan yang disokong. Tiada pembayaran yang telah dikutip untuk dibayar balik; masa bank memaparkan pelepasan tidak ditetapkan.
Pilihan lain tidak melakukan capture sebelum tarikh akhir rekaan. Kebenaran luput dan pegangan lama tidak boleh terus dikutip selepas itu. Kebenaran baharu, jika dibenarkan, memerlukan proses penyedia serta kebenaran pelanggan yang sesuai.
Pilihan ini adalah alternatif, bukan jumlah untuk dicampurkan. Baki 300 dalam model bukan bayaran balik daripada 900 yang dikutip. Pengesahan capture masih memerlukan semakan penyelesaian dan pembayaran ke bank secara berasingan.
| Pilihan alternatif | Jumlah dikutip | Kebenaran tidak digunakan | Semakan berasingan |
|---|---|---|---|
| Capture separa Hari 2 | 900 | 300 dibatalkan/dilepaskan dengan andaian satu capture | Hasil capture, penyelesaian dan penerimaan bank |
| Batal sebelum capture | 0 | 1,200 melalui pembatalan/pelepasan | Status penyedia dan bank pelanggan |
| Tiada capture sebelum Hari 3 18:00 UTC | 0 | 1,200 luput menurut tarikh akhir rekaan | Pembayaran baharu memerlukan proses sah |
Rutin semakan peniaga
Tetapkan dasar penyerahan yang didokumenkan untuk perniagaan dan kaedah pembayaran anda. Sesetengah aliran menyokong capture sekitar penghantaran, manakala yang lain berbeza. Kebenaran sahaja bukan alasan menjanjikan penyerahan atau perlindungan kewangan.
Jika capture gagal atau hasil tidak pasti, semak sejarah pembayaran asal sebelum mencuba semula atau membuat caj lain. Padankan rujukan dan jumlah supaya khidmat pelanggan tidak membuat kutipan berganda tanpa sengaja.
Selepas pembayaran dikutip, gunakan proses bayaran balik atau pembalikan yang disokong penyedia apabila sesuai. Membatalkan pesanan dalam sistem kedai sahaja tidak membatalkan kebenaran atau mengembalikan pembayaran yang telah dikutip secara automatik.
Jika pelanggan masih melihat pegangan selepas pembatalan, berikan rujukan transaksi, jumlah dan cap masa yang dibenarkan untuk susulan penyedia atau bank. Jangan janjikan pelepasan serta-merta atau meminta butiran kad lengkap.
- Padankan rujukan pesanan, kebenaran dan capture.
- Rekod jumlah diluluskan dan jumlah yang masih boleh dikutip.
- Simpan masa luput sebenar serta zon waktu.
- Sahkan kelayakan kaedah dan tetapan capture.
- Semak penerimaan permintaan, hasil dan kegagalan kemudian.
- Asingkan baki dibatalkan atau dilepaskan daripada bayaran balik.
- Padankan penyelesaian, pembayaran keluar dan penerimaan bank sebenar.
Soalan lazim
Pelanggan melihat debit. Adakah itu membuktikan capture?
Tidak semestinya. Paparan pengeluar kad boleh mengaburkan tempahan dana dengan caj yang telah dicatat. Bandingkan status pembayaran, capture dan pembatalan transaksi tepat; jelaskan bukti semasa tanpa menjanjikan masa pemprosesan bank.
Bolehkah baki 300 dikutip kemudian?
Hanya jika aliran sebenar menyokong capture tambahan dan kebenaran masih boleh digunakan. Contoh ini jelas membenarkan satu capture separa lalu melepaskan baki. Jangan anggap 300 tersebut tersedia secara automatik untuk capture seterusnya.
Teruskan dengan soalan yang sesuai
Selepas status capture dikenal pasti, baca Penyelesaian, bayaran balik dan chargeback tentang penyelesaian dan tunai bank, serta Jumlah kos payment gateway tentang fi dan dana peniaga yang disekat. Panduan neutral lain tersedia di TrustFinance Blog.
Sumber dan skop
Halaman rasmi berikut menerangkan mekanisme khusus penyedia yang disemak pada 12 Oktober 2026. Ia tidak menetapkan tarikh akhir sejagat, hak pengguna tempatan atau jaminan penerimaan wang. Sahkan syarat entiti kontrak, akaun dan kaedah pembayaran sendiri.
Ditulis oleh
TrustFinance Research Team
Official TrustFinance research and editorial team, sharing insights, analysis, and best practices to help financial companies and traders build transparency, credibility, and growth.
