Mode test et simulateur

Le déploiement de test fonctionne comme la production, avec un seul fournisseur : le simulateur (provider: "SANDBOX"). Il ne touche aucun argent réel. Les endpoints /v1/sandbox/… n’existent pas en production.

Le même chemin que la production

Une simulation ne modifie pas le statut directement : le simulateur envoie à Galsen Pay un webhook signé, qui passe par la vérification de signature, la confirmation auprès du « fournisseur », la comptabilité et l’envoi de vos propres webhooks. Ce que vous testez est donc la vraie chaîne.

Simuler le client d’un paiement

POST/v1/sandbox/payments/{reference}/simulate

Permission payments:write. {reference} : la référence du simulateur, dernier segment de nextAction.url (sbx_…), ou l’identifiant du paiement.

Paramètre	Type	Description
`outcome`requis	"succeed" \| "fail" \| "expire"	Le client paie, le paiement échoue, ou la session expire sans paiement.
`deliverWebhook`facultatif	boolean	`false` : change l’état chez le simulateur sans envoyer le webhook du fournisseur, pour tester un webhook perdu. Galsen Pay interroge alors le fournisseur avant de clore la session, à son expiration : le paiement n’est jamais déclaré expiré s’il a été payé.

cURL

curl -sX POST https://backend.v1.pay.galsen.tech/v1/sandbox/payments/sbx_.../simulate \
  -H "Authorization: Bearer $GALSEN_SECRET_KEY" -H "Content-Type: application/json" \
  -d '{ "outcome": "succeed" }'
# {"success":true,"data":{"providerReference":"sbx_…","outcome":"succeed","webhook":{"eventId":"sbxev_…","status":"…"}}}

Le statut du paiement passe à SUCCEEDED (ou FAILED, EXPIRED) dès que le webhook est traité en arrière-plan, en quelques secondes au plus. Relisez le paiement, ou attendez votre webhook payment.succeeded.

Simuler un versement

POST/v1/sandbox/payouts/{reference}/simulate

Permission payouts:write. {reference} : l’identifiant du versement. Corps : { "outcome": "succeed" | "fail" }.

Un versement simulé reste PROCESSING jusqu’à cet appel. Un numéro de bénéficiaire qui se termine par 0000 échoue immédiatement : pratique pour tester vos erreurs.

Ce que le simulateur reproduit

Paiement réussi, échoué, expiré ; annulation par le marchand.
Remboursements (total et partiel) et versements, avec réservation puis libération des fonds sur votre solde.
Frais réels de votre grille tarifaire, règlement, mouvements comptables.
Webhooks signés vers votre serveur, avec les mêmes nouvelles tentatives qu’en production.

Ce qu’il ne reproduit pas : l’expérience du client sur l’application Wave, les délais et les refus propres à un vrai fournisseur. Prévoyez des tests réels lors du passage en production.