Anularea unei comenzi API dacă clientul a trimis un link incorect

Mai întâi verificați dacă comanda a fost transmisă furnizorului

Un link incorect nu înseamnă întotdeauna că promovarea a fost deja lansată. În baza proprie, comanda poate fi creată, dar încă netrimisă prin API. În acest caz, anularea depinde doar de logica dumneavoastră de procesare: este suficient să marcați comanda ca anulată, să opriți plata automată și să nu lansați transmiterea.

Verificați identificatorul comenzii, ora creării, linkul, tipul serviciului și jurnalul cererilor API. Dacă cererea către furnizor nu a plecat, nu creați o comandă nouă peste cea veche. Mai întâi înregistrați anularea solicitării inițiale, altfel clientul poate primi două lansări pe linkuri diferite.

Determinați statusul comenzii la furnizor

Dacă cererea API a fost deja trimisă, solicitați statusul actual de la furnizor. Denumirile statusurilor diferă, dar de obicei pot fi împărțite în câteva grupuri: în așteptare, în procesare, executare parțială, finalizare și anulare. Pentru decizie contează nu statusul din panoul dumneavoastră, ci răspunsul părții care lansează serviciul.

• În așteptare: comanda poate permite încă anularea.
• În procesare: oprirea este uneori posibilă, dar o parte din volum poate fi deja lansată.
• Executare parțială: se poate anula doar restul, dacă furnizorul suportă această operațiune.
• Finalizare: linkul nu mai poate fi corectat prin anulare.

Dezavantajul verificării doar după statusul intern este că acesta se poate actualiza cu întârziere. Orientați-vă după ultimul răspuns API și momentul primirii lui.

Anulați comanda înainte de lansarea serviciului

Pentru o comandă aflată în coadă, utilizați metoda de anulare dacă este prevăzută în documentația furnizorului. Transmiteți identificatorul primit la crearea comenzii, nu numărul dumneavoastră intern, dacă acestea sunt valori diferite. Salvați răspunsul complet: codul operațiunii, statusul, textul erorii și ora cererii.

Nu considerați comanda anulată până când API-ul nu a confirmat anularea. Răspunsul de acceptare a cererii și oprirea efectivă a serviciului pot fi evenimente diferite. În unele integrări, mai întâi vine confirmarea acceptării, iar statusul final se schimbă mai târziu.

Dezavantajul acestei variante este că furnizorul poate să nu apuce să retragă comanda din procesare. Atunci anularea va returna un refuz sau va funcționa doar pentru partea neexecutată.

Nu modificați linkul într-o comandă deja creată fără confirmare

La multe API-uri, linkul este fixat în momentul creării comenzii. Încercarea de a transmite un link nou cu același identificator poate fi ignorată, tratată ca eroare sau poate crea o stare imprevizibilă. Nu vă bazați pe faptul că retransmiterea cererii va înlocui automat adresa.

Dacă documentația suportă în mod explicit editarea linkului, mai întâi asigurați-vă că serviciul nu a început deja să se execute. Apoi salvați valoarea veche, valoarea nouă și răspunsul API. Acest lucru va fi util în cazul unei dispute cu clientul sau cu furnizorul.

Dezavantajul editării este că, chiar și cu o metodă disponibilă, o parte din acțiuni ar fi putut ajunge pe pagina veche înainte de actualizare. Linkul corectat nu transferă rezultatul deja obținut.

Ce faceți în cazul executării parțiale

Când promovarea pe linkul incorect a început deja, solicitați anularea restului. În adresarea către furnizor indicați identificatorul comenzii, linkul incorect, linkul corect, statusul actual și momentul descoperirii erorii. Nu modificați detaliile adresării de mai multe ori: acest lucru îngreunează verificarea istoricului.

Dacă anularea restului este confirmată, înregistrați volumul care a fost deja executat. Rambursarea, dacă este prevăzută de regulile furnizorului, de obicei se referă doar la partea neexecutată. Volumul executat nu poate fi transferat tehnic de pe un canal, un clip sau un profil pe altul.

Dezavantajul anulării parțiale este evident: clientul poate primi deja rezultatul pe pagina incorectă, iar bugetul pentru această parte a comenzii nu este întotdeauna returnat.

Dacă comanda este finalizată, formulați corectarea printr-o solicitare separată

