HMAC sur les 2 sens
Vous signez vos requêtes API avec X-SP-Signature. Nous signons nos webhooks avec X-SP-Signature. Aucune route ne passe sans vérification cryptographique.
REST + HMAC + retry async
Une API REST conçue pour ne pas vous trahir en prod
JSON propre, signatures HMAC SHA-256 sur entrée et sortie, idempotency-key first-class, retry exponentiel, et catalogue d'events stable. Vous écrivez votre intégration une fois — elle ne casse plus.
Ce que vous obtenez
Idempotency-Key obligatoire
Sur tous les POST mutations critiques. Un rejeu réseau ou un double-click ne crée jamais de double charge — la même réponse est rendue deterministically.
Retry async dédié
Les webhooks merchant partent dans une file de retry isolée. 10 tentatives, backoff exponentiel cap 30 min, DLQ pour les échecs permanents — aucun blocage du flux principal.
35+ events stables
Un catalogue d'events centralisé et versionné. Une fois publiée, une chaîne d'event ne change plus. Convention payment.succeeded, checkout.session.completed, payout.failed.
# Reçu :
# POST /votre-endpoint-webhook
# X-SP-Signature: sha256=<hex>
# X-Event-Type: payment.succeeded
# { ... payload JSON ... }
# 1. Recalculer le HMAC à partir du corps brut + secret merchant
expected=$(printf '%s' "$BODY" \
| openssl dgst -sha256 -hmac "$WEBHOOK_SECRET" -hex \
| awk '{print "sha256=" $2}')
# 2. Comparaison constant-time (pas de strcmp naïf — timing-safe)
if [ "$expected" = "$X_SP_SIGNATURE" ]; then
echo "Signature OK — traiter $X_EVENT_TYPE"
else
echo "Signature invalide — rejeter 403"
fi
# Idempotence côté merchant : dédupliquer sur l'event_id du payload
# pour gérer les rejeux de retry sans double-effet.
HMAC
SHA-256 entrée et sortie
10×
Retry exponentiel cap 30 min
35+
Events stables catalogués
Intégrez l'API avec confiance.
Doc Swagger complète + Postman collection à venir.