Pembatalan pesanan API jika klien mengirim tautan yang salah

Pertama, periksa apakah pesanan sudah dikirim ke pemasok

Tautan yang salah tidak selalu berarti promosi sudah dimulai. Di basis data internal, pesanan mungkin sudah dibuat tetapi belum dikirim melalui API. Dalam hal ini, pembatalan hanya bergantung pada logika pemrosesan Anda: cukup tandai pesanan sebagai dibatalkan, hentikan pembayaran otomatis, dan jangan memulai pengiriman.

Periksa ID pesanan, waktu pembuatan, tautan, jenis layanan, dan log permintaan API. Jika permintaan ke pemasok belum terkirim, jangan membuat pesanan baru di atas pesanan lama. Pertama, catat pembatalan permintaan awal, jika tidak klien bisa mendapatkan dua peluncuran pada tautan yang berbeda.

Tentukan status pesanan di pemasok

Jika permintaan API sudah terkirim, minta status terkini dari pemasok. Nama status berbeda-beda, tetapi biasanya dapat dibagi menjadi beberapa kelompok: menunggu, diproses, eksekusi sebagian, selesai, dan dibatalkan. Untuk keputusan, yang penting bukan status di panel Anda, melainkan respons dari pihak yang menjalankan layanan.

• Menunggu: pesanan mungkin masih dapat dibatalkan.
• Diproses: penghentian kadang mungkin dilakukan, tetapi sebagian volume mungkin sudah dijalankan.
• Eksekusi sebagian: hanya sisa yang dapat dibatalkan, jika pemasok mendukung operasi tersebut.
• Selesai: memperbaiki tautan melalui pembatalan sudah tidak mungkin.

Kekurangan memeriksa hanya berdasarkan status internal adalah status tersebut dapat diperbarui dengan jeda. Berpedomanlah pada respons API terakhir dan waktu penerimaannya.

Batalkan pesanan sebelum layanan dimulai

Untuk pesanan dalam antrean, gunakan metode pembatalan jika disediakan oleh dokumentasi pemasok. Kirimkan ID yang diterima saat pembuatan pesanan, bukan nomor internal Anda, jika keduanya berbeda. Simpan respons lengkap: kode operasi, status, teks kesalahan, dan waktu permintaan.

Jangan anggap pesanan sudah dibatalkan sampai API mengonfirmasi pembatalan. Respons penerimaan permintaan dan penghentian layanan yang sebenarnya bisa menjadi peristiwa yang berbeda. Dalam beberapa integrasi, konfirmasi penerimaan datang lebih dulu, dan status akhir berubah kemudian.

Kekurangan opsi ini adalah pemasok mungkin tidak sempat menarik pesanan dari pemrosesan. Maka pembatalan akan mengembalikan penolakan atau hanya berlaku untuk bagian yang belum dieksekusi.

Jangan ubah tautan pada pesanan yang sudah dibuat tanpa konfirmasi

Pada banyak API, tautan dikunci pada saat pesanan dibuat. Upaya mengirim tautan baru dengan ID yang sama dapat diabaikan, diproses sebagai kesalahan, atau menciptakan keadaan yang tidak terduga. Jangan mengandalkan bahwa pengiriman ulang permintaan akan otomatis mengganti alamat.

Jika dokumentasi secara langsung mendukung pengeditan tautan, pertama pastikan layanan belum mulai dijalankan. Kemudian simpan nilai lama, nilai baru, dan respons API. Ini akan berguna saat berdebat dengan klien atau pemasok.

Kekurangan pengeditan adalah bahkan dengan metode yang tersedia, sebagian tindakan mungkin sudah mengarah ke halaman lama sebelum pembaruan. Tautan yang diperbaiki tidak memindahkan hasil yang sudah diperoleh.

Apa yang harus dilakukan saat eksekusi sebagian

Ketika promosi sudah dimulai pada tautan yang salah, minta pembatalan sisa. Dalam permohonan ke pemasok, sertakan ID pesanan, tautan yang salah, tautan yang benar, status terkini, dan waktu kesalahan ditemukan. Jangan mengubah detail permohonan beberapa kali: ini mempersulit pemeriksaan riwayat.

Jika pembatalan sisa dikonfirmasi, catat volume yang sudah dieksekusi. Pengembalian dana, jika diatur oleh aturan pemasok, biasanya hanya berlaku untuk bagian yang belum dieksekusi. Volume yang sudah dieksekusi tidak dapat secara teknis dipindahkan dari satu kanal, video, atau profil ke yang lain.

Kekurangan pembatalan sebagian jelas: klien mungkin sudah mendapatkan hasil pada halaman yang salah, dan anggaran untuk bagian pesanan ini tidak selalu dikembalikan.

Jika pesanan sudah selesai, ajukan perbaikan sebagai permintaan terpisah

Pesanan yang sudah selesai biasanya tidak dapat dibatalkan melalui API. Dalam situasi seperti ini, jangan hapus catatan dan jangan ubah tautan dalam riwayat: data awal diperlukan untuk rekonsiliasi. Periksa apakah layanan benar-benar diberikan ke alamat yang salah, bukan hanya ditampilkan dengan jeda.

Selanjutnya ada dua jalur: membahas kompensasi dengan pemasok sesuai aturannya atau membuat pesanan baru pada tautan yang benar setelah disetujui dengan klien. Pesanan baru harus memiliki ID terpisah, jumlah, dan catatan yang jelas tentang alasan pembuatannya.

Kekurangan peluncuran baru — memerlukan anggaran tambahan, dan kompensasi untuk layanan yang sudah selesai mungkin tidak tersedia.

Beri tahu klien tentang situasinya sebelum peluncuran ulang

Jangan meluncurkan pengganti atas kebijaksanaan Anda sendiri jika tautan milik klien dan kesalahan berasal dari pihaknya. Kirimkan kepadanya tautan awal, status pesanan, kemungkinan pembatalan, dan konsekuensi dari setiap opsi. Ini sangat penting jika sebagian layanan sudah dieksekusi.

• Jika pesanan belum dikirim, minta tautan yang benar dan konfirmasikan pembatalan permintaan lama.
• Jika pesanan dalam antrean, beri tahu bahwa pembatalan telah dikirim, tetapi masih menunggu respons pemasok.
• Jika ada eksekusi sebagian, tunjukkan bahwa hanya sisa yang dapat dihentikan.
• Jika pesanan sudah selesai, sepakati peluncuran baru atau cara penyelesaian lain.

Kekurangan koordinasi yang lama — selama waktu itu pesanan dalam antrean dapat beralih ke pemrosesan. Karena itu, pertama kirimkan permintaan teknis untuk pembatalan jika ada kemungkinan, lalu klarifikasi tindakan selanjutnya.

Simpan log dan bukti untuk operasi tersebut

Untuk setiap pesanan yang disengketakan, simpan tautan awal dari klien, tanggal penerimaan, nomor internal, ID di pemasok, permintaan dan respons API. Jika klien mengirim tautan dalam percakapan, jangan ganti pesan dengan versi yang diedit di kartu pesanan tanpa menyimpan aslinya.

Catat secara terpisah siapa dan kapan yang menemukan kesalahan. Ini membantu memisahkan data yang dikirim salah dari kesalahan manajer, formulir pesanan, atau pengisian otomatis. Saat menghubungi pemasok berulang kali, gunakan satu rangkaian data agar tidak terjadi kontradiksi.

Kekurangan pencatatan log secara manual — memakan waktu. Tetapi tanpa riwayat, lebih sulit mengonfirmasi status pembatalan dan menjelaskan kepada klien mengapa dana tidak dapat dikembalikan sepenuhnya.

Periksa penanganan kesalahan dalam integrasi

Setelah kasus seperti ini, periksa bagaimana sistem mengirimkan tautan ke API. Kesalahan dapat muncul bukan hanya karena klien: kadang formulir memotong parameter, mengganti dengan nilai lama dari cache, menerima tautan profil alih-alih tautan publikasi, atau meloloskan tautan dengan karakter berlebih.

Tambahkan validasi format sebelum membuat pesanan: kesesuaian dengan platform, jenis layanan, dan objek yang diharapkan. Untuk layanan pada video, sistem harus membedakan tautan video dari tautan kanal, dan untuk media sosial — profil dari publikasi tertentu. Validasi tidak menjamin tautan benar, tetapi menyaring sebagian kesalahan yang jelas.

Pengiriman pesanan sebaiknya dipisahkan dari pembuatannya dengan pemeriksaan data singkat. Kekurangan langkah tambahan — pesanan tidak akan langsung masuk ke pengerjaan, tetapi Anda akan punya waktu untuk menyadari alamat yang salah.

Siapkan skenario pembatalan yang jelas untuk tim

Jelaskan prosedur tindakan yang seragam: hentikan pengiriman otomatis, periksa status di pemasok, kirim pembatalan, simpan respons, beri tahu klien, dan baru kemudian sepakati peluncuran ulang. Skenario seperti ini diperlukan bukan untuk formalitas, tetapi agar karyawan yang berbeda tidak melakukan tindakan yang saling bertentangan.

Jangan berikan akses ke pembatalan tanpa pembatasan hak dan log tindakan. Jika beberapa manajer bekerja pada satu pesanan secara bersamaan, satu dapat meminta pembatalan, sementara yang lain membuat pengganti sebelum menerima respons. Ini menyebabkan biaya tambahan dan kebingungan dalam perhitungan.

Kekurangan skenario yang ketat — kurang fleksibilitas dalam kasus mendesak. Tetapi untuk pesanan API, yang lebih penting bukan kecepatan tindakan individu, melainkan kontrol atas tautan mana yang sebenarnya masuk ke pengerjaan.