O comandă finalizată de obicei nu poate fi anulată prin API. Într-o astfel de situație, nu ștergeți înregistrarea și nu modificați linkul din istoric: datele inițiale sunt necesare pentru verificare. Verificați dacă serviciul a fost într-adevăr prestat pe adresa greșită, și nu doar afișat cu întârziere.

Apoi există două căi: discutați o compensație cu furnizorul conform regulilor acestuia sau creați o comandă nouă pe linkul corect după ce ați convenit cu clientul. Comanda nouă trebuie să aibă un identificator separat, o sumă și o mențiune clară privind motivul creării.

Dezavantajul noii lansări este că necesită un buget suplimentar, iar compensația pentru un serviciu finalizat poate să nu fie disponibilă.

Informați clientul despre situație înainte de o nouă lansare

Nu lansați înlocuirea din proprie inițiativă dacă linkul aparține clientului și eroarea a venit din partea lui. Trimiteți-i linkul inițial, statusul comenzii, posibilitatea anulării și consecințele fiecărei variante. Acest lucru este deosebit de important dacă o parte din serviciu a fost deja executată.

• Dacă comanda nu a fost transmisă, solicitați linkul corect și confirmați anularea solicitării vechi.
• Dacă comanda este în coadă, anunțați că anularea a fost trimisă, dar se așteaptă răspunsul furnizorului.
• Dacă există o executare parțială, indicați că poate fi oprit doar restul.
• Dacă comanda este finalizată, conveniți o nouă lansare sau o altă soluție.

Dezavantajul unei coordonări îndelungate este că, între timp, comanda din coadă poate trece în procesare. De aceea, mai întâi trimiteți cererea tehnică de anulare, dacă această posibilitate există, și abia apoi clarificați acțiunile ulterioare.

Păstrați jurnalele și dovezile pentru operațiune

Pentru fiecare comandă contestată păstrați linkul inițial de la client, data primirii, numărul intern, identificatorul la furnizor, cererile API și răspunsurile. Dacă clientul a trimis linkul într-o conversație, nu înlocuiți mesajul cu o variantă editată în fișa comenzii fără a păstra originalul.

Înregistrați separat cine și când a observat eroarea. Acest lucru ajută la delimitarea datelor transmise greșit de o eroare a managerului, a formularului de comandă sau a unei substituiri automate. La adresările repetate către furnizor, folosiți un singur lanț de date, pentru a nu apărea contradicții.

Dezavantajul ținerii manuale a jurnalelor este că ocupă timp. Dar fără istoric este mai dificil să confirmați statusul anulării și să explicați clientului de ce fondurile nu pot fi returnate integral.

Verificați gestionarea erorilor în integrare

După un astfel de caz, verificați modul în care sistemul transmite linkurile către API. Eroarea poate apărea nu doar din cauza clientului: uneori formularul trunchiază parametrii, substituie o valoare veche din cache, acceptă un link către profil în loc de un link către publicație sau lasă să treacă un link cu caractere în plus.

Adăugați o verificare a formatului înainte de crearea comenzii: conformitatea cu platforma, tipul serviciului și obiectul așteptat. Pentru serviciile pe video, sistemul trebuie să distingă linkul către un clip de linkul către un canal, iar pentru rețelele sociale — profilul de o publicație separată. Verificarea nu garantează corectitudinea linkului, dar elimină o parte din erorile evidente.

Este mai bine să separați transmiterea comenzii de crearea ei printr-o scurtă verificare a datelor. Dezavantajul pasului suplimentar este că comanda nu va intra imediat în lucru, însă veți avea timp să observați adresa incorectă.

Configurați un scenariu clar de anulare pentru echipă

Descrieți o ordine unitară a acțiunilor: opriți trimiterea automată, verificați statusul la furnizor, trimiteți anularea, salvați răspunsul, informați clientul și abia apoi conveniți o nouă lansare. Un astfel de scenariu este necesar nu de formă, ci pentru ca diferiți angajați să nu efectueze acțiuni care se exclud reciproc.

Nu acordați acces la anulare fără limitarea drepturilor și fără un jurnal al acțiunilor. Dacă mai mulți manageri lucrează simultan la aceeași comandă, unul poate solicita anularea, iar altul poate crea o înlocuire înainte de primirea răspunsului. Acest lucru duce la cheltuieli suplimentare și confuzii în decontări.

Dezavantajul unui scenariu strict este mai puțină flexibilitate în cazurile urgente. Dar pentru comenzile API este mai important controlul asupra linkului care a ajuns efectiv în lucru decât viteza unei acțiuni separate.