Betalingswebhook: bekreft hendelser og unngå dobbelt arbeid

Beskriv handlingen før du velger hendelser

Skriv en konkret oppgave, som å frigjøre en bestilling eller oppdatere en intern betalingsoversikt. Knytt deretter oppgaven til dokumenterte hendelser. Det er enklere å drifte en bevisst valgt liste enn en generell mottaker som forsøker å reagere på alt. Tenk på en ordre som allerede er levert når samme bekreftelse kommer på nytt. Beskjeden kan fortsatt være gyldig, men leveransen skal ikke gjentas. Skill derfor lagring av betalingsinformasjon fra selve forretningshandlingen. Gi begge deler identiteter som gjør det mulig å vise hva som er mottatt, hva som er behandlet, og hva bedriften allerede har gjort med ordren.

Signerte betalingsvarsler

Kontroller avsenderen med riktig metode

En offentlig webhook-adresse må behandle innhold som ubekreftet frem til den dokumenterte kontrollen er gjennomført. Følg metoden for den konkrete integrasjonen, inkludert håndtering av signatur og beskjedformat. Stripe beskriver egne webhook-signaturer; disse er ikke automatisk samme kontrakt som OrsunPays hendelser. Hemmelighetene må ligge på serveren og ha et kontrollert eierskap. En beskjed som ikke kan verifiseres, må ikke merke ordren som betalt. Sørg samtidig for at feilen kan undersøkes uten å legge unødvendige kundeopplysninger i loggen. Ved nøkkelbytte bør teamet følge en avtalt prosedyre og kontrollere at den aktive konfigurasjonen stemmer med forventet miljø.

Utviklerverktøy

Gjør gjentatt behandling trygg

En mottaker kan få samme hendelse flere ganger, og flere prosesser kan arbeide samtidig. Et midlertidig minnefelt er derfor ikke nødvendigvis nok til å hindre dobbelt levering. Bruk en varig registrering som knytter hendelsesidentitet, betaling og ordre sammen. Beslutningen om å utføre neste handling bør skje kontrollert, slik at to parallelle behandlinger ikke begge starter den. Gå også gjennom forskjellige hendelser som beskriver samme endelige resultat. Det er ikke bare identiske meldinger som kan føre til gjentatt arbeid. Dokumenter hva applikasjonen gjør når en ordre allerede har riktig status, og sørg for at en ny levering av beskjed fortsatt gir en forståelig driftslogg.

Forbered forsinkede og manglende oppdateringer

Kundens returside og serverens hendelse kan komme på forskjellige tidspunkter. Vis en passende ventestatus når resultatet ikke er avklart, og unngå å kreve et nytt betalingsforsøk av den grunn alene. Dersom ordren blir stående uten forventet oppdatering, må drift kunne finne betalingsreferansen og undersøke aktuell status. Kontroller om problemet gjelder selve betalingen, leveringen av meldingen eller behandlingen i eget system. Disse lagene krever ulike tiltak. En mottatt forespørsel er ikke nødvendigvis en ferdig oppdatert ordre. Gå derfor helt frem til forretningsresultatet når saken undersøkes, og noter hvor den siste sikre opplysningen kommer fra.

Gjenbehandle først når årsaken er forstått

En ny levering løser lite hvis mottakeren fortsatt har samme feil. Finn først ut om adressen, tilgjengeligheten, signaturkontrollen eller forretningslogikken hindrer behandlingen. Registrer hvilken hendelse som skal prøves igjen, hvem som gjør det, og hva som forventes å endre seg. OrsunPays leveringshistorikk kan støtte undersøkelsen, mens tilgjengelige kontrollhandlinger avhenger av rettigheter. Automatiske leveringsforsøk er begrenset. Ha derfor en manuell rutine for tilfeller der disse er brukt opp. Kontroller etterpå at ordren fikk riktig tilstand, ikke bare at serveren svarte uten feil. En trygg arbeidsflyt må tåle at det samme steget blir utført på nytt under en senere undersøkelse.

Gi drift en kort og brukbar veiledning

Veiledningen bør angi hvilke referanser som brukes, hvem som eier mottakeren, og hvilke handlinger som er tillatt ved dubletter eller manglende meldinger. La en medarbeider utenfor utvikling prøve å finne en konkret ordre ved hjelp av teksten. Personen skal kunne se siste verifiserte status og om oppfyllelse allerede er utført. OrsunPay tilbyr signerte betalingshendelser og leveringshistorikk som tekniske verktøy. De erstatter ikke betalingsleverandørens oppgjørsopplysninger eller bedriftens regnskap. Hold disse formålene adskilt. Da kan teamet undersøke en forsinket beskjed uten å forveksle en teknisk kvittering med en bankoverføring eller en ferdig bokført inntekt, og uten å sette i gang unødvendige nye betalinger.

Kilder

• Stripe Webhooks
• Stripe API: idempotent requests