Test

Una chiave di test non muove denaro reale, ma quasi tutto il resto è reale.

Le chiavi di test

Le vostre chiavi esistono in due famiglie: sk_live_… e sk_test_…. La chiave usata marca l'operazione per tutta la sua vita; nulla sposta un'operazione da una famiglia all'altra.

Con una chiave di test:

• nessun fornitore viene mai chiamato. Risponde sempre una simulazione al suo posto — una campagna di test non può raggiungere un circuito reale né disturbarlo.
• libro mastro, regolamenti e notifiche transazionali sono esclusi. Nessun movimento contabile, nessun totale di regolamento, nessun SMS né e-mail al pagatore.
• tutto il resto è reale: la catena di accettazione, i vostri webhook, i vostri registri per sviluppatori, le vostre righe di reporting e l'insieme dei controlli di rischio.

Importi magici

Le ultime due cifre dell'importo scelgono l'esito. È l'unico modo per provare i percorsi di errore, che un circuito in buona salute non produce mai.

L'importo termina con	Cosa accade
99	Rifiutato all'invio, in via definitiva. La classe «numero non valido» — non riprovate
98	Rifiutato all'invio, in via temporanea. La classe «guasto del circuito» — riprovare ha senso
97	Accettato, poi fallito. Prima pending, poi failed
qualsiasi altra cosa	Accettato, poi success

Vale allo stesso modo per incassi, pagamenti, rimborsi e annullamenti.

Il caso 97 è quello che conviene davvero provare

È la sequenza che le integrazioni si perdono: il vostro webhook riceve pending, voi segnate l'ordine come «in attesa di pagamento», e poi arriva failed e deve annullare ciò che pending ha fatto. Senza un modo per provocarla, la prima volta che quel percorso viene eseguito è in produzione.

Un importo che ha codificato un fallimento fallisce fino in fondo: un'operazione non può al tempo stesso rifiutare e riuscire, per quante volte la rileggiate.

Identità di test

I controlli di conformità si provano nello stesso modo, con identità magiche. Corrispondono soltanto alle operazioni di test.

Identità	Cosa prova	Cosa dovreste vedere
+221700000001 — «Test Sanctionne Fort»	Corrispondenza forte con una lista sanzionatoria	Il pagamento è rifiutato.
«Test Sanctionne Nom Seul» (solo nome, nessun numero)	Corrispondenza solo sul nome	Accettato, poi trattenuto per esame — vedi sotto
+221700000003 — «Test Personne Politiquement Exposee»	Persona politicamente esposta	Esame rafforzato, non un rifiuto
+221700000004 — «Test Identite Mineure»	Identità nota come minore	Rifiutato su un corridoio soggetto a restrizioni (gioco, scommesse), accettato altrove

Insieme di identità in vigore: fixture-2026-09-13-1. È identico in ogni ambiente e cambia per versione — un test scritto contro un insieme con un nome resta riproducibile.

Un nome da solo non è mai un rifiuto

La seconda riga sorprende, e lo fa di proposito: una corrispondenza sul solo nome non ferma un pagamento. I cognomi sono condivisi; rifiutare in base al nome significherebbe rifiutare moltissime persone per averlo scritto correttamente. Il pagamento viene dunque accettato e trattenuto per esame, e la vostra integrazione dovrebbe trattarlo come un'attesa, non come un fallimento.

Un rifiuto richiede un identificativo forte: un numero, un documento.

⚠️ Queste identità non sono persone reali e non corrispondono mai a un pagamento in produzione. Usarle con una chiave sk_live_ non produce nulla: sono identità di prova, e nulla di più.

Cosa potete provare

• risk.status che passa a review e a held, sul webhook come in lettura;
• gli eventi payment.held e payment.released;
• un fascicolo di conformità aperto nella corsia di test: visibile a voi, e che non raggiunge mai il nostro team di conformità né alcun totale regolamentare.

Cosa un test non mostra

Tre limiti, detti francamente invece di essere scoperti più tardi:

1. Nessun movimento contabile. Il libro mastro è fuori dal perimetro di test, quindi nulla che riguardi un saldo disponibile, un trattenimento o uno svincolo di fondi può essere verificato qui.
2. I tempi non sono quelli di produzione. La simulazione non ha un pagatore: la conferma proviene da una scansione con la propria cadenza, non da qualche secondo dopo un codice USSD. Provate la transizione, mai l'orologio.
3. Le notifiche transazionali non vengono inviate. Né al pagatore né a voi.

Cosa non fare

• Non ricavate i tempi di produzione dai tempi di test. Vedi il punto 2.
• Non trattate pending come un fallimento, né in test né in produzione.
• Non copiate mai un'identità di test nei vostri dati di produzione. Lì non corrisponde a nulla, e un dato di prova in un record reale è una pista falsa per chiunque lo legga dopo.