Webhook-er
Webhook-er gir sanntids, hendelsesdrevne varsler for kritiske oppdateringer i betalingens livssyklus. Cardflos webhook-er gjør at systemene dine kan reagere umiddelbart på betalingsstatuser, tvister og andre viktige hendelser.
Automatiser arbeidsflyter og oppretthold synkronisering mellom plattformen din og Cardflo uten konstant polling.
- Kategori
- Utvikler
- Funksjoner
- 10
- Tilgjengelig på
- Alle abonnementer
Oversikten
Webhook-er fungerer som asynkrone HTTP-tilbakekall som muliggjør sanntidskommunikasjon mellom en betalingsgateway og en forhandlerserver.
I motsetning til tradisjonelle polling-metoder hvor en server sender gjentatte forespørsler for å sjekke statusoppdateringer, sender webhook-er data til en forhåndsdefinert URL i det øyeblikket en spesifikk hendelse inntreffer i betalingens livssyklus.
Denne mekanismen er avgjørende for å håndtere ikke-synkrone hendelser som 3-D Secure-autentiseringsresultater, asynkron Alternative Payment Method (APM)-fullførelser, eller mottak av en tilbakeføring. Innenfor betalingsstacken fungerer webhook-er som bindevevet mellom innløseren eller PSP-en og forhandlerens interne ordrestyringssystem (OMS) eller inntektsstyringsplattform.
De sikrer at påfølgende logikk, som lagerlåsing eller digitale rettigheter, forblir nøyaktig uten å introdusere forsinkelse eller unødvendig API-overhead.
Riktig implementering krever robust håndtering av HTTP-statuskoder og idempotens for å håndtere potensielle gjenforsøk fra senderserveren, noe som sikrer at hver hendelse behandles én gang og bare én gang.
Slik fungerer det
Definer endepunkt og hendelser
En forhandler spesifiserer en destinasjons-URL i sitt miljø for å motta POST-forespørsler. De velger spesifikke hendelsestrigger fra betalingslivssyklusen, for eksempel autorisasjonssuksess, refusjonsinitiellering eller tvistopprettelse.
Dette sikrer at systemet deres kun behandler relevante datapakker, noe som reduserer unødvendig serverbelastning og holder integrasjonspunkter fokuserte og håndterbare.
Hendelsestrigger og nyttelast
Når en statusendring inntreffer, for eksempel at en kunde fullfører en SCA-utfordring, genererer systemet en JSON-nyttelast. Denne nyttelasten inneholder strukturerte data, inkludert transaksjons-ID, forhandler-ID (MID), beløp og den spesifikke hendelsestypen.
Gatewayen forsøker deretter å levere disse dataene til det registrerte endepunktet.
Sikkerhet og signaturverifisering
For å forhindre uautorisert datainjeksjon signeres nyttelasten vanligvis med en hemmelig nøkkel. Forhandlerserveren rekonstruerer signaturen ved hjelp av den rå forespørselsteksten og sammenligner den med overskriften.
Denne verifiseringen sikrer at dataene stammer fra den pålitelige kilden og ikke ble tuklet med under transport.
Bekreft og behandle
Forhandlerserveren må returnere en 200 OK-statuskode raskt for å bekrefte mottak. Intern logikk utføres deretter, for eksempel oppdatering av en databasepost eller utløsing av en automatisert e-post.
Hvis serveren er utilgjengelig eller returnerer en feil, følger leveringssystemet en programmert gjenforsøksplan for å sikre datakonsistens.
Hvorfor det er viktig
Operasjonell effektivitet og automatisering
Å stole på manuelle statuskontroller eller periodisk API-polling introduserer forsinkelser som kan forringe brukeropplevelsen og forsinke oppfyllelsen. Webhook-er automatiserer overgangen mellom betalingsautorisasjon og tjenestelevering.
Ved å motta umiddelbar varsling om vellykkede fangster eller oppgjør, kan bedrifter automatisere forsendelsesarbeidsflyter, lisensgenerering eller kontolevering, noe som reduserer behovet for manuell inngripen og minimerer risikoen for menneskelige feil i transaksjonsstyring.
Risiko- og tvistbegrensning
Varsler om gjenfinningsforespørsler eller tilbakeføringer gjør at forhandlere kan svare innenfor ordningskrav. Umiddelbare varsler om myke avslag eller SCA-feil muliggjør proaktivt kundeengasjement.
Ved å reagere på disse hendelsene når de skjer, kan forhandlere forbedre suksessraten for representasjon og redusere driftskostnadene forbundet med uadresserte betalingsfeil eller tvister som ellers kunne ha gått ubemerket hen inntil en periodisk manuell revisjon.
Bruksområder
Abonnement og SaaS livssyklus
Når en gjentakende betaling mislykkes eller et kort utløper, utløser en webhook en automatisert påminnelsessekvens eller suspenderer brukerens tilgang, og opprettholder nøyaktige faktureringssykluser uten manuell overvåking.
E-handel ordreoppfyllelse
En nettforhandler bruker webhook-er for å frigi varer for forsendelse først etter å ha mottatt en 'capture. succeeded'-hendelse, og forhindrer utsendelse av varer som ikke er fullt autorisert.
Markedsplass utbetalingskoordinering
Plattformer som mottar midler kan utløse utbetalinger til undermerchants bare etter at den opprinnelige kundetransaksjonen har oppnådd statusen 'avgjort', noe som sikrer likviditet og reduserer risikoen for utbetalingsreverseringer.
Alternativ betalingsmetode fullførelse
For metoder som bankoverføringer eller lokale ordninger som ikke gir umiddelbar bekreftelse, varsler webhook-er systemet timer eller dager senere når midler er bekreftet.
I tall
Typisk bransjeforsinkelse mellom en hendelse som registreres i innløserplattformen og webhook-en som sendes til forhandlerens endepunkt.
Standard pålitelighetsmålestokk for webhook-tjenester når man inkluderer automatisert gjenforsøkslogikk og redundant leveringsinfrastruktur.
Bransjeobservasjon av forbedring i oppfyllingshastighet når man går over fra periodisk batchbehandling til hendelsesdrevne webhook-arkitekturer.
Relaterte begreper
Talk to our team about a live rollout on your acquiring stack.
Hva du får med Webhook-er
- Asynkron levering av transaksjonsstatusendringer for forbedret systemytelse.
- Støtte for flere hendelsestyper, inkludert autorisasjon, innfanging, refusjon og tvist.
- HMAC-SHA256-signaturhoder for robust verifisering av innkommende dataintegritet.
- Automatisert gjenforsøkslogikk etter eksponentielle backoff-planer for mislykkede leveringsforsøk.
- Payload-versjonering for å sikre kompatibilitet etter hvert som datastrukturer utvikler seg over tid.
- IP-hvitelisting-funksjoner for å begrense innkommende trafikk til kjente gateway-kilder.
- Inkludering av idempotensnøkkel for å forhindre duplikatbehandling av samme betalingshendelse.
- Detaljerte hendelseslogger for feilsøking og revisjon av webhook-leveringsytelse i dashbordet.
- Detaljert hendelsesvalg for å minimere båndbreddebruk og server-side prosesseringskrav.
- Testmodusfunksjonalitet for validering av endepunktatferd med simulerte betalingsscenarier.
A short scoping call, then a written plan for your MIDs.
Spørsmål om Webhook-er
Hvordan bør serveren vår håndtere dupliserte webhook-varsler?
Det er standard praksis for betalingsgatewayer å bruke en gjenforsøksmekanisme hvis et endepunkt ikke returnerer en 200 OK-respons innen en spesifikk tidsramme. Følgelig kan serveren din motta den samme hendelsen flere ganger.
For å opprettholde dataintegritet bør du implementere idempotenslogikk. Dette innebærer vanligvis å spore den unike hendelses-ID-en som er gitt i payloaden, og sjekke om den allerede er behandlet før du utfører forretningslogikk.
Hvis ID-en eksisterer i databasen din, bør serveren din ignorere hendelsen, men fortsatt returnere en 200 OK for å stoppe ytterligere gjenforsøk.
Hva er forskjellen mellom å polle et API og å bruke webhook-er?
Polling krever at serveren din initierer hyppige forespørsler til gatewayen for å sjekke statusoppdateringer, noe som er ineffektivt og kan føre til hastighetsbegrensninger eller forsinket informasjon. Webhook-er snur denne flyten, der gatewayen initierer en forespørsel til serveren din bare når en hendelse inntreffer.
Denne 'push'-modellen er mer effektiv, reduserer serverbelastningen og sikrer at status oppdateres i nær sanntid på tvers av infrastrukturen din, noe som er spesielt viktig for tidssensitive handlinger som levering av digitalt innhold eller svindelforebygging.
Hvorfor er signaturverifisering nødvendig for hver webhook-forespørsel?
Siden webhook-endepunkter er offentlige URL-er, er de teoretisk tilgjengelige for enhver enhet på internett. Uten verifisering kan en angriper sende en forfalsket JSON-payload til serveren din, og feilaktig indikere at en verdifull betaling var vellykket.
Ved å bruke en delt hemmelighet for å verifisere HMAC-signaturen som er angitt i forespørselshodet, kan systemet ditt matematisk bevise at meldingen ble sendt av din PSP og at innholdet ikke er endret, noe som sikrer sikkerheten i ordreutførelsesprosessen din.
Hvordan håndterer webhook-er 3-D Secure- og SCA-krav?
Under en 3-DS-flyt går transaksjonen ofte inn i en ventende tilstand mens brukeren omdirigeres til utstederen for autentisering. Det endelige resultatet av denne autentiseringen er kanskje ikke kjent umiddelbart.
Webhook-er brukes til å varsle systemet ditt når 3-DS-utfordringen er fullført og transaksjonen deretter er autorisert eller avvist. Dette forhindrer at kassen din henger og lar backend-en din reagere på den endelige autorisasjonsstatusen når kunden returnerer fra bankens omdirigeringsside.
Kan webhook-er brukes til å administrere tidslinjer for tilbakeførsler og tvister?
Ja, webhook-er er et primært verktøy for å administrere tvistelivssyklusen. Når en kortholder initierer en gjenfinningsforespørsel eller en formell tilbakeføring med utstederen, mottar gatewayen dette varselet via kortselskapene.
En webhook sendes deretter til systemet ditt som spesifiserer årsakskode, beløp og frist for svar. Ved å bruke disse sanntidsdataene kan du automatisere suspensjon av den aktuelle kontoen og varsle risikoteamet ditt om å starte representasjonsprosessen umiddelbart, noe som øker sannsynligheten for en vellykket tvisteomvendelse.
Hva skjer hvis serveren vår er nede under en kritisk webhook-hendelse?
Pålitelige webhook-systemer opererer med en gjenforsøkspolicy. Hvis endepunktet ditt returnerer en 4xx eller 5xx feil, eller ikke svarer innen noen sekunder, vil gatewayen sette meldingen i kø for gjenlevering.
Disse gjenforsøkene følger vanligvis et eksponentielt backoff-mønster, hvor levering forsøkes flere ganger over minutter eller timer.
For å sikre langsiktig konsistens bør du også ha en fallback-mekanisme, for eksempel et daglig avstemmingsskript som kaller API-en for å finne eventuelle tapte statusendringer, noe som gir et sikkerhetsnett for langvarige utfall.
Relaterte funksjoner.
Klar for fart?
Fortell oss om bedriften din. Vi finner de rette innløsningspartnerne og den rette ruten for deg, vanligvis innen en uke.