Webhooks i regnskap

En webhook er et varsel som et system sender automatisk til et annet system når noe skjer, for eksempel når en faktura er betalt, en ordre er opprettet eller et bilag er bokført. I stedet for at mottakeren spør regnskapssystemet hvert minutt om noe er nytt, får den beskjed med én gang.

Typiske bruksområder

Fire tekniske grep som hindrer feil i regnskapet

1. Kontroller signaturen. Seriøse webhook-tjenester signerer hver melding med en hemmelig nøkkel, for eksempel med HMAC. Mottakeren skal beregne signaturen på nytt og avvise meldinger som ikke stemmer. Ellers kan hvem som helst sende falske «betalt»-varsler.

2. Tål at samme varsel kommer flere ganger. Sender avsenderen ikke kvittering i tide, sender den varselet på nytt. Mottakeren må derfor kjenne igjen hendelsen på en unik ID og ikke bokføre den to ganger. Dette kalles idempotens.

3. Ikke stol på rekkefølgen. Varsler kan komme i en annen rekkefølge enn hendelsene skjedde. Et «refundert»-varsel kan komme før «betalt». Hent gjerne gjeldende status fra kilden før du bokfører.

4. Svar raskt, behandle etterpå. Kvitter for mottatt melding med en gang, og legg selve behandlingen i en kø. Da unngår du tidsavbrudd og nye forsøk fra avsenderen.

Eksempel: dobbelt betalingsvarsel

En nettbutikk sender varselet «ordre 1045 betalt, 1 250 kr» to ganger fordi regnskapssystemet brukte for lang tid på å svare første gang. Uten kontroll av hendelses-ID blir salget bokført to ganger, og kundefordringen blir negativ med 1 250 kr. Med kontroll av ID blir det andre varselet gjenkjent og ignorert.

Logging og kontrollspor

Lagre alle mottatte varsler med tidspunkt, hendelses-ID og resultat. Loggen er nyttig når noe må feilsøkes, og den er en del av sporbarheten i regnskapet. Se kontrollspor i regnskapssystemet og importlogg.

Når varsler uteblir

Webhooks kan gå tapt, for eksempel når mottakeren er nede. Kjør derfor en jevnlig kontroll som sammenligner data i begge systemer, for eksempel antall ordrer og sum betalinger per dag. Differanser tas inn manuelt eller hentes på nytt.

Sjekkliste

• Signaturen kontrolleres på hver melding
• Hver hendelse har unik ID som lagres
• Mottakeren svarer raskt og behandler i kø
• Feilede varsler logges og varsles
• Det finnes en daglig eller ukentlig avstemming mellom systemene
• Integrasjonen er testet i et testmiljø

Les også om API-sikkerhet i regnskap og integrasjoner i ReAI.