Fejlkoder & fejlfinding

Læs både HTTP-status og fejlkode

HTTP-status angiver fejltypen. Den stabile kode forklarer den konkrete afvisning. En menneskelig besked hjælper ved fejlsøgning, men må ikke bruges som en maskinel kontrakt; teksten kan blive forbedret uden at ændre kodebetydningen.

Gatewayen returnerer et request-ID i svarheaderen. Gem dette sammen med tidspunkt, operation og din egen korrelationsreference. Gem ikke Authorization-headeren, client secret eller et helt bilag i en log, blot for at kunne slå requesten op senere. Blind genafsendelse med en ny nøgle er ikke en sikker fejlstrategi.

De vigtigste statusgrupper

Fejlkoder

Den fulde liste over stabile koder:

Nogle fejl opstår før databasen, andre i den autoritative domæneoperation. Et fejlsvar er derfor ikke i sig selv bevis for, at alle efterfølgende trin blev forsøgt. Eksempelvis afvises en bankroute, før en normal domæneskrivning bliver udført.

Inputfejl, som ofte bliver overset

Ukendte felter afvises i stedet for at blive ignoreret. Det gælder eksempelvis customer_id, source, status og providerfelter i en partnerpayload. En kopieret intern payload er derfor ikke nødvendigvis et gyldigt eksternt input.

Beløb skal være tal og hele øre. En streng med cifre accepteres ikke som en praktisk genvej. Datoer skal være gyldige kalenderdatoer. Parametre må ikke gentages i query eller formular for at teste, om serveren vælger den første eller sidste værdi.

På fakturakladder er mængde, pris og rabat forskellige størrelser. En rabat på 100 procent accepteres ikke. En mængde med mere end tre decimaler afrundes ikke lydløst, hvis det ændrer beløbsgrundlaget.

Autorisationsfejl

Et gyldigt client secret beviser ikke, at kunden har givet adgang. Et token kan ligeledes være korrekt formateret, men knyttet til en udløbet eller tilbagekaldt grant. Kontrollér den aktive apprevision, grantens organisation og scopes, før du begynder at rotere credentials tilfældigt.

Et hsk_-token hører til sandbox. Et hat_-token hører til produktionsprofilen. At ændre URL'en er ikke en måde at konvertere det ene til det andet. Refresh-token-replay kan tilbagekalde hele tokenfamilien; et parallelt refresh-design i klienten skal derfor undgås.

Regnskabsfejl

En postering kan være balanceret og alligevel blive afvist af en lukket periode, en afregnet momsperiode eller en ugyldig reference. Ret ikke automatisk dato, konto eller moms for at få et grønt svar. En sådan ændring er en ny faglig beslutning.

Input, der afvises før regnskabskernen (alle 400-svar samt invalid_amount, journal_unbalanced og reference_not_allowed), gemmer ingen kvittering, så samme idempotensnøgle kan genbruges med rettet input. En afvisning fra kernen (domain_rejected, for eksempel et lukket regnskabsår) gemmes og afspilles igen ved samme nøgle og samme input. Samme nøgle med anden payload giver 409 idempotency_conflict. Idempotensguiden beskriver forskellen mellem et sikkert retry og en ny operation.

Ukendt udfald

Et netværkstimeout fortæller, at klienten ikke fik et rettidigt svar. Det fortæller ikke, om databasen committede. Gem derfor den samme nøgle og payload, og gentag efter den beskrevne strategi. Et senere identisk svar kan være et replay af den første succes, ikke en ny bogføring.

Et timeout under tokenudstedelse er et andet problem: et engangssecret eller en rotationsværdi kan være skabt, men ikke nå klienten. Den værdi kan ikke læses ud af sin digest bagefter. Følg credential- eller reautoriseringsflowet i stedet for at antage, at serveren kan vise den igen.

Hvad en god supportsag indeholder

Angiv miljø, app-ID, den berørte revision, metode og relativ sti, HTTP-status, stabil fejlkode, request-ID og omtrentligt tidspunkt. Beskriv, om requesten var første forsøg eller et retry med samme nøgle. Del kun et minimeret, syntetisk eksempel på input.

Serverens interne databasefejl sendes ikke til partneren. Gatewayen mapper kendte fejl og skjuler ukendte interne detaljer. En lækket SQL-fejl er ikke mere brugbar dokumentation; den kan afsløre tabeller, relationer eller andre kunders eksistens.