API-rendelés törlése, ha az ügyfél hibás linket küldött

Először ellenőrizze, hogy a rendelést továbbították-e a szolgáltatónak

A hibás link nem mindig jelenti azt, hogy a promóció már elindult. A saját rendszerében a rendelés létrejöhetett, de még nem lett elküldve az API-n keresztül. Ebben az esetben a törlés csak az Ön feldolgozási logikájától függ: elegendő a rendelést töröltként megjelölni, az automatikus fizetést leállítani és a továbbítást nem elindítani.

Ellenőrizze a rendelés azonosítóját, a létrehozás idejét, a linket, a szolgáltatás típusát és az API-kérések naplóját. Ha a kérés a szolgáltatóhoz nem ment el, ne hozzon létre új rendelést a régi fölé. Először rögzítse az eredeti kérelem törlését, különben az ügyfél két indítást kaphat különböző linkekre.

Határozza meg a rendelés állapotát a szolgáltatónál

Ha az API-kérés már elküldésre került, kérje le az aktuális állapotot a szolgáltatótól. Az állapotok elnevezése eltérő, de általában több csoportba sorolhatók: várakozás, feldolgozás, részleges teljesítés, befejezés és törlés. A döntéshez nem a saját paneljén látható állapot a fontos, hanem annak a félnek a válasza, aki a szolgáltatást indítja.

• Várakozás: a rendelés még törölhető lehet.
• Feldolgozás: a leállítás néha lehetséges, de a mennyiség egy része már elindulhatott.
• Részleges teljesítés: csak a fennmaradó részt lehet törölni, ha a szolgáltató támogatja ezt a műveletet.
• Befejezés: a linket törléssel már nem lehet javítani.

A csak belső állapot alapján történő ellenőrzés hátránya, hogy az késedelmesen frissülhet. Támaszkodjon az utolsó API-válaszra és annak beérkezési idejére.

Törölje a rendelést a szolgáltatás elindítása előtt

A sorban álló rendeléshez használja a törlési metódust, ha azt a szolgáltató dokumentációja előírja. Adja át a rendelés létrehozásakor kapott azonosítót, ne a saját belső számát, ha ezek különböző értékek. Mentse el a teljes választ: a művelet kódját, az állapotot, a hibaüzenet szövegét és a kérés idejét.

Ne tekintse a rendelést töröltnek, amíg az API nem igazolta a törlést. A kérés elfogadásáról szóló válasz és a szolgáltatás tényleges leállítása különböző események lehetnek. Egyes integrációkban először az elfogadás visszaigazolása érkezik, és a végleges állapot később változik meg.

Ennek a lehetőségnek a hátránya, hogy a szolgáltató nem biztos, hogy időben le tudja venni a rendelést a feldolgozásból. Ekkor a törlés elutasítást ad vissza, vagy csak a nem teljesített részre érvényesül.

Ne módosítsa a linket egy már létrehozott rendelésben visszaigazolás nélkül

Sok API-ban a link a rendelés létrehozásának pillanatában rögzül. Ha ugyanazzal az azonosítóval próbál új linket átadni, azt figyelmen kívül hagyhatják, hibaként kezelhetik, vagy kiszámíthatatlan állapotot hozhat létre. Ne számítson arra, hogy a kérés ismételt elküldése automatikusan lecseréli a címet.

Ha a dokumentáció kifejezetten támogatja a link szerkesztését, először győződjön meg arról, hogy a szolgáltatás még nem kezdett el teljesülni. Ezután mentse el a régi értéket, az új értéket és az API válaszát. Ez hasznos lesz az ügyféllel vagy a szolgáltatóval folytatott vitában.

A szerkesztés hátránya, hogy még egy elérhető metódus esetén is a műveletek egy része a frissítés előtt a régi oldalra kerülhetett. A javított link nem viszi át a már elért eredményt.

Mit tegyen részleges teljesítés esetén

Ha a hibás linken már elindult a promóció, kérje a fennmaradó rész törlését. A szolgáltatóhoz intézett kérelemben tüntesse fel a rendelés azonosítóját, a hibás linket, a helyes linket, az aktuális állapotot és a hiba észlelésének idejét. Ne módosítsa többször a kérelem részleteit: ez megnehezíti az előzmények ellenőrzését.

Ha a fennmaradó rész törlését visszaigazolták, rögzítse a már teljesített mennyiséget. A visszatérítés, ha azt a szolgáltató szabályai előírják, általában csak a nem teljesített részre vonatkozik. A teljesített mennyiséget technikailag nem lehet átvinni egyik csatornáról, videóról vagy profilról a másikra.

A részleges törlés hátránya nyilvánvaló: az ügyfél már kaphat eredményt a hibás oldalon, és az erre a rendelésrészre szánt költségvetés nem mindig térül meg.

Ha a rendelés befejeződött, külön kérelemben intézze a javítást

A befejezett rendelést általában nem lehet törölni az API-n keresztül. Ebben a helyzetben ne törölje a rekordot, és ne módosítsa a linket az előzményekben: az eredeti adatokra szükség van az egyeztetéshez. Ellenőrizze, hogy a szolgáltatást valóban a hibás címre nyújtották-e, és nem csak késedelmesen jelenik meg.

