Testa la tua integrazione

Testare la tua integrazione ECR ti consente di verificare che il tuo Point of Sale (POS) comunichi correttamente con il terminale di pagamento Market Pay prima del passaggio in produzione. Una campagna di test strutturata consente di individuare i difetti di integrazione prima del passaggio in produzione.

Ecco il nostro strumento online per l'auto-test: pos-test-suite.market-pay.com

Prerequisito

Dovresti disporre di un terminale di pre-produzione connesso all'host di acquiring di test (Dummy) di Market Pay. Non viene trasferito alcun fondo reale: rifiuti e approvazioni sono simulati.

Suite di test per l'integrazione del POS

La Suite di test per l'integrazione del POS è un manuale di test autonomo che ti guida attraverso una campagna di integrazione completa e ti consente di registrare i risultati, senza account né server. Tutto viene memorizzato localmente nel browser. Questo strumento consente di:

  • Filtrare i test in base al tuo ambito. Seleziona il tuo protocollo (Cloud API, Local API HTTP o TCP/IP, App2App) e attiva o disattiva le funzionalità opzionali (pre-autorizzazione, DCC, mancia, sovrapprezzo, S&F, ecc.). Il manuale nasconde i test non applicabili; ad esempio, la categoria Sessione viene rimossa automaticamente per Cloud API.
  • Coprire il manuale standard completo in sei categorie: Sessione, Transazione, Scenari di rifiuto, Interruzione e annullamento, Resilienza, Transazioni speciali.
  • Fornire per ogni test uno scenario, l'importo esatto di attivazione, i campi della risposta prevista e un suggerimento per lo sviluppatore, oltre a esempi di messaggi di richiesta/risposta per ciascun protocollo.
  • Registrare lo stato superato / non superato / non eseguito per ogni test e consentire di esportare un'istantanea JSON da condividere con il tuo referente Market Pay o da archiviare ai fini della certificazione.
  • Personalizzare: aggiungere, modificare o rimuovere test e intere categorie quando la tua integrazione richiede qualcosa oltre il manuale standard.

Con quali carte eseguire i test

Emulatore di carte

Lo strumento principale per la campagna è l'emulatore di carte dello schema insieme al Dummy Server. Gli scenari vengono attivati dall'importo della transazione: il Dummy Server restituisce uno specifico Bank Response Code (BRC) in base all'importo inviato. Ciò ti offre un controllo deterministico e ripetibile su rifiuti, errori, approvazioni parziali e flussi speciali, senza dover utilizzare carte fisiche diverse.

Carte di test ufficiali

Alcuni schemi forniscono carte di test; queste carte possono essere utilizzate con la nostra configurazione Dummy o in un ambiente di pre-produzione end-to-end, se disponiamo di un MID da configurare con l'acquirer previsto.

Avvertenza

Solo per le transazioni contact (chip): a seconda della carta, una transazione contact / chip potrebbe essere rifiutata quando viene utilizzata con il nostro Dummy Server, che emula la risposta.  Alcune carte richiedono dati effettivi dell'emittente che non siamo in grado di restituire alla carta quando viene utilizzata in un ambiente emulato.

Simulazione delle risposte

Il nostro connettore Dummy ci consente di emulare alcuni scenari e risposte in base all'importo inserito, per aiutarti con l'integrazione:

Importo Risultato attivato
11.00 Do Not Honor: rifiuto generico (BRC 100)
11.01 Carta scaduta (BRC 101)
11.04 Carta soggetta a restrizioni (BRC 104)
11.06 Numero di tentativi PIN consentiti superato (BRC 106)
11.09 Esercente non valido (BRC 109)
11.16 Fondi insufficienti (BRC 116)
16.20 Autorizzazione parziale (autorizzato = 16.20 − €0.50), se configurata
19.07 Emittente della carta non operativo (BRC 907): timeout dell'host con un ritardo di 30 secondi
19.09 Malfunzionamento del sistema (BRC 909): attiva la modalità offline se configurata

Interpretare correttamente il risultato

Quando verifichi l'esito di una transazione, controlla la risposta a livello di campo, non solo lo stato HTTP:

  • L'approvazione/il rifiuto è contenuto nel messaggio, non solo nel codice HTTP. Un HTTP 200 può comunque contenere un pagamento rifiutato. Controlla il campo del risultato all'interno del messaggio di risposta.
  • Local API HTTP utilizza un modello POST → polling. POST restituisce 202 Accepted; quindi esegui il polling con GET. Un 206 indica che l'elaborazione è in corso: continua il polling; un 200 indica il risultato finale. Non chiudere mai una transazione con 206.
  • Memorizza il POITransactionID restituito dal terminale. Storni, rimborsi e richieste di stato fanno riferimento a questo ID, non al riferimento della vendita.
  • Mantieni ServiceID univoco per ogni transazione all'interno di una sessione. Riutilizzarlo compromette la protezione dai pagamenti duplicati.
  • Segnala separatamente le approvazioni offline. Quando il risultato indica un'approvazione offline, il POS dovrebbe registrarla distintamente dalle approvazioni online.

Criteri di completamento: quando hai finito?

  • Tutti i test OBBLIGATORI sono superati. Sono bloccanti per il go-live.
  • I test CONSIGLIATI sono superati oppure eventuali errori sono documentati e accettati.
  • I test CONDIZIONALI sono superati per ogni funzionalità opzionale inclusa nel tuo ambito (pre-autorizzazione, DCC, mancia, sovrapprezzo, S&F, ecc.).
  • La campagna completata (Esporta dalla suite di test) è condivisa con il tuo referente Market Pay.

Hai bisogno di aiuto con la tua campagna? Contatta il tuo referente per l'integrazione Market Pay oppure invia una richiesta tramite Market Pay Assist.

Questo articolo ti è stato utile?

Utenti che ritengono sia utile: 0 su 0