Testa la tua integrazione

Testa la tua integrazione

Testare la tua integrazione ECR ti permette di confermare che il tuo Punto Vendita (POS) comunica correttamente con il terminale di pagamento Market Pay prima di passare alla produzione. Una campagna di test strutturata individua i difetti di integrazione mentre sono ancora economici da correggere — in pre-produzione, senza impatto finanziario.

Questo articolo descrive cosa testare, come attivare ogni scenario e introduce il POS Integration Test Suite — un libro di test autonomo che puoi usare per eseguire e tracciare la tua campagna.

Prima di iniziare

Conferma che siano presenti i seguenti elementi:

  • Un terminale in pre-produzione connesso all'host di acquisizione di test (Dummy) di Market Pay. Non vengono movimentati fondi reali — rifiuti e approvazioni sono simulati.
  • Il metodo di integrazione è deciso: Local API (HTTP o Socket/TCP-IP), Cloud API o App2App (Android Intent). I test applicabili dipendono da questo (vedi Quali test si applicano alla mia integrazione).
  • Il timeout del client HTTP supera i 90 secondi per le chiamate di pagamento. Diversi scenari di resilienza ritardano deliberatamente la risposta dell'host; un timeout più breve fallirà quei test in modo errato.

Passaggi chiave per il test

  1. Valida il flusso positivo. Una vendita contactless standard e una vendita chip + PIN standard che entrambe si completano con un risultato approvato e una ricevuta corretta.
  2. Esamina i casi limite. Rifiuti, aborti, cancellazioni, autorizzazioni parziali, firma richiesta e transazioni speciali (storno, rimborso, pre-autorizzazione, ecc.).
  3. Testa la resilienza. Perdita di rete a metà transazione, riavvio del POS, timeout dell'host, modalità offline e comportamento di polling.
  4. Verifica la gestione dei dati. Che il tuo POS memorizzi gli identificatori restituiti dal terminale (POITransactionID) per storni, rimborsi e interrogazioni di stato, e che ServiceID sia unico per transazione.
  5. Traccia e documenta i risultati. Registra pass/fail per ogni test affinché la campagna sia verificabile prima del go-live.

Il POS Integration Test Suite

Il POS Integration Test Suite è un libro di test autonomo che ti guida attraverso una campagna di integrazione completa e ti permette di registrare i risultati — senza account né server necessari. Tutto è memorizzato localmente nel tuo browser.

Sostituisce l'approccio manuale di copia-incolla per i test di integrazione con un unico strumento che:

  • Filtra i test in base al tuo ambito. Seleziona il tuo protocollo (Cloud API, Local API HTTP o TCP/IP, App2App) e attiva/disattiva le funzionalità opzionali (pre-autorizzazione, DCC, mancia, sovrapprezzo, S&F, ecc.). Il libro nasconde i test non applicabili — per esempio, la categoria Session viene rimossa automaticamente per Cloud API.
  • Copre l'intero libro standard attraverso sei categorie: Sessione, Transazione, Scenari di rifiuto, Abort & Cancel, Resilienza, Transazioni speciali.
  • Fornisce a ogni test uno scenario, l'importo esatto da attivare, i campi di risposta attesi e un suggerimento per sviluppatori — più esempi di messaggi richiesta/risposta per protocollo.
  • Registra pass / fail / non eseguito per ogni test e ti permette di esportare uno snapshot JSON da condividere con il tuo contatto Market Pay o archiviare per la certificazione.
  • È personalizzabile. Aggiungi, modifica o rimuovi test e intere categorie quando la tua integrazione necessita qualcosa oltre il libro standard.

Come usarlo: apri la suite di test, completa il breve tour guidato, imposta il tuo ambito, poi procedi con ogni categoria, segnando i risultati man mano. Usa Esporta alla fine per produrre il report della tua campagna.

Nota

Chiedi al tuo contatto per l'integrazione Market Pay il link attuale al POS Integration Test Suite per la tua campagna.

Quali test si applicano alla mia integrazione

Categoria Local API (HTTP / Socket) Cloud API App2App
Sessione (Login / Logout, controllo seriale, diagnosi) Sì Non applicabile — autenticazione gestita a livello API Sì
Transazione Sì Sì Sì
Scenari di rifiuto Sì Sì Sì
Abort & Cancel Sì Sì Sì
Resilienza Sì Sì — meccanismo di polling / autenticazione può differire Sì — più risoluzione Intent
Transazioni speciali Sì — dipendente dalla funzionalità Sì — dipendente dalla funzionalità Sì — dipendente dalla funzionalità

La suite di test applica questo filtro per te una volta impostato il tuo ambito.

