Comprendre les paiements carte refusés

# Audit des paiements carte refusés

## Pourquoi un tool séparé

`get_transactions` ne retourne que les paiements réussis (compensés). Les paiements refusés vivent dans un objet distinct, `get_failed_transactions`, avec un champ que `get_transactions` n'a pas : la raison du refus en langage clair (`reasonCodeLong`) et la remédiation (`reasonCodeRemediation`). Toujours afficher les deux à l'utilisateur pour qu'il n'ait pas besoin de relancer une question — c'est explicitement documenté comme le comportement attendu du tool.

## Différences avec get_transactions à connaître

- `merchantName` ici est le descripteur brut du réseau carte — **pas** comparable au `merchantName` de `get_transactions`, qui est dérivé du nom du fournisseur lié.
- `createdAt` reflète ici la date d'enregistrement du refus, alors que sur `get_transactions` il reflète la date de règlement (pas la date d'autorisation) — les deux champs ne se comparent pas directement entre les deux tools.
- Pas de fenêtre fixe par défaut : sans `startDate`, la couverture est les 30 derniers jours ; avec `startDate`, aucune limite de profondeur.
- ⚠️ `endDate` seul ne déplace pas cette fenêtre : il ne fait que raccourcir les 30 derniers jours, donc un `endDate` vieux de plus de 30 jours ne renvoie rien. Toujours passer `startDate` pour une période qui commence il y a plus de 30 jours.
- Sur `get_transactions`, `startDate`/`endDate` filtrent sur la date de règlement uniquement : les paiements réglés sans date de règlement sont exclus dès qu'un filtre de dates est posé. Une liste filtrée par dates peut donc sous-compter une période — ne pas présenter sa somme comme un total complet.

## Appel

```json
{
  "tool": "get_failed_transactions",
  "params": {
    "companyId": "<companyId>",
    "startDate": "2026-01-01"
  }
}
```

## Résultat observé

Sur ce compte, sur la période testée : `{"data":[]}` — zéro paiement refusé. C'est un résultat normal et légitime à rapporter tel quel ("aucun paiement refusé sur la période") plutôt que de le traiter comme une erreur ou un signe que la requête a échoué.

## Piège devise

Chaque montant porte sa propre devise (`amountBilled.currency`, `amountDeclared.currency`) — il n'y a pas de champ `currencyBilled`/`currencyDeclared` séparé. Vérifier la devise sur chaque enregistrement avant de sommer. Si `amountDataIssue` est présent, ne jamais traiter le montant concerné comme zéro — le signaler explicitement à l'utilisateur.

## Exemples de prompts utilisateur

- "Quels paiements carte ont été refusés ce mois-ci, et pourquoi ?"
- "Y a-t-il des cartes avec des paiements refusés à répétition ?"
- "Donne-moi la raison et la solution pour chaque paiement refusé de [employé]"