Webhooks Best Practices
Découvrez les meilleures pratiques à suivre lorsque vous utilisez des liens de rappel HTTP (webhooks). Explorez les informations sur les événements webhook, les listes d'autorisation, la logique de réessai et la sécurité.
Événements
Votre point de terminaison webhook doit être configuré pour recevoir uniquement les types d'événements requis par votre intégration.Écouter des événements supplémentaires (ou tous les événements) mettra une pression excessive sur votre serveur et n'est pas recommandé.
La configuration des événements ne peut être effectuée que par Affirm. Veuillez communiquer avec Affirm via le widget d'assistance.
Listes d'autorisation
Affirm utilise un certain nombre d'adresses IP lors de l'envoi de demandes de webhook et de nouvelles adresses IP peuvent être utilisées au fur et à mesure que nos systèmes évoluent et que de nouvelles ressources sont mises en ligne. Pour cette raison, nous recommandons fortement de ne pas mettre en place de listes blanches d'IP pour les requêtes de webhook, car cela pourrait entraîner l'échec des appels de webhook d'Affirm.
Réessayer la logique
Affirm ne renvoie pas actuellement (ou ne prend pas en charge le mécanisme de nouvelle tentative) un événement webhook lorsque votre point de terminaison ne le reçoit pas avec succès.
Sécurité
Authentification
Nous pouvons prendre en charge l'authentification de base et l'authentification JWT dans l'URL.
Exemple : "AB123 :[courriel protégé]/affirm_webhook".
Demandes signées
Affirm signs webhook requests so that you can optionally verify that Affirm is sending the request instead of a third-party pretending to be Affirm. Each request includes the following: a base-64 encoded header, and an X-Affirm-Signature. The value of the header is an HMAC-SHA512 hash signature computed from the request payload and your private API key found in your merchant dashboard.
Rejouer la prévention des attaques
If a third-party intercepts a request payload and its signature, your endpoint is susceptible to a replay attack. To mitigate these attacks, we include a timestamp in the X-Affirm-Signature header. Since the timestamp is part of the signed payload, the attacker cannot change the timestamp without invalidating the signature. If the signature is valid but the timestamp is old, you should reject the request. We recommend rejecting a response with a timestamp 5 minutes older than the current time.
Mis à jour about 2 months ago