Webhook-er
Webhooks for betalingsbehandling, som muliggjør sanntids HTTP-varsler for synkronisering på tvers av over 50 partnerselskaper, automatiserer oppfyllelse og sporer umiddelbart tilbakeførselshendelser eller MID-aktivitet.
- Kategori
- Utvikler
- Funksjoner
- 6
- Tilgjengelig på
- Alle abonnementer
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.
Tidlige webhook-varsler leverer sanntidsoppdateringer om transaksjonsstatus og MID-aktivitet på tvers av vårt omfattende innløsernettverk. Denne umiddelbare dataflyten muliggjør rask automatisering av kritiske forretningsprosesser og umiddelbare svar på hendelser.
Oversikt over Webhook-eroversikt
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 3D Secure-autentiseringsresultater, asynkron fullføring av alternative betalingsmetoder (APM), 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 plattform for inntektsstyring.
De sikrer at påfølgende logikk, som lagerreservasjon 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 Webhook-erfungerer
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.
Derfor er Webhook-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.
Regelverk for Webhook-er
Data privacy and payload security
Transmitting transaction data across open networks leaves no slack against data protection regulations like GDPR and PCI DSS. Notification payloads must travel exclusively over TLS-encrypted connections to prevent interception by unauthorised third parties during transit.
Cardflo enforces HTTPS URLs for all registered listener endpoints, rejecting any unencrypted destinations.
Furthermore, structured notifications exclude sensitive cardholder data, such as full primary account numbers or security codes. The gateway transmits tokenised identifiers and masked references, ensuring that the receiving server does not inadvertently bring its hosting environment into the highest tiers of PCI DSS compliance scope.
PSD2 and asynchronous strong customer authentication
Under Payment Services Directive 2, Strong Customer Authentication introduces asynchronous flows into the standard checkout process. When a transaction requires an out-of-band authentication step, such as a biometric check in a banking application, the initial request cannot return an immediate definitive success or failure status.
Event listeners are essential for capturing the final outcome of these mandated security challenges. Once the issuing bank confirms the authentication result through the acquirer partner network, the orchestration layer fires an asynchronous event.
This notification informs the merchant system that the security requirement is satisfied and the capture can proceed.
Brukstilfeller for Webhook-erbrukstilfeller
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.
Webhook-er 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.
Metodikk: Disse tallene er veiledende intervaller hentet fra publiserte bransjedata og observerte handelsgrupper, ikke garantier. Faktiske resultater avhenger av din risikoprofil, kortmiks, geografi og anskaffelsesoppsett, og bekreftes kun i dine egne priser og godkjenningsvilkår.
Relaterte begreper
Snakk med teamet vårt om en live utrulling på infrastrukturen til våre innløserpartnere.
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.
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 3D 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.
Relaterte funksjoner.
Relatert guider.
Se hvordan Cardflo sammenlignes.
Klar for å forbedre betalingsløsningen din?
Fortell oss om bedriften din. Vi finner de rette innløsningspartnerne og den rette ruten for deg, vanligvis innen en uke.