Ezután két lehetőség van: megvitatni a kompenzációt a szolgáltatóval annak szabályai szerint, vagy új rendelést létrehozni a helyes linkre az ügyféllel való egyeztetés után. Az új rendelésnek külön azonosítóval, összeggel és a létrehozás okának egyértelmű megjelölésével kell rendelkeznie.

Az új indítás hátránya, hogy további költségvetést igényel, és a befejezett szolgáltatásért járó kompenzáció nem biztos, hogy elérhető.

Tájékoztassa az ügyfelet a helyzetről az ismételt indítás előtt

Ne indítsa el a cserét saját belátása szerint, ha a link az ügyfélé, és a hiba az ő oldaláról származik. Küldje el neki az eredeti linket, a rendelés állapotát, a törlés lehetőségét és az egyes lehetőségek következményeit. Ez különösen fontos, ha a szolgáltatás egy része már teljesült.

• Ha a rendelést nem továbbították, kérje a helyes linket, és igazolja vissza a régi kérelem törlését.
• Ha a rendelés sorban áll, jelezze, hogy a törlést elküldték, de a szolgáltató válaszára várnak.
• Ha részleges teljesítés van, jelezze, hogy csak a fennmaradó rész állítható le.
• Ha a rendelés befejeződött, egyeztessen egy új indítást vagy más megoldási módot.

A hosszú egyeztetés hátránya, hogy ez idő alatt a sorban álló rendelés feldolgozásba kerülhet. Ezért először küldje el a technikai törlési kérelmet, ha erre van lehetőség, és csak utána tisztázza a további lépéseket.

Őrizze meg a naplókat és a művelet bizonyítékait

Minden vitatott rendelésnél őrizze meg az ügyfél eredeti linkjét, a beérkezés dátumát, a belső számot, a szolgáltatói azonosítót, az API-kéréseket és a válaszokat. Ha az ügyfél a levelezésben küldte a linket, ne cserélje le az üzenetet szerkesztett változatra a rendelés kártyáján az eredeti megőrzése nélkül.

Külön rögzítse, hogy ki és mikor észlelte a hibát. Ez segít elkülöníteni a hibásan átadott adatokat a menedzser, a rendelési űrlap vagy az automatikus behelyettesítés hibájától. A szolgáltatóhoz intézett ismételt megkereséseknél ugyanazt az adatláncot használja, hogy ne keletkezzenek ellentmondások.

A manuális naplóvezetés hátránya, hogy időt vesz igénybe. Előzmények nélkül azonban nehezebb igazolni a törlés állapotát és elmagyarázni az ügyfélnek, miért nem téríthető vissza teljesen az összeg.

Ellenőrizze a hibakezelést az integrációban

Egy ilyen eset után ellenőrizze, hogyan továbbítja a rendszer a linkeket az API-ba. A hiba nem csak az ügyfél miatt jelentkezhet: néha az űrlap levágja a paramétereket, a gyorsítótárból régi értéket helyettesít be, profilra mutató linket fogad el közzétételre mutató link helyett, vagy extra karaktereket tartalmazó linket enged át.

Adjon hozzá formátumellenőrzést a rendelés létrehozása előtt: a platformnak, a szolgáltatás típusának és a várt objektumnak való megfelelést. A videós szolgáltatásoknál a rendszernek meg kell különböztetnie a videóra mutató linket a csatornára mutató linktől, a közösségi oldalaknál pedig a profilt az egyedi közzétételtől. Az ellenőrzés nem garantálja a link helyességét, de kiszűri a nyilvánvaló hibák egy részét.

A rendelés továbbítását jobb egy rövid adatellenőrzéssel elválasztani a létrehozásától. A további lépés hátránya, hogy a rendelés nem azonnal kerül feldolgozásra, viszont lesz ideje észrevenni a hibás címet.

Állítson be egyértelmű törlési forgatókönyvet a csapat számára

Írja le az egységes műveleti sorrendet: az automatikus küldés leállítása, az állapot ellenőrzése a szolgáltatónál, a törlés elküldése, a válasz mentése, az ügyfél tájékoztatása, és csak ezután az ismételt indítás egyeztetése. Erre a forgatókönyvre nem formaságból van szükség, hanem azért, hogy a különböző munkatársak ne hajtsanak végre egymást kizáró műveleteket.

Ne adjon hozzáférést a törléshez jogosultságkorlátozás és műveleti napló nélkül. Ha több menedzser dolgozik egyszerre ugyanazon a rendelésen, az egyik kérheti a törlést, a másik pedig létrehozhatja a cserét a válasz megérkezése előtt. Ez felesleges költségekhez és az elszámolás összekeveredéséhez vezet.

A szigorú forgatókönyv hátránya, hogy kevesebb a rugalmasság sürgős esetekben. Az API-rendeléseknél azonban nem az egyedi művelet sebessége a fontosabb, hanem annak ellenőrzése, hogy melyik link került ténylegesen feldolgozásra.