Partnerprogramos webhook

A partnerprogramos webhook egy HTTP-értesítés, amelyet egy másik rendszer kap, amikor partnerprogrammal kapcsolatos esemény történik, például konverzió, jutalékmódosítás vagy kifizetési állapotváltozás. A kapcsolódó integrációkhoz callback vagy postback is használható. A támogatott eseményindítók és az adatcsomagok platformonként eltérnek.

Webhook, callback és postback – a fogalmak

Ezeknek az elnevezéseknek a jelentése platformonként átfed. A webhook eseményvezérelt HTTP-értesítés. A callback egy másik rendszernek küldött válasz vagy értesítés tágabb értelemben vett neve. A partnerprogramos integrációkban a postback gyakran szerverről továbbított konverziós eseményt jelent. Önmagában az irány nem ad általános érvényű különbségtételt.

Példák az eseményekre és a fogadó rendszer műveleteire

Ezek fogalmi példák; nem jelentik azt, hogy minden platform biztosít ilyen eseményindítókat. A fogadó rendszer megtervezése előtt ellenőrizze a tényleges eseménykatalógust és az adatcsomag verzióját.

Webhookok és rendszeres lekérdezés

A rendszeres lekérdezés ütemezetten kérdezi le az API-t a változásokról. A webhookok a támogatott eseményeket azok bekövetkezésekor küldik el. A webhookok csökkenthetik az ismételt API-lekérdezések számát, míg a lekérdezés vagy az egyeztetés segíthet a hiányzó állapotok helyreállításában. Egy megbízható integráció mindkettőt használhatja, ahelyett hogy teljesnek és sorrendhelyesnek feltételezné az értesítéseket.

Példa a többször kézbesített értesítésre

Egy jóváhagyási esemény időtúllépés után kétszer érkezik meg. A fogadó rendszer felismeri, hogy ugyanarról az eseményazonosítóról van szó, és csak egy állapotátmenetet rögzít. Egy későbbi visszatérítés külön esemény, amelyet akkor is fel kell dolgozni, ha ugyanahhoz a tranzakcióhoz kapcsolódik.

Ezért lehet helytelen minden webhookot kizárólag a tranzakcióazonosító alapján deduplikálni. Az eseményazonosító és a tranzakcióazonosító eltérő célt szolgál.

Üzemeltetési ellenőrzések

Ne szerepeltessen hitelesítő adatokat nyilvános példákban, naplózza a kézbesítés eredményét szükségtelen ügyféladatok nélkül, és állítson be riasztást az ismétlődő hibákra. A fogadó rendszernek a küldő dokumentált protokollja szerint kell visszaigazolnia a kéréseket, a pénzügyi következményekkel járó műveleteket pedig biztonságosan kell feldolgoznia. A fontos állapotokat egyeztesse a hiteles forrásként szolgáló platformmal, ne csak az értesítések érkezési idejére támaszkodjon.

Fogadó rendszer tervezése valós kézbesítési körülményekre

Ellenőrizze, mely esemény indítja el az értesítést, és hogy rögzített, jóváhagyott vagy kifizetett jutalékra vonatkozik-e. Tárolja az eseményazonosítót és a releváns entitás azonosítóját, a küldő által támogatott hitelesítési módszerrel ellenőrizze a kérést, az időigényes feladatokat pedig helyezze várólistára.

Készüljön fel a többször, késve, sikertelenül vagy sorrenden kívül érkező eseményekre. Újrapróbálkozáskor ugyanazt a rekordot frissítse, ne fizessen ki kétszer jutalmat. Ha a jóváhagyás a helyi értékesítési rekord előtt érkezik meg, kérje le vagy egyeztesse a hiányzó állapotot; ne kezelje az érkezési sorrendet üzleti szabályként.

A Stripe hivatalos webhook-dokumentációja ismerteti a kézbesítéssel és a végpontok kialakításával kapcsolatos mintákat; az aláírások és az adatcsomagok Stripe-specifikusak. A tényleges mezőkről, támogatott eseményindítókról és hitelesítésről a partnerplatform saját dokumentációjában tájékozódjon. Mielőtt webhookot pénzügyi művelethez kapcsolna, tesztelje a hibás válaszok kezelését és az egyeztetést.

A megfelelő Post Affiliate Pro-beállításokért tekintse meg a webhookok és callbackek dokumentációját . Ellenőrizze a konfigurációt és az integrációs követelményeket a program szabályai alapján.

A folyamat áttekintése