# Exploitation

> Faire tourner une intégration Merchant API en production : débit, reprises, délais, erreurs, identifiants de requête et observabilité, avec les garanties réellement tenues par le serveur.

Cette section rassemble ce qu'il faut pour exploiter une intégration sans surprise : ce que le serveur garantit quand quelque chose se passe mal, et ce qu'il vous revient de faire.

## Ce que le serveur garantit

- **Un refus de débit ne calcule rien et ne facture rien.** Un `429` coûte moins cher qu'une requête servie. Voir [Limites de débit](https://developer.noryo.app/fr-FR/merchant/rate-limits).
- **Une panne du moteur n'est jamais facturée ni mémorisée.** Un `503 engine_error` se reprend avec la même `Idempotency-Key`. Voir [Reprises](https://developer.noryo.app/fr-FR/merchant/operations/retries).
- **Un règlement est atomique.** La réservation de la clé d'idempotence, la facturation et la mémoire de la réponse sont écrites ensemble : il n'existe aucun instant où la facture serait enregistrée et la réponse perdue.
- **Une tentative a exactement un identifiant**, le même dans l'en-tête, le corps d'erreur et les journaux de Noryo. Voir [Identifiants de requête](https://developer.noryo.app/fr-FR/merchant/operations/request-ids).
- **Aucune erreur ne laisse fuir d'information interne** : ni SQLSTATE, ni nom de table, ni trace d'appel, ni nom d'hôte interne. Voir [Erreurs](https://developer.noryo.app/fr-FR/merchant/error-handling).

## Ce qui n'est pas publié

- **Aucun engagement de latence ni de disponibilité** n'est publié. Ne bâtissez pas vos délais sur une valeur supposée. Voir [Délais d'attente](https://developer.noryo.app/fr-FR/merchant/operations/timeouts).
- **Les limites de débit de Production** ne sont pas publiées : lisez `Noryo-RateLimit-Limit`.

## La règle qui rend tout le reste sûr

Envoyez une `Idempotency-Key` générée une fois par opération, et réutilisez-la pour chaque reprise de cette opération. Avec elle, une reprise après un délai dépassé, un `500`, un `503` ou une coupure réseau ne peut ni dupliquer un enrichissement ni le facturer deux fois. Ajoutez un `external_transaction_id` pour que la même transaction renvoyée des semaines plus tard soit reconnue. Voir [Les deux identifiants](https://developer.noryo.app/fr-FR/merchant/identifiers).

## Dans cette section

- [Limites de débit](https://developer.noryo.app/fr-FR/merchant/rate-limits) : seau de jetons, en-têtes, `429` et `Retry-After`.
- [Reprises](https://developer.noryo.app/fr-FR/merchant/operations/retries) : quoi reprendre, quand, et comment.
- [Délais d'attente](https://developer.noryo.app/fr-FR/merchant/operations/timeouts) : ce qui se passe quand une requête dure, des deux côtés.
- [Erreurs](https://developer.noryo.app/fr-FR/merchant/error-handling) : le format Problem Details et le catalogue des codes.
- [Identifiants de requête](https://developer.noryo.app/fr-FR/merchant/operations/request-ids) : `Noryo-Request-Id`, et comment s'en servir avec le support.
- [Observabilité](https://developer.noryo.app/fr-FR/merchant/operations/observability) : ce que vous pouvez mesurer, et ce que Noryo journalise.

---

Page canonique : https://developer.noryo.app/fr-FR/merchant/operations