Documentation / Premiers pas

Sandbox

Une instance distincte de Coinetic, sans réseaux réels. L’API, les signatures, la page de paiement, les statuts et les webhooks avec nouvelles tentatives fonctionnent comme en production : seuls les paiements sont simulés.

Service	Adresse
API	`https://sandbox.coinetic.money`
Tableau de bord	https://sandbox.coinetic.money/merchant

Les clés sandbox et production sont distinctes. Une clé sandbox ne fonctionne pas en production, et inversement.

Paiements de test par boutons

Sur la page de paiement de la sandbox, une fois la devise choisie, un bloc « Sandbox : paiement test » apparaît :

Bouton	Effet
Payer le montant exact	Paiement du montant total : `detected` immédiatement, puis `paid` après ~3 s
Sous-paiement de 10 %	90 % du montant → `underpaid`
Payer le solde	(après un sous-paiement) le reste → `paid`
Surpaiement de 10 %	110 % → `overpaid`
Moitié du montant	50 % ; cliquez à nouveau : la seconde moitié → `paid`

Paiements de test depuis vos tests automatisés

Les mêmes scénarios, par requête. Le jeton est la partie de checkout_url qui suit #t=. La devise doit déjà être choisie (sur la page ou via POST /v1/invoices/{id}/select avec le même jeton).

HTTP

POST /sandbox/v1/invoices/{id}/pay
Authorization: Bearer <jeton de checkout_url après #t=>
Content-Type: application/json

{"scenario": "exact"}

Valeurs de scenario : exact, underpay, overpay, half, rest.

En sandbox, un remboursement s’exécute en une seule commande : POST /v1/refunds/{id}/simulate (détails dans la section « Remboursements »).

Différences avec la production

Les factures et les webhooks portent livemode: false. Votre boutique en production doit rejeter ces factures et ces événements : ainsi, une sandbox branchée par erreur ne déclenchera jamais de livraison.
Les webhooks et le return_url peuvent pointer vers http://localhost et http://127.0.0.1. Les adresses publiques doivent être en https:// sur le port 443, comme en production.
Le contrôle AML est toujours « propre ».
Les taux des actifs volatils sont réels, issus des plateformes d’échange.

À tester avant la mise en production

Paiement exact, sous-paiement suivi du complément, surpaiement, paiement en deux moitiés.
Facture expirée : nouvelle facture pour la même commande.
Un webhook falsifié ou périmé est rejeté ; un webhook renvoyé ne déclenche pas de double livraison.
Rotation du secret de webhook et changement de clé API sans interruption de service.