Toutes les routes de ce groupe nécessitent le header Authorization: Bearer sk_.... Une Transaction est créée par softpay, checkout hébergé ou payout — il n’existe pas de création directe de transaction via ce groupe, lecture seule uniquement.
Vue d’ensemble
flow_direction : payin ou payout
flow_direction est toujours dérivé de transaction_type, jamais saisi directement — c’est un champ en lecture seule.
status: "CANCELLED" existe dans le modèle de données mais n’est actuellement atteint par aucun flux — en pratique, seuls PENDING, SUCCESS et FAILED apparaissent.
GET /transactions/, GET /transaction-attempts/ et GET /transaction-status-logs/ utilisent une pagination par curseur (page_size=50 par défaut, 200 maximum via ?page_size=) :
Pas de champ count sur ces trois endpoints (contrairement à la plupart des autres listes de l’API, qui utilisent une pagination par numéro de page classique avec count) — table la plus volumineuse de la plateforme, un COUNT(*) par page serait coûteux. Naviguez avec next/previous, pas avec un numéro de page.
Filtrer et rechercher
GET /transactions/ accepte :
- Filtres exacts :
status, transaction_type, currency, flow_direction, country, network, merchant
- Plage de dates :
created_at__gte, created_at__lte
- Recherche libre (
?search=) : référence, référence gateway, nom/email/téléphone client, slug de lien de paiement, slug de session checkout
GET /transaction-attempts/ filtre par status, gateway, transaction. GET /transaction-status-logs/ filtre par to_status, triggered_by, transaction.
Export et facture : marge interne jamais exposée
gateway_fee et platform_fee (la marge interne de la plateforme) sont visibles sur les endpoints JSON classiques (liste, détail) — vous les voyez déjà comme marchand. Ils disparaissent totalement des deux documents destinés à être partagés en dehors de l’API :
La facture PDF n’est disponible que pour un paiement entrant réussi (flow_direction: "INBOUND" et status: "SUCCESS") — jamais pour un payout, jamais pour une transaction encore PENDING ou FAILED.
