Müşteri yanlış bağlantı gönderdiğinde API siparişinin iptali

Önce siparişin tedarikçiye aktarılıp aktarılmadığını kontrol edin

Yanlış bağlantı, promosyonun zaten başlatıldığı anlamına gelmez. Dahili veritabanınızda sipariş oluşturulmuş ancak henüz API üzerinden gönderilmemiş olabilir. Bu durumda iptal yalnızca sizin işleme mantığınıza bağlıdır: siparişi iptal edildi olarak işaretlemek, otomatik ödemeyi durdurmak ve aktarımı başlatmamak yeterlidir.

Sipariş kimliğini, oluşturulma zamanını, bağlantıyı, hizmet türünü ve API istek günlüğünü kontrol edin. Tedarikçiye istek gitmediyse eski siparişin üzerine yeni bir sipariş oluşturmayın. Önce orijinal talebin iptalini kaydedin, aksi halde müşteri farklı bağlantılar için iki kez başlatma alabilir.

Tedarikçideki sipariş durumunu belirleyin

API isteği zaten gönderildiyse tedarikçiden güncel durumu talep edin. Durum adları farklılık gösterir, ancak genellikle birkaç gruba ayrılabilir: bekleme, işleme, kısmi tamamlama, tamamlama ve iptal. Karar için panelinizdeki durum değil, hizmeti başlatan tarafın yanıtı önemlidir.

• Bekleme: sipariş hâlâ iptale izin veriyor olabilir.
• İşleme: durdurma bazen mümkündür, ancak hacmin bir kısmı zaten başlatılmış olabilir.
• Kısmi tamamlama: tedarikçi bu işlemi destekliyorsa yalnızca kalan kısım iptal edilebilir.
• Tamamlama: bağlantı artık iptal yoluyla düzeltilemez.

Yalnızca dahili duruma göre kontrol etmenin dezavantajı, durumun gecikmeyle güncellenebilmesidir. Son API yanıtına ve alınma zamanına göre hareket edin.

Hizmet başlamadan önce siparişi iptal edin

Sıradaki bir sipariş için tedarikçi belgelerinde öngörülmüşse iptal yöntemini kullanın. Farklı değerler ise dahili numaranızı değil, sipariş oluşturulurken alınan kimliği iletin. Tam yanıtı kaydedin: işlem kodu, durum, hata metni ve istek zamanı.

API iptali onaylamadıkça siparişi iptal edilmiş saymayın. Talebin kabul edildiğine dair yanıt ile hizmetin fiilen durdurulması farklı olaylar olabilir. Bazı entegrasyonlarda önce kabul onayı gelir, nihai durum daha sonra değişir.

Bu seçeneğin dezavantajı, tedarikçinin siparişi işlemeden çıkarmaya yetişemeyebilmesidir. Bu durumda iptal reddedilir veya yalnızca yerine getirilmemiş kısım için geçerli olur.

Onay olmadan oluşturulmuş siparişteki bağlantıyı değiştirmeyin

Birçok API'de bağlantı sipariş oluşturulduğu anda sabitlenir. Aynı kimlikle yeni bir bağlantı iletme girişimi yok sayılabilir, hata olarak işlenebilir veya öngörülemeyen bir duruma yol açabilir. İsteğin yeniden gönderilmesinin adresi otomatik olarak değiştireceğini varsaymayın.

Belgeler bağlantı düzenlemeyi açıkça destekliyorsa önce hizmetin henüz çalışmaya başlamadığından emin olun. Ardından eski değeri, yeni değeri ve API yanıtını kaydedin. Bu, müşteri veya tedarikçiyle yaşanacak bir anlaşmazlıkta işinize yarar.

Düzenlemenin dezavantajı, yöntem mevcut olsa bile güncellemeden önce bazı işlemlerin eski sayfaya gitmiş olabilmesidir. Düzeltilmiş bağlantı, zaten elde edilmiş sonucu taşımaz.

Kısmi tamamlama durumunda ne yapmalı

Yanlış bağlantı üzerinden promosyon başladıysa kalan kısmın iptalini talep edin. Tedarikçiye yapacağınız başvuruda sipariş kimliğini, yanlış bağlantıyı, doğru bağlantıyı, mevcut durumu ve hatanın fark edilme zamanını belirtin. Başvurunun ayrıntılarını birkaç kez değiştirmeyin: bu, geçmişin incelenmesini zorlaştırır.

Kalan kısmın iptali onaylandıysa zaten yerine getirilmiş hacmi kaydedin. Tedarikçi kurallarında öngörülmüşse iade genellikle yalnızca yerine getirilmemiş kısmı kapsar. Yerine getirilmiş hacim teknik olarak bir kanaldan, videodan veya profilden diğerine aktarılamaz.

Kısmi iptalin dezavantajı açıktır: müşteri yanlış sayfada sonuç almış olabilir ve siparişin bu kısmı için ayrılan bütçe her zaman iade edilmez.

Sipariş tamamlandıysa düzeltmeyi ayrı bir talep olarak oluşturun

Tamamlanmış bir sipariş genellikle API üzerinden iptal edilemez. Bu durumda kaydı silmeyin ve geçmişteki bağlantıyı değiştirmeyin: orijinal veriler mutabakat için gereklidir. Hizmetin gerçekten hatalı adrese verilip verilmediğini, yoksa yalnızca gecikmeyle mi görüntülendiğini kontrol edin.

Ardından iki yol vardır: tedarikçiyle kurallarına göre tazminat görüşmek veya müşteriyle anlaştıktan sonra doğru bağlantı için yeni bir sipariş oluşturmak. Yeni siparişin ayrı bir kimliği, tutarı ve oluşturulma nedenine dair açık bir notu olmalıdır.

Yeni başlatmanın dezavantajı, ek bütçe gerektirmesi ve tamamlanmış hizmet için tazminatın mümkün olmayabilmesidir.

Yeniden başlatmadan önce müşteriye durumu bildirin

Bağlantı müşteriye aitse ve hata onun tarafından geldiyse, değişikliği kendi takdirinize göre başlatmayın. Ona orijinal bağlantıyı, sipariş durumunu, iptal imkânını ve her seçeneğin sonuçlarını gönderin. Hizmetin bir kısmı zaten yerine getirildiyse bu özellikle önemlidir.

• Sipariş aktarılmadıysa doğru bağlantıyı isteyin ve eski talebin iptalini onaylayın.
• Sipariş sıradaysa iptalin gönderildiğini ancak tedarikçi yanıtının beklendiğini bildirin.
• Kısmi tamamlama varsa yalnızca kalan kısmın durdurulabileceğini belirtin.
• Sipariş tamamlandıysa yeni bir başlatma veya başka bir çözüm yolu üzerinde anlaşın.

Uzun süren anlaşmanın dezavantajı, bu süre içinde sıradaki siparişin işlemeye geçebilmesidir. Bu nedenle imkân varsa önce teknik iptal talebini gönderin, ardından sonraki adımları netleştirin.

İşleme ait günlükleri ve kanıtları saklayın

Her ihtilaflı sipariş için müşteriden gelen orijinal bağlantıyı, alınma tarihini, dahili numarayı, tedarikçideki kimliği, API isteklerini ve yanıtlarını saklayın. Müşteri bağlantıyı yazışmada gönderdiyse, orijinali saklamadan mesajı sipariş kartında düzenlenmiş sürümle değiştirmeyin.

Hatayı kimin ve ne zaman fark ettiğini ayrıca kaydedin. Bu, yanlış iletilen verileri yönetici hatasından, sipariş formundan veya otomatik doldurmadan ayırmaya yardımcı olur. Tedarikçiye yapılan tekrarlanan başvurularda çelişki oluşmaması için tek bir veri zinciri kullanın.

Günlükleri elle tutmanın dezavantajı zaman almasıdır. Ancak geçmiş olmadan iptal durumunu doğrulamak ve müşteriye paranın neden tamamen iade edilemeyeceğini açıklamak daha zordur.

Entegrasyondaki hata işlemeyi kontrol edin

Böyle bir olaydan sonra sistemin bağlantıları API'ye nasıl ilettiğini kontrol edin. Hata yalnızca müşteriden kaynaklanmayabilir: bazen form parametreleri keser, önbellekten eski değeri yerleştirir, yayın bağlantısı yerine profil bağlantısını kabul eder veya fazla karakter içeren bağlantıyı geçirir.

Sipariş oluşturmadan önce biçim kontrolü ekleyin: platforma, hizmet türüne ve beklenen nesneye uygunluk. Video hizmetlerinde sistem, kanal bağlantısından video bağlantısını ayırt edebilmeli; sosyal ağlarda ise profili ayrı bir gönderiden ayırt edebilmelidir. Kontrol bağlantının doğruluğunu garanti etmez, ancak belirgin hataların bir kısmını eler.

Sipariş aktarımını, oluşturulmasından kısa bir veri kontrolüyle ayırmak daha iyidir. Ek adımın dezavantajı, siparişin hemen işleme girmemesidir; ancak yanlış adresi fark etmek için zamanınız olur.

Ekip için anlaşılır bir iptal senaryosu oluşturun

Birleşik bir işlem sırası tanımlayın: otomatik gönderimi durdurun, tedarikçideki durumu kontrol edin, iptali gönderin, yanıtı kaydedin, müşteriye bildirin ve ancak bundan sonra yeniden başlatmayı onaylayın. Bu senaryo formalite için değil, farklı çalışanların birbiriyle çelişen işlemler yapmaması için gereklidir.

İptal erişimini yetki sınırlaması ve işlem günlüğü olmadan vermeyin. Birden fazla yönetici aynı sipariş üzerinde aynı anda çalışırsa biri iptal talep ederken diğeri yanıt gelmeden değişiklik oluşturabilir. Bu, gereksiz maliyetlere ve hesaplamalarda karışıklığa yol açar.

Katı senaryonun dezavantajı, acil durumlarda daha az esneklik sunmasıdır. Ancak API siparişlerinde tek bir işlemin hızından çok, hangi bağlantının fiilen işleme girdiğinin kontrolü daha önemlidir.