Quali carte testare

Emulatore di carte (consigliato)

Lo strumento principale per la campagna è l'emulatore di carte Market Pay insieme al Dummy Server. Gli scenari sono attivati dall'importo della transazione: il Dummy Server restituisce un Codice di Risposta Bancaria (BRC) specifico basato sull'importo inviato. Questo ti dà un controllo deterministico e ripetibile su rifiuti, errori, approvazioni parziali e flussi speciali — senza bisogno di decine di carte fisiche.

Per esempio (qualsiasi importo non nella lista di attivazione restituisce un approvato di default):

Importo Risultato attivato
11.00 Do Not Honor — rifiuto generico (BRC 100)
11.01 Carta scaduta (BRC 101)
11.16 Fondi insufficienti (BRC 116)
11.17 PIN errato (BRC 117)
16.00 – 17.99 Autorizzazione parziale (autorizzato = richiesto − €1,00)
18.00 – 18.99 Firma richiesta sulla ricevuta
19.07 Emittente non operativo — ritardo di risposta di 30 secondi (BRC 907)

La mappatura completa importo-BRC (inclusi intervalli specifici per carta) è fornita all'interno della suite di test, per ogni test.

Usare le proprie carte personali

Puoi anche usare le tue carte personali in pre-produzione. Poiché l'ambiente di pre-produzione è connesso all'host di acquisizione Dummy, non c'è impatto finanziario — non avvengono autorizzazioni, catture o regolamenti reali sulla tua carta.

Questo è un complemento utile all'emulatore quando vuoi validare il comportamento con carte reali: tap contactless, lettura reale del chip, inserimento reale del PIN e l'esperienza del titolare della carta sullo schermo del terminale.

Avvertenza

Solo transazioni contact (chip): a seconda della carta, una transazione contact/chip può essere rifiutata. Questo è previsto ed è una caratteristica della carta, non un difetto della tua integrazione. I tap contactless generalmente non sono influenzati. Se ti serve un'approvazione garantita o un motivo di rifiuto specifico, usa l'emulatore di carte con l'importo di attivazione corrispondente.

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/rifiuto è nel messaggio, non solo nel codice HTTP. Un HTTP 200 può comunque contenere un pagamento rifiutato. Controlla il campo risultato all'interno del messaggio di risposta.
  • Local API HTTP usa un pattern POST → poll. POST restituisce 202 Accepted; poi fai polling con GET. Un 206 significa in corso — continua a fare polling; un 200 è il risultato finale. Non chiudere mai una transazione su 206.
  • Memorizza il POITransactionID restituito dal terminale. Storni, rimborsi e interrogazioni di stato lo fanno riferimento — non al tuo riferimento di vendita.
  • Mantieni ServiceID unico per transazione all'interno di una sessione. Riutilizzarlo compromette la protezione da pagamenti duplicati.
  • Segnala separatamente le approvazioni offline. Quando il risultato indica un'approvazione offline, il tuo POS dovrebbe registrarla distintamente dalle approvazioni online.

Criteri di uscita — quando hai finito?

  • Tutti i test OBBLIGATORI passano. Questi sono bloccanti per il go-live.
  • I test RACCOMANDATI passano, o eventuali fallimenti sono documentati e accettati.
  • I test CONDIZIONALI passano per ogni funzionalità opzionale nel tuo ambito (pre-autorizzazione, DCC, mancia, sovrapprezzo, S&F, ecc.).
  • La tua campagna completata (Esporta dalla suite di test) è condivisa con il tuo contatto Market Pay.

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

 

 

Testare la tua integrazione ECR ti permetterà di verificare che la tua integrazione funzioni come previsto prima di passare a un ambiente di produzione.

I passaggi chiave per il test includono:

  1. Validare il flusso positivo.
  2. Esaminare i flussi non positivi, comprendendo scenari come timeout e problemi di connessione, confermando lo stato della transazione.
  3. Replicare diverse risposte degli acquirer per valutare la gestione dei pagamenti rifiutati.
  4. Eseguire test con vari Metodi di Verifica del Titolare della Carta (CVM).

Puoi ottenere carte emulate per l'ambiente di test da:

Nota. Per le carte fisiche, dovresti verificare con il tuo acquirer o con il tuo referente Market Pay.

Per testare i flussi non positivi, quando usi l'ambiente di test Market Pay, esiste una regola per restituire un codice di risposta specifico in base all'importo ricevuto quando corrisponde al formato seguente: 9XXX, dove

es.: se il codice di risposta atteso è 116 (Fondi insufficienti). Devi effettuare una transazione con l'importo 9116.

Allegati