Ultimo aggiornamento 2/05/2014

1. Introduzione

Nelle pagine successive spiegheremo come integrare il vostro negozio o il sito Web nella nostra pagina di pagamenti sicuri online.

Ingenico ePayments e-Commerce consente di:

  • integrare le pagine dei pagamenti nella piattaforma Ingenico ePayments, estremamente sicura e monitorata
  • personalizzare la pagina dei pagamenti adattandola allo stile del vostro sito Web
  • evitare certificati o la responsabilità dei dati riservati

Se non si provvede autonomamente all'integrazione o la si affida a un Web master e si cerca una soluzione che richieda un impegno minimo, controllare le nostre diverse soluzioni di Carrello acquisti.

2. Pagina Informazione tecniche

Nell'account Ingenico ePayments è possibile accedere alla pagina "Informazione tecniche" dal menu "Configurazione" in alto.

In base alle impostazioni della pagina "Informazione tecniche", sarà presente l'icona "i" per spiegare una particolare impostazione.

3. Processo di vendita

Nelle seguenti schermate viene illustrato il processo di vendita in seguito all'integrazione di base del sito Web nel sistema.

Pagina di riepilogo del processo di vendita

Sul vostro sito Web, al cliente viene presentata una pagina riepilogativa con i dettagli dell'ordine. Il cliente deve confermare i dati prima di accedere alla pagina di pagamento sicuro.

Il pulsante di conferma infatti è la parte visibile di un "modulo HTML" contenenti campi nascosti con i dati del pagamento; l'operazione di inoltro rimanda automaticamente il cliente in modalità protetta alla pagina di pagamento sul nostro server. I campi nascosti sono descritti nel capitolo Collegamento del sito Web alla pagina del pagamento.

Pagina del pagamento

Nella nostra pagina di pagamento sicuro, il cliente può scegliere tra i metodi di pagamento selezionati da voi.

Se il pagamento avviene mediante carta di credito, al cliente verrà richiesta l'immissione dei dati della carta di credito. Il cliente può confermare o annullare la richiesta di pagamento.

Pagina di conferma del pagamento 

Dopo aver richiesto il pagamento all'istituto finanziario competente, il cliente visualizza una pagina con il risultato del pagamento.

Se il pagamento viene rifiutato, viene visualizzato un messaggio di errore. Il cliente può riprovare con un altro metodo di pagamento oppure modificando i dati immessi.

Il cliente può visualizzare anche una pagina specifica del sito Web, in base al risultato della transazione. Per maggiori informazioni, vedere il capitolo
Reindirizzamento in base al risultato della transazione.

4. Collegamento del sito Web alla pagina del pagamento

4.1 Dove effettuare la configurazione?

Il collegamento tra il vostro sito Web e la nostra pagina di pagamento di e-Commerce deve essere instaurato nell'ultima pagina del carrello acquisti del vostro sito Web, quindi nell'ultima pagina del sito presentata all'acquirente.

In quest'ultima pagina è necessario integrare un modulo con campi html nascosti contenenti i dati dell'ordine. Di seguito viene raffigurato il blocco di codice da incollare nell'ultima pagina del carrello acquisti:

<form method="post" action="https://ogone.test.v-psp.com/ncol/test/orderstandard_utf8.asp" id=form1 name=form1>

<!-- parametri general: vedere Parametri del modulo -->

<input type="hidden" name="PSPID" value="">
<input type="hidden" name="ORDERID" value="">
<input type="hidden" name="AMOUNT" value="">
<input type="hidden" name="CURRENCY" value="">
<input type="hidden" name="LANGUAGE" value="">
<input type="hidden" name="CN" value="">
<input type="hidden" name="EMAIL" value="">
<input type="hidden" name="OWNERZIP" value="">
<input type="hidden" name="OWNERADDRESS" value="">
<input type="hidden" name="OWNERCTY" value="">
<input type="hidden" name="OWNERTOWN" value="">
<input type="hidden" name="OWNERTELNO" value="">


<!-- controllo prima del pagamento: vedere Sicurezza: controllo prima del pagamento -->

<input type="hidden" name="SHASIGN" value="">


<!-- informazioni sul layout: vedere Aspetto della pagina di pagamento -->

<input type="hidden" name="TITLE" value="">
<input type="hidden" name="BGCOLOR" value="">
<input type="hidden" name="TXTCOLOR" value="">
<input type="hidden" name="TBLBGCOLOR" value="">
<input type="hidden" name="TBLTXTCOLOR" value="">
<input type="hidden" name="BUTTONBGCOLOR" value="">
<input type="hidden" name="BUTTONTXTCOLOR" value="">
<input type="hidden" name="LOGO" value="">
<input type="hidden" name="FONTTYPE" value="">

<!-- reindirizzamento dopo il pagamento: vedere Feedback sulla transazione al cliente -->

<input type="hidden" name="ACCEPTURL" value="">
<input type="hidden" name="DECLINEURL" value="">
<input type="hidden" name="EXCEPTIONURL" value="">
<input type="hidden" name="CANCELURL" value="">

<input type="submit" value="" id=submit2 name=submit2>

</form> 

4.2 Parametri del modulo

Sebbene i campi PSPID, ORDERID, AMOUNT, CURRENCY e LANGUAGE siano sufficienti, consigliamo di inviare anche il nome del cliente (CN), l’indirizzo e-mail del cliente (EMAIL), indirizzo (OWNERADDRESS), città (OWNERTOWN), CAP (OWNERZIP), paese (OWNERCTY) e numero di telefono (OWNERTELNO), che possono essere strumenti utili per evitare frodi.

Nella seguente tabella viene fornita una panoramica dei campi nascosti usati per trasmettere i “parametri generali” al nostro sistema (i campi aggiuntivi vengono descritti in questo documento e nella documentazione correlata):

Campo

Descrizione

PSPID Nome di affiliazione al nostro sistema
ORDERID

Numero di ordine (riferimento per il venditore) Il sistema verifica che non sia stato richiesto due volte il pagamento dello stesso ordine.

L'ORDERID deve essere assegnato dinamicamente.

AMOUNT

Importo da pagare MOLTIPLICATO PER 100 in quanto il formato dell'importo non deve contenere decimali o altri separatori.

Il valore di AMOUNT deve essere assegnato dinamicamente.

CURRENCY

Valuta dell'ordine

Codice alfanumerico ISO, ad es. EUR, USD, GBP, ecc.

CN

Nome cliente

Preinizializzato (ma comunque modificabile) nel campo Nome cliente dei dati della carta di credito.

EMAIL Indirizzo email del cliente
OWNERADDRESS Via e numero civico del cliente
OWNERZIP CAP del cliente
OWNERTOWN Città/Località del cliente
OWNERCTY Paese del cliente
OWNERTELNO Numero di telefono del cliente

5. Sicurezza: controllo prima del pagamento

5.1 Firma SHA-IN

Per controllare i dati trasmessi al sistema (nel caso di e-Commerce, i campi nascosti inviati alla pagina di pagamento), Ingenico ePayments richiede il metodo di verifica della sicurezza dei dati SHA. Per ciascun ordine, il server genera una stringa di caratteri univoci (=digest), separata da un trattino dall'algoritmo preferito dall'utente: SHA-1, SHA-256 o SHA-512. Il valore SHA-IN viene popolato automaticamente dal sistema tramite GUID. L'algoritmo SHA predefinito di PSPID è SHA-512. Non modificare la configurazione se il sistema richiede l'algoritmo SHA-1 o SHA-256.

È possibile effettuare un calcolo simile dopo la transazione, per verificare i parametri restituiti con gli URL di reindirizzamento. Quest'operazione viene definita SHA-OUT.

5.1.1 Creazione della stringa

La stringa con il trattino è composta dalla concatenazione dei valori dei campi trasmessi insieme all'ordine, in ordine alfabetico, nel formato ‘PARAMETRO=valore’. Ciascun parametro con il proprio valore è seguito da una passphrase. La passphrase è definita nella pagina "Informazione tecniche" dell'account Ingenico ePayments, nella scheda “Controllo dei dati e d'origine”, sezione “Controlli per e-Commerce”. È importante rispettare la distinzione tra maiuscole e minuscole quando si compilano questi valori per formare la stringa precedente il trattino!

Importante

  • Tutti i parametri inviati (e visualizzati nell'Elenco dei parametri da includere nel calcolo SHA-IN) sono inclusi nella stringa con il trattino.
  • Tutti i nomi dei parametri devono essere in LETTERE MAIUSCOLE (per evitare confusione).
  • Tutti i parametri devono essere disposti in ordine alfabetico.
  • I parametri senza alcun valore NON devono essere inclusi nella stringa dell'algoritmo.
  • Alcuni algoritmi di ordinamento aggiungono caratteri speciali prima della prima lettera dell'alfabeto, mentre altri li aggiungono alla fine. In caso di dubbio, rispettare l'ordine visualizzato nell'elenco SHA.
  • Per una maggiore sicurezza, è necessario utilizzare passphrase SHA diverse per gli ambienti di prova e di produzione.

Quando si effettua l'hash di una stringa composta con l'algoritmo SHA, viene restituito un digest esadecimale. La lunghezza del digest SHA è di 40 caratteri per SHA-1, 64 per SHA-256 e 128 per SHA-512. Il risultato deve essere inviato al sistema nella richiesta dell'ordine mediante il campo “SHASIGN”.

Il sistema ricompone la stringa SHA in base ai parametri ricevuti e confronta il digest del venditore con il digest generato dal sistema. Se il risultato non è identico, l'ordine viene rifiutato. Il controllo serve a garantire che i dati dell'ordine siano esatti e completi.

È possibile controllare qui il valore SHASIGN ed effettuare una transazione di prova con il digest SHA calcolato dal sistema qui.

Esempio di calcolo SHA-1-IN (con soltanto parametri di base)

Parametri (in ordine alfabetico):

AMOUNT=1500 (15.00 x100)
CURRENCY=EUR
LANGUAGE=en_US
ORDERID=1234
PSPID=MyPSPID

Passphrase SHA-IN (nella pagina "Technical information"):
Mysecretsig1875!?

Stringa con hash:
AMOUNT=1500Mysecretsig1875!?CURRENCY=EURMysecretsig1875!?LANGUAGE=en_USMysecretsig1875!?
ORDERID=1234Mysecretsig1875!?PSPID=MyPSPIDMysecretsig1875!?

Digest risultante (SHA-1):
F4CC376CD7A834D997B91598FA747825A238BE0A


Se il campo SHASIGN inviato nei campi HTML nascosti della transazione non corrisponde al campo SHASIGN costruito da parte nostra con i dettagli dell'ordine e la passphrase immessa nel campo della passphrase SHA-IN (nella pagina Technical information), viene visualizzato il messaggio di errore “unknown order/1/s" nei Registri di errore dell'account (nella pagina del pagamento viene visualizzato un messaggio di errore generico).

Se nulla nel campo "SHASIGN" viene inviato nei campi HTML nascosti mentre viene immessa una passphrase nel campo SHA-IN (nella pagina Technical information), ad indicare che si intende utilizzare una firma SHA con ogni transazione –, viene visualizzato il messaggio di errore “unknown order/0/s".

Di seguito il campo nascosto usato per trasmettere la firma SHA al sistema:

Campo Descrizione
SHASIGN Stringa di caratteri univoca per la convalida dei dati dell'ordine. Una stringa contrassegnata con l'algoritmo SHA-1 contiene sempre 40 caratteri.

5.2 Referente

Oltre al controllo SHA, è possibile configurare il controllo del referente. Quest'impostazione permette di controllare l'origine della richiesta di transazione, ovvero l'URL di provenienza della richiesta (= il referente). L'obiettivo è impedire agli URL non autorizzati (non configurati nell'account) di richiamare la pagina di pagamento.

Se si passa alla scheda "Controlle dei dati e d'origine" della pagina Informazione tecniche nella sezione "Controlli per e-Commerce", è possibile immettere uno o più URL da attivare per richiamare la pagina dei  pagamenti: orderstandard.asp / orderstandard_utf8.asp.

Importante

  • L'URL deve iniziare sempre con http:// o https://.
  • È possibile immettere l'URL completo o soltanto il nome di dominio; nell'ultimo caso, tutte le directory secondarie e le pagine del dominio verranno accettate.
  • In presenza di parecchi domini, è possibile immettere diversi URL, ad es. http://www.miosito.com;http://www.miosito.it;https://www.miosito.sicuro.com. Gli URL devono essere separati dai due punti, senza spazi prima o dopo i due punti.
  • Se si esegue una transazione di prova dalla pagina di prova, immettere l'’URL del sito Web come riferimento, altrimenti comparirà un messaggio di errore.
Sebbene il referente permetta al sistema di identificare l'origine di un ordine, non garantisce l'integrità dei dati. Il sistema richiede pertanto l'uso di una firma SHA.

I possibili errori relativi al referente sono "unknown order/1/r" e "unknown order/0/r". Per maggiori informazioni relative agli errori, visitare Errori possibili .

6. Aspetto della pagina del pagamento

ASPETTO: Configurare la pagina di pagamento in modo che rifletta il nostro marchio e le esigenze dei clienti al momento del pagamento, terminando con un imbuto d'acquisto coerente e aumentando la conversione.

Esistono due tipi di informazioni sulla pagina del pagamento ospitata:
  • Informazioni statiche (ad es. il logo)
  • Informazioni sui dati del pagamento (ad es. riferimento ordine, campi in cui il cliente immette i dati della carta, ecc.)
Le informazioni statiche provengono dal layout comune del sistema o da una pagina specifica di modello del venditore. Il sistema aggiunge i dati del pagamento per ogni transazione in modo dinamico. È possibile personalizzare la pagina di pagamento applicando un HTML e CSS personalizzato ai contenuti. Basta semplicemente dirci dove inserire la "ZONA DI PAGAMENTO" responsabile del pagamento nella pagina.

HOSTING SICURO: Ingenico ePayments offre l'hosting sicuro per il modello della pagina di pagamento, che consente di mantenere la conformità allo standard PCI.

Nota: se non si desidera personalizzare la pagina di pagamento, è possibile ignorare la seguente sezione di personalizzazione del modello di demo.

6.1 Modello di Responsive Payment Page Ingenico ePayments

Il nostro modello di pagina di pagamento completamente responsiva è la soluzione perfetta e più semplice per le esigenze dei tuoi clienti nell’online shopping. Garantisce una conversione ottimizzata su dispositivi desktop e mobili.

  • Per attivare il modello di Responsive Payment Page Ingenico ePayments dal back office di Ingenico ePayments, vai a Configurazione > Modello > Selettore modello e fai clic su “Attiva” la Responsive Payment Page.
  • Per personalizzare il template con il tuo logo, vai a Configurazione > Modello > File Gestione file e carica il logo che hai nominato: “logo.png”.

6.2 Modifica e carica il tuo modello personalizzato

Inizia scaricando il file sorgente del modello della pagina di pagamento responsiva di Ingenico ePayments in basso, quindi personalizzalo liberamente adattandolo alle esigenze specifiche del tuo marchio. Il modello può essere progettato interamente in base alle proprie esigenze, lasciando solo un’area libera sulla pagina che sarà completata dal nostro sistema. Puoi anche salvare il tuo modello di pagina e i tuoi file sul nostro ambiente protetto, da noi chiamato “modello statico”.

Download del modello per le pagine di pagamento di e-Commerce

I nostri modelli supportano i browser sia dei desktop che dei dispositivi mobili. È possibile usarli così come sono oppure personalizzarli, per adattarli alle proprie esigenze. È sufficiente adattare i diversi valori con i file modello css per ottenere la pagina desiderata.

Oltre a personalizzare i file css forniti, puoi anche completare l’HTML aggiungendo le tue informazioni di intestazione e piè di pagina. Consulta il Capitolo 6.2.2 per ulteriori informazioni. Per motivi di sicurezza, non applicare dati o file esterni non autorizzati; tutti i file e i dati devono essere caricati in Gestione file per poter essere utilizzati. Una volta completato, seguire questa procedura per scaricare e applicare gratuitamente i modelli:

  1. Scaricare il  file zip.
  2. Per attivare i modelli statici, dal Back Office selezionare Configurazione > Modello > Configurazione avanzala > Consenti l'utilizzo di un modello dinamico) > Sì.
  3. Per caricare i vari file inclusi nel file zip (non nella cartella), selezionare Configurazione > Modello > File manager.
  4. Per selezionare il proprio Modello predefinito esercente per l'e-Commerce, selezionare Configurazione > Modello > Selezione modello.

Nota: 

  • Se non si intende personalizzare la pagina di e-Commerce, fermarsi qui. Per maggiori informazioni sulla personalizzazione della pagina di e-Commerce con il nostro modello, passare alla sezione successiva.
  • La piattaforma supporta diversi modelli. È possibile ignorare il modello predefinito per ogni qualsiasi transazione e selezionarne uno specifico applicando il parametro "TP" nella richiesta POST (TP=<nome completo del file HTML inclusa l'estensione>).

Personalizzazione intensa: progettazione della pagina di pagamento

Oltre a personalizzare i file css, è possibile completare il file HTML aggiungendo la propria intestazione e pie' di pagina. Per maggiori informazioni, consultare il Capitolo 6.2.2. Per questioni di sicurezza, non usare dati/file esterni non autorizzati. Tutti i file e i dati devono essere caricati in File Manager per essere usati.

6.2.1 Campi nascosti

Il seguente campo nascosto serve a trasmettere l'URL della pagina del modello:

<input type="hidden" name="TP" value="">

Campo
Descrizione
TP Nome di file del modello ospitato da Ingenico ePayments.

6.2.2 Zona di pagamento

La pagina del modello dinamico può essere progettata in base alle proprie preferenze. L'unico requisito è che deve contenere la stringa "$$$PAYMENT ZONE$$$" ad indicare il punto in cui il modulo e-Commerce può aggiungere dinamicamente i campi. Pertanto, deve contenere almeno:

<html>
$$$PAYMENT ZONE$$$
</html>

Importante

Non utilizzare tag BASE, frame o tag FORM per incapsulare la stringa $$$PAYMENT ZONE$$$.

6.2.3 Fogli di stile

È possibile personalizzare l'aspetto delle pagine di pagamento aggiungendo alla pagina del modello i fogli di stile.

Abbiamo definito una classe per i vari tipi di tabelle e celle nelle tabelle e una classe per i pulsanti di inoltro. È necessario aggiungere il seguente blocco di codice tra i tag <head></head>, nonché modificare le proprietà delle classi per adattarle all'aspetto del sito (v. ad esempio la pagina di modello descritta sopra):

<style type="text/css">
<!--
td.ncolh1 {background-color : #006600; color : yellow; font-family : verdana}
td.ncoltxtl {background-color : #ffffcc; color : black; text-align : right; font-weight : bold}
td.ncoltxtl2 {background-color : #ffffcc; color : black; text-align : right; font-weight : bold}
td.ncoltxtr {background-color : #ffffcc; color : black; text-align : left; font-weight : bold}
td.ncoltxtc {background-color : #ffffcc; color : black; text-align : center; font-weight : bold}
td.ncolinput {background-color : #ffffcc; color : black}
td.ncolline1 {background-color : #ffffff; color : black}
td.ncolline2 {background-color : #ffffcc; color : black}
input.ncol {background-color : #006600; color : white}
td.ncollogoc {background-color : #ffffcc; color : black; text-align : center; font-weight : bold}
table.ncoltable1 { background-color: #ffffcc;   }
table.ncoltable2 { background-color: #ffffcc;  border-width : medium; border-color : green; }
table.ncoltable3 { background-color: #ffffcc;   }
-->
</style>

Quando si immettono le proprie istruzioni per il layout, è necessario rispettare la sintassi del foglio di stile CSS. Si consiglia di provare su vari browser, poiché le modalità di gestione dello stile possono essere molto diverse.

6.3 Modello dinamico

La pagina del modello dinamico permette di personalizzare il design delle pagine di pagamento in modalità molto più avanzata rispetto al modello statico.

Quando si utilizza una pagina di un modello dinamico, si progetta la propria pagina di modello e il sistema completa soltanto un'area nella pagina. È necessario inviarci l'URL del modello nei campi nascosti per ogni transazione.

Tenere presente che l'utilizzo di una pagina di modello dinamico comporta una richiesta aggiuntiva del sistema di ricerca della pagina del modello. Il processo di pagamento dura quindi di più.

Importante

Per risultare conformi allo standard PCI-DSS più recente (vedere qui), è necessario ospitare il modello (e i rispettivi file) in un ambiente con la certificazione PCI più elevata. Qualora ciò non fosse possibile, consigliamo di ospitare i file di modello con Ingenico ePayments tramite un modello statico e Template File Manager. Tenere presente tuttavia che in questo modo il modello potrebbe perdere parte del suo comportamento dinamico (a seconda della propria integrazione).


6.3.1 Campi nascosti

Il seguente campo nascosto serve a trasmettere l'URL della pagina del modello:

<input type="hidden" name="TP" value="">

Campo
Descrizione
TP URL della pagina del modello dinamico del venditore (la pagina deve essere ospitata dal venditore). L'URL deve essere assoluto (contenere l'intero percorso) e non può essere relativo. Non specificare nessuna porta nell'URL; accettiamo soltanto le porte 443 e 80. Tutti i componenti inclusi nella pagina del modello devono avere anche un URL assoluto.

6.3.2 Zona di pagamento

La pagina del modello dinamico può essere progettata in base alle proprie preferenze. L'unico requisito è che deve contenere la stringa "$$$PAYMENT ZONE$$$" ad indicare il punto in cui il modulo e-Commerce può aggiungere dinamicamente i campi. Pertanto, deve contenere almeno:

<html>
$$$PAYMENT ZONE$$$
</html>

Importante

Non utilizzare tag BASE, frame o tag FORM per incapsulare la stringa $$$PAYMENT ZONE$$$.

6.3.3 Comportamento dinamico

La stessa pagina di modello può essere utilizzata per tutti gli ordini oppure può essere generata dinamicamente dall'applicazione del venditore in base agli altri parametri.

Per generare dinamicamente la pagina del modello, il venditore può scegliere se creare una pagina specifica per l'ordine il cui URL viene trasmesso nei campi nascosti oppure se usare un URL fisso ma restituire un risultato ottenuto dal numero di ordine. Affinché ciò sia possibile, il sistema aggiunge i dati principali del pagamento – incluso il numero di riferimento dell'ordine del venditore (cfr. Elaborazione dopo il pagamento) – quando recupera la pagina di pagamento:

Richiesta HTTP = url_page_template ?ORDERID=...&AMOUNT=...&CURRENCY=…

6.3.4 Fogli di stile

È possibile personalizzare l'aspetto delle pagine di pagamento aggiungendo alla pagina del modello i fogli di stile.

Abbiamo definito una classe per i vari tipi di tabelle e celle nelle tabelle e una classe per i pulsanti di inoltro. È necessario aggiungere il seguente blocco di codice tra i tag <head></head>, nonché modificare le proprietà delle classi per adattarle all'aspetto del sito (v. ad esempio la pagina di modello descritta sopra):

<style type="text/css">
<!--
td.ncolh1 {background-color : #006600; color : yellow; font-family : verdana}
td.ncoltxtl {background-color : #ffffcc; color : black; text-align : right; font-weight : bold}
td.ncoltxtl2 {background-color : #ffffcc; color : black; text-align : right; font-weight : bold}
td.ncoltxtr {background-color : #ffffcc; color : black; text-align : left; font-weight : bold}
td.ncoltxtc {background-color : #ffffcc; color : black; text-align : center; font-weight : bold}
td.ncolinput {background-color : #ffffcc; color : black}
td.ncolline1 {background-color : #ffffff; color : black}
td.ncolline2 {background-color : #ffffcc; color : black}
input.ncol {background-color : #006600; color : white}
td.ncollogoc {background-color : #ffffcc; color : black; text-align : center; font-weight : bold}
table.ncoltable1 { background-color: #ffffcc;   }
table.ncoltable2 { background-color: #ffffcc;  border-width : medium; border-color : green; }
table.ncoltable3 { background-color: #ffffcc;   }
-->
</style>

Quando si immettono le proprie istruzioni per il layout, è necessario rispettare la sintassi del foglio di stile CSS. Si consiglia di provare su vari browser, poiché le modalità di gestione dello stile possono essere molto diverse.

6.3.5 Prestazioni

Il nostro sistema è configurato con un timeout di 5 secondi affinché la richiesta recuperi la pagina del modello dinamico del venditore.

Il timeout (HTTPTimeOut) può essere modificato da parte nostra su richiesta del cliente (tramite un support ticket).

Se si verifica un timeout, il sistema utilizza il modello statico del venditore.

Se non è configurato nessun modello statico, il sistema utilizza il modello statico di Ingenico ePayments come ultima risorsa.

Il campo HTTPTimeOut incide sia sulle richieste di modello dinamico che sulle richieste di feedback dopo il pagamento (vedere Richieste dirette di feedback (post-pagamento)). Di conseguenza, se il venditore decide di modificare il timeout ad esempio su 15 secondi, anche il timeout della richiesta di feedback aumenta a 15 secondi.

Per ogni ordine, il sistema esegue una richiesta di recupero della pagina del modello dinamico. In presenza di volumi elevati di transazioni o di una grande pagina di modello (ad es. la pagina del modello dinamico contiene molte immagini), queste richieste HTTP possono durare a lungo. In presenza di volumi elevati di transazioni, rivolgersi al nostro team di vendita per una soluzione.

6.4 Modello mobile

È possibile ottimizzare la visualizzazione della pagina del pagamento sui dispositivi mobili (smartphone, tablet, ecc.) applicando una pagina del modello, arricchita con fogli di stile, come spiegato nei capitoli successivi.

6.4.1 Parametri di layout

Di seguito vengono riportati i campi che è possibile personalizzare fornendo i dettagli in una richiesta:

<input type="hidden" name="TITLE" value="">
<input type="hidden" name="BGCOLOR" value="">
<input type="hidden" name="TXTCOLOR" value="">
<input type="hidden" name="TBLBGCOLOR" value="">
<input type="hidden" name="TBLTXTCOLOR" value="">
<input type="hidden" name="BUTTONBGCOLOR" value="">
<input type="hidden" name="BUTTONTXTCOLOR" value="">
<input type="hidden" name="LOGO" value="">
<input type="hidden" name="FONTTYPE" value="">

Campo

Descrizione

Valore predefinito

TITLE Titolo di pagina Title
BGCOLOR Colore di fondo white
TXTCOLOR Colore testo black
TBLBGCOLOR Colore di fondo delle colonne a destra white
TBLTXTCOLOR Colore di testo delle colonne a destra black
BUTTONBGCOLOR Colore di fondo del pulsante n/d
BUTTONTXTCOLOR Colore di testo del pulsante black
LOGO

URL/nome di file del logo da visualizzare nella pagina del pagamento

https://secure.ogone.com/images/merchant/[PSPID]/[immagine]

-
FONTTYPE

Famiglia di caratteri

Verdana

6.4.2 Modello

Il seguente campo nascosto serve a trasmettere l'URL della pagina del modello:

<input type="hidden" name="TP" value="">

Campo Descrizione
TP

URL della pagina del modello dinamico. L'URL deve essere assoluto (contenere l'intero percorso) e non può essere relativo. Tutti i componenti inclusi nella pagina del modello devono avere anche un URL assoluto.

Importante: Per garantire la conformità con i più recenti PCI-DSS (2015), è necessario ospitare le voci modello utilizzate nella pagina dei pagamenti in un ambiente con la certificazione PCI più elevata. Pertanto si raccomanda di ospitare i file con Ingenico ePayments, utilizzando File Manager.

Zona di pagamento

La pagina del modello può essere progettata in base alle proprie preferenze. L'unico requisito è che deve contenere la stringa "$$$PAYMENT ZONE$$$" ad indicare il punto in cui il modulo e-Commerce può aggiungere dinamicamente i campi. Pertanto, deve contenere almeno:

<html>
$$$PAYMENT ZONE$$$
</html>

Vedere i  modelli di esempio per trarre ispirazione dai modelli creati da noi oppure semplicemente per creare modelli personali basati sui nostri modelli.

6.4.3 Fogli di stile (css)

Per semplificare la gestione e la comprensione di CSS, abbiamo diviso il modello CSS in quattro parti principali:

 

Intestazione

Questo stile consente di modificare l'intestazione della pagina dei pagamenti, come illustrato di seguito:

Elemento/i

- Parte del lucchetto

.securedBG
{
background: #797979;
}
.secured
{
padding: 8px 20px 0px 40px;
color: #ffffff;
width: 235px;
margin: 0 auto;
background: url("lock.png") 5px no-repeat #797979;
height: 30px;
}

- Riepilogo ordine

table.ncoltable1
{
width: 100%;
margin: 0 auto;
min-width: 300px !important;
}
td.ncoltxtl
{
font-family: open-sans ,Verdana,sans-serif;
font-size: 14px;
background-color:#ffffff;
text-align : left !important;
font-weight : bold !important;
vertical-align:bottom;
}
td.ncoltxtr
{
text-align: left;
font-weight: normal;
font-family: open-sans ,Verdana,sans-serif;
font-size: 14px;
background-color:#ffffff;
}

 

Dettagli del pagamento

Questo stile permette di personalizzare la sezione relativa ai dettagli del pagamento, come illustrato di seguito:

td.ncolinput
{
text-align: left;
font-weight: normal;
font-size: 14px;
font-family: open-sans ,Verdana,sans-serif;
display: block;
box-shadow: none !important;
}
input.ncol
{
background-color: #ffffff;
height: 40px;
font-size: 14px;
text-align: center;
padding: 0px;
font-family: open-sans ,Verdana,sans-serif;
margin: 0 35px 20px;
border-bottom: 1px solid #999999;
border-radius: 0px;
-webkit-appearance: none !important;
-webkit-border-radius: 0 !important;
}
td.ncoltxtl2
{
text-align: left;
font-family: open-sans ,Verdana,sans-serif;
white-space: nowrap;
display: block;
font-size: 14px;
background-color:#ffffff;
}

 

Piè di pagina

Questo stile consente di impostare il piè di pagina della pagina dei pagamenti:

Elemento/i

td.ncollogoc
{
text-align: center;
font-weight: normal;
font-size: 14px;
padding: 2px;
vertical-align: top !important;
}
td.ncollogoc IMG
{
width: 90px;
height: 55px;
margin-right: 4px;
}
.ncollogoc td .ncol
{
width: auto;
padding-right: 10px;
padding-left: 10px;
cursor:pointer;
}
.ncollogoc input.ncol
{
margin-top:10px !important;
-webkit-appearance: none !important;
-webkit-border-radius: 0 !important;
}

 

Sezione relativa allo stato del pagamento

Questa sezione consente di personalizzare l'aspetto della pagina di stato del pagamento, come illustrato qui:

Elemento/i

td.ncoltxtc
{
background-color:#ffffff;
color:#999999;
padding: 0px;
text-align: left;
font-weight: normal;
font-size: 14px;
border-top: 0px solid #ffffff;
font-family: open-sans ,Verdana,sans-serif;
}
td.ncoltxtc h3
{
text-align: center;
font-weight: normal !important;
padding: 5px;
font-family: open-sans ,Verdana,sans-serif;
}
td.ncoltxtmessage
{
background-color: #ffffff;
color: #999999;
text-align: left;
font-weight: normal;
}

 

La pagina risultante potrebbe avere il seguente aspetto:

6.4.4 Pagine di esempio

Per iniziare, abbiamo creato due pagine.

La prima è una versione che si può prendere ad esempio:

https://secure.ogone.com/ncol/StandardMobileTemplate.htm

Si può anche utilizzare la seguente versione "spoglia" come base per la creazione di un modello:

https://secure.ogone.com/ncol/StandardMobileTemplate_generic.htm

Questi due modelli sono disponibili qui in formato compresso scaricabile insieme a file aggiuntivi (caratteri e immagini).

6.5 Template File Manager

Template File Manager consente di gestire facilmente i modelli e i vari file ad essi associati.

Per iniziare a usare File Manager, accedere al proprio account Ingenico ePayments, quindi aprire "Configurazione" > "Modello" > "File Manager".

Importante
Non è possibile usare simultaneamente i file precedentemente caricati da Ingenico ePayments e i file caricati con File Manager nella propria integrazione.
Quindi, se sono presenti file caricati da Ingenico ePayments in passato, caricare di nuovo questi file personalmente, utilizzando File Manager.

6.5.1 Caricamento di file modello (template)

Sotto "Carica file modello", selezionare il pulsante "File..." per cercare i file che si desidera caricare. È possibile caricare Javascripts, html, css e immagini (.css, .jpg, .jpeg, .gif, .png, .html, .js), con un massimo di 7 MB a file, e 10 MB in totale.

Effettuare la selezione e confermare.

6.5.2 Controllo e gestione dei file caricati

Al termine del caricamento, i file appariranno nella stessa pagina nella sezione "File caricati".

I file presenteranno prima lo stato "Convalida", durante il quale vengono eseguiti alcuni necessari controlli di sicurezza/antivirus.

I file potranno essere usati quando lo stato passa a "Convalidato".

Fare clic sul pulsante di aggiornamento  per verificare l'attuale stato dei file / fare clic sul pulsante di eliminazione  per eliminare il file in modo permanente.

Un file assumerà lo stato "Rifiutato" se non passa il controllo di sicurezza. Ciò può essere dovuto a un virus o, ad esempio, se l'estensione del file è errata. 

6.5.3 Integrazione

Nei modelli si fa riferimento ai file caricati con un codice che segue questa struttura: $$$TP RESOURCES URL$$$/[nome file].

Se tuttavia si desidera usare una risorsa in un file CSS, fare riferimento al seguente codice: "./[nome file]

Esempio:

Per fare riferimento al modello caricato nella propria integrazione e-Commerce, si invia il nome file del modello con il parametro "TP".

Esempio: TP=mytemplatefile.html

Quando è presente un'integrazione di base e-Commerce con un logo in cima alla pagina, occorre fare riferimento al logo caricato inviando il nome file insieme al parametro "LOGO".

Esempio: LOGO=mycompanylogo.png

6.6 Controllo di sicurezza del modello

Per proteggere i clienti da attività fraudolente, come la manipolazione dei dati riservati della carta di credito (numero di carta, codice CVC), sono disponibili diversi controlli di sicurezza per il modello per venditori.

Nella pagina Informazione tecniche, scheda "Parametri globali di sicurezza", sezione "Modello", è possibile configurare le seguenti impostazioni:

  • Abilita controllo JavaScript sul modello
    È possibile attivare questa funzione per rilevare l'utilizzo di Javascript sulla pagina del modello. Se si rileva Javascript, il modello viene bloccato e al suo posto viene utilizzato il modello predefinito.
  • Consenti l'utilizzo di un modello dinamico (facoltativo, dipende dall'abbonamento sottoscritto)
    Se si seleziona "Consenti l'utilizzo di un modello dinamico", è necessario configurare il campo Trusted website host name (nome host del sito Web attendibile) che ospita il campo del modello dinamico. Il campo può contenere diversi host Web, separati da punto e virgola, che però devono contenere l'URL completo. Esempio: http://www.website.com/. È possibile escludere le directory secondarie, in modo che sia sufficiente configurare http://www.website.com come host Web attendibile se il modello dinamico è http://www.website.com/templates/nl/template1.htm.

    Inoltre, è possibile configurare uno o più URL di modelli dinamici attendibili, separati da punto e virgola, nel campo Trusted dynamic template url (URL modello dinamico attendibile).

Se in una transazione viene trasmesso un modello dinamico ma i modelli dinamici non sono consentiti, il modello viene bloccato e il sistema utilizza invece il modello statico.
In assenza di modelli statici configurati oppure, viene utilizzato il modello Ingenico ePayments predefinito. Per impostazione predefinita, le opzioni "Abilita controllo JavaScript sul modello" sono attivate.

6.7 Blocchetto dell'ambiente sicuro

L'URL usato per collegare il cliente alla piattaforma si basa su un protocollo sicuro (https). Tutte le comunicazioni tra la nostra piattaforma e-Commerce e il cliente sono crittografate in modo sicuro.

È possibile tuttavia che il lucchetto piccolo sul browser, che indica al cliente che il sito è sicuro, non venga visualizzato qualora alcuni elementi (ad es. le immagini) nella pagina del modello non siano posti su un server sicuro oppure se alcuni frame nella schermata mostrano pagine non provenienti da siti sicuri.

Anche se le comunicazioni sull'elaborazione del pagamento sono crittografate, la maggior parte dei browser non riconosce una connessione sicura ad eccezione del caso in cui tutti gli elementi sullo schermo, incluse le immagini, l'audio, ecc., provengano da siti sicuri.

I venditori che non hanno un sito sicuro devono tenere a mente quanto segue:

  1. Non utilizzare frame per le pagine di pagamento: è possibile aggiornare tutta la schermata con una pagina di modello che faccia sembrare che si utilizzino i frame oppure consentire l'elaborazione del pagamento in una nuova finestra.
  2. non collegare file alla pagina del modello (tag <link>) utilizzata per la pagina del pagamento. Utilizzare invece i tag <style> e <script> per includere stili e script nella pagina di modello.
  3. Verificare che le immagini nel modello siano salvate su un server sicuro (la pagina del modello può trovarsi su un server non sicuro, a differenza delle immagini). È disponibile l'hosting di questi elementi (vedere le opzioni di hosting delle immagini nel proprio account).

6.8 Uso della pagina di pagamento in Iframe

IFrame consente di integrare una pagina Web esterna (ad esempio la pagina del pagamento) nel sito Web dell'URL, pur mantenendo l'URL nel browser.

L'IFrame del contesto tuttavia ha anche notevoli svantaggi:

  • Dato che l'URL è l'URL del venditore, può trattarsi di un semplice http (anziché https) ed è possibile che l'icona del blocchetto non venga visualizzata nel browser. Questo potrebbe indurre i clienti a dubitare sulla sicurezza del negozio online.
  • Alcuni metodi di pagamento (ad esempio Giropay, Sofort, Bancontact/Mister Cash e PayPal) usano il reindirizzamento, compromettendo il layout e/o causando problemi di navigazione.

Di conseguenza, Ingenico ePayments non consiglia IFrame, il cui eventuale utilizzo è di responsabilità dell'utente. Ingenico ePayments consiglia vivamente di utilizzare invece un modello dinamico.

Se si desidera comunque integrare IFrame, si consiglia di seguire alcune regole:

  • Utilizzare IFrame soltanto nella pagina di scelta del metodo di pagamento (e successive)
  • Usare i popup per i metodi di pagamento esterni laddove possibile, per garantire la visibilità di applicazioni Web di terzi.

7. Feedback sulla transazione

In seguito all'elaborazione di una transazione, in base al risultato, è possibile che venga inviata una risposta al sistema e al cliente. Di seguito viene spiegato in che modo e quando è possibile inviare il feedback sulla transazione e cosa si deve configurare e impostare per garantire l'efficacia di ogni processo di feedback.

Procedure consigliate

Reindirizzamento con i parametri su accept-/exception-/cancel-/declineurl (Reindirizzamento con aggiornamento del database) con richiesta differita di feedback dopo il pagamento come riserva (Feedback da server a server (post-pagamento)).

Nell'account Ingenico ePayments selezionare "Configurazione" > "Informazione tecniche" > "Ritorno d'informazione della transazione". Configurare le impostazioni come descritto di seguito: 

Reindirizzamento HTTP nel browser:

Feedback sugli URL di reindirizzamento

Richiesta HTTP diretta da server a server: sempre differita:

Feedback differito dopo il pagamento 

7.1 Reazione predefinita

In base alle impostazioni predefinite, se non sono state configurate le impostazioni di feedback sulla transazione, il cliente visualizza un messaggio standard: "Pagamento autorizzato" oppure "Transazione rifiutata".

In questa pagina aggiungiamo anche un collegamento al vostro sito Web e/o al vostro catalogo. In genere questi collegamenti sono configurati nei dettagli amministrativi dell'account Ingenico ePayments, da cui il sistema li recupera. È possibile anche sostituire gli URL inviando i campi HOMEURL e CATALOGURL insieme agli altri campi nascosti nel modulo dell'ordine:

<input type="hidden" name="CATALOGURL" value="">
<input type="hidden" name="HOMEURL" value="">

Campo
Descrizione
CATALOGURL URL (assoluto) del catalogo. Dopo l'elaborazione della transazione, al cliente viene richiesto di tornare all'URL con un pulsante.
HOMEURL

URL (assoluto) della home page. Dopo l'elaborazione della transazione, al cliente viene richiesto di tornare all'URL con un pulsante.

Se si invia il valore “NONE”, il pulsante che rimanda al sito Web del venditore viene nascosto.

7.2 Reindirizzamento in base al risultato della transazione

In base al risultato, dopo la transazione il sistema può reindirizzare il cliente verso quattro URL: "ACCEPTURL", "EXCEPTIONURL", "CANCELURL" e "DECLINEURL".

Gli URL possono essere configurati o trasmessi nel seguente modo:

  • Configurazione nell'account Ingenico ePayments: Nella scheda Transaction feedback della pagina Informazione tecniche: "Ridirezione HTTP nel navigatore"
  • Invio degli URL nei campi nascosti del modulo dell'ordine:

    <input type="hidden" name="ACCEPTURL" value="">
    <input type="hidden" name="DECLINEURL" value="">
    <input type="hidden" name="EXCEPTIONURL" value="">
    <input type="hidden" name="CANCELURL" value="">

    Campo Descrizione
    ACCEPTURL URL della pagina Web che il cliente deve visualizzare dopo che il pagamento viene autorizzato (stato 5), archiviato (stato 4), accettato (stato 9) o è in attesa di accettazione (stato in sospeso 41, 51 o 91).
    DECLINEURL URL della pagina Web che il cliente deve visualizzare quando l'acquirente rifiuta l'autorizzazione (stato 2 o 93) oltre al numero massimo ammissibile di volte.
    EXCEPTIONURL URL della pagina Web che il cliente deve visualizzare quando il risultato del pagamento è incerto (stato 52 o 92).
    Se il campo è vuoto, il cliente viene invece reindirizzato su ACCEPTURL.
    CANCELURL URL della pagina Web che il cliente deve visualizzare quando annulla il pagamento (stato 1).
    Se il campo è vuoto, il cliente viene invece reindirizzato su DECLINEURL.

Notifica di avviso del browser: da ambiente sicuro ad ambiente non sicuro

Quando un cliente torna dalle pagine di pagamento sicuro al sito Web del venditore, il browser lo può avvisare che sta accedendo a un ambiente non sicuro, dato che probabilmente sta passando da un ambiente https:// a un ambiente http://.

Quando viene rilevato il reindirizzamento al sito Web, possiamo mostrare un messaggio che avvisa il cliente circa la possibilità di rischi, evitando pertanto preoccupazioni infondate per un avviso del browser. È possibile attivare la seguente opzione nella sezione “Ridirezione HTTP nel navigatore" della scheda Ritorno d'informazione... della pagina Informazione tecniche: “Voglio Ingenico ePayments mostrare un testo corto al cliente sulla pagina di pagamento se una ridirezione al mio sito web è individuata appena dopo il processo di pagamento.”

7.3 Reindirizzamento con aggiornamento del database

È possibile usare il reindirizzamento negli URL di reindirizzamento per avviare automaticamente attività di back-office come gli aggiornamenti del database. Quando viene eseguita una transazione, possiamo inviare i parametri della transazione agli URL di reindirizzamento.

Per usare questa funzionalità è necessario attivare la seguente opzione nella sezione “Ridirezione HTTP nel navigatore" della scheda Ritorno d'informazione... della pagina Informazione tecniche:

  • “Desidero ricevere i parametri di ritorno delle transazioni sugli URL di redirezione.”

7.3.1 SHA-OUT

Il reindirizzamento avviene mediante il browser del cliente, che lo rende visibile. Occorre pertanto usare una firma SHA-OUT per controllare i contenuti della richiesta ed impedire ai clienti di manomettere i dati nel campo URL, effettuando aggiornamenti fraudolenti del database.

Se la firma SHA-OUT non viene configurata, non viene inviato alcun parametro negli URL di reindirizzamento.

La stringa di cui effettuare l'hash è composta dalla concatenazione dei valori dei campi trasmessi insieme all'ordine, in ordine alfabetico, nel formato ‘parametro=valore’, seguiti da una passphrase. La passphrase è definita nella scheda Transaction feedback della pagina Technical information, nella sezione “Tutti I modi di sottomissione delle transazione”.



Per un elenco completo dei parametri da includere nel digest SHA, vedere l'elenco dei parametri SHA-OUT. Questi valori operano una distinzione tra maiuscole e minuscole.

Importante

  • Tutti i parametri trasmessi (visualizzati nell'elenco dei parametri SHA-OUT) sono inclusi nella stringa di cui effettuare l'hash.
  • Tutti i parametri devono essere in ordine alfabetico.
  • I parametri senza alcun valore NON devono essere inclusi nella stringa dell'algoritmo.
  • Anche se alcuni parametri vengono (parzialmente) restituiti dal sistema con caratteri minuscoli, per il calcolo SHA-OUT ogni parametro deve essere scritto in maiuscolo.
  • Se si sceglie di trasferire l'account di prova alla produzione mediante il collegamento nel menu del back-offfice, nell'account di produzione viene automaticamente configurata una passphrase SHA-OUT casuale.
  • Per una maggiore sicurezza, è necessario utilizzare passphrase SHA diverse per gli ambienti di prova e di produzione. Se le passphrase sono identiche, la passphrase di PROVA verrà modificata dal sistema (l'utente riceverà una notifica).

Allo stesso modo in cui dobbiamo ricreare il digest per convalidare i dati della transazione con SHA-IN, occorre ricostituire l'hash, usando però la passphrase SHA-OUT e i parametri ricevuti dal sistema.

Se il risultato non è identico, è possibile che i parametri della richiesta siano stati manomessi. Questo controllo garantisce la precisione e l'integrità dei valori dei parametri inviati nella richiesta.

Esempio di calcolo di base SHA-1-OUT



Parametri (in ordine alfabetico, come vengono restituiti da Ingenico ePayments):

ACCEPTANCE: 1234

amount: 15

BRAND: VISA

CARDNO: XXXXXXXXXXXX1111

currency: EUR

NCERROR: 0

orderID: 12

PAYID: 32100123

PM: CreditCard

STATUS: 9



Passphrase SHA-OUT (in Informazione tecniche):

Mysecretsig1875!?



Stringa di cui effettuare l'hash (tutti i parametri maiuscoli):

ACCEPTANCE=1234Mysecretsig1875!?AMOUNT=15Mysecretsig1875!?BRAND=VISAMysecretsig1875!?

CARDNO=XXXXXXXXXXXX1111Mysecretsig1875!?CURRENCY=EURMysecretsig1875!?NCERROR=0

Mysecretsig1875!?ORDERID=12Mysecretsig1875!?PAYID=32100123Mysecretsig1875!?

PM=CreditCardMysecretsig1875!?STATUS=9Mysecretsig1875!?



Digest risultante (SHA-1):

209113288F93A9AB8E474EA78D899AFDBB874355

7.4 Feedback da server a server (post-pagamento)

Dopo l'elaborazione della transazione, il nostro sistema può inviare una richiesta http per trasmettere i dati della transazione a un URL specificato. Questo processo, in genere denominato richiesta "post-vendita", consente di aggiornare il database con lo stato dell'ordine, ecc. e di avviare un processo “di fine ordine” (qualora ciò non sia già avvenuto dopo un reindirizzamento). Si tratta anche di un'alternativa per generare una risposta personale al cliente in caso di esigenze specifiche (qualora ciò non sia già avvenuto mediante reindirizzamento).

Il set di parametri di feedback coincide con quelli del reindirizzamento ed è disponibile alla pagina Parametri di feedback.

7.4.1 URL post-pagamento

È possibile definire gli URL di due pagine eseguibili sul sito Web nella scheda "Ritorno d'informazione...", nella sezione (campi URL) "Ridirezione HTTP nel navigatore" della pagina Informazione tecniche:

  • In condizioni ideali, il primo campo contiene l'URL al quale vengono inviati i parametri della richiesta qualora lo stato del pagamento sia accettato, in sospeso o incerto.
  • Il secondo campo può essere l'URL al quale vengono inviati i parametri della richiesta quando la transazione viene annullata dal cliente o rifiutata troppe volte dall'acquirente (ad es. oltre il numero massimo consentito di tentativi di pagamento, in base alle impostazioni della scheda "Parametri globali della transazione" nella sezione "Riprovare il pagamento" della pagina Informazione tecniche).

È possibile immettere due URL diversi oppure usare due volte lo stesso URL. È possibile anche immettere un URL soltanto nel primo campo, ma non nel secondo.

Non specificare nessuna porta nell'URL; accettiamo soltanto le porte 443 e 80.

URL post-pagamento variabili per diversi negozi

Se nella pagina Informazione tecniche dell'account è stata configurata una pagina dopo il pagamento ma ci sono diversi negozi, ciascuno connesso a una directory specifica per la ricezione di feedback dopo il pagamento, una parte dell'URL dopo il pagamento può essere variabile.

La parte variabile può anche essere utilizzata, ad esempio, per "adattare" la richiesta di feedback in modo che includa informazioni sulla sessione, trasmettendola come parte di URL anziché come parametro aggiuntivo. Questo è il caso delle piattaforme Intershop o dei sistemi Servlet.

Conviene utilizzare il seguente campo nascosto:

<input type="hidden" name="PARAMVAR" value="">

Esempio:

URL post-pagamento nella pagina Informazione tecniche:
https://www.sitoWebdelcliente.com/<PARAMVAR>/paginadelcliente.asp

Ulteriore campo nascosto inviato nel modulo dell'ordine:
<input type="hidden" name="PARAMVAR" value="shop1">

Per la transazione risulta il seguente URL post-pagamento:
https://www.sitoWebdelcliente.com/shop1/paginadelcliente.asp

Importante: non utilizzare caratteri speciali nel campo PARAMVAR, poiché il loro URL è codificato e potrebbero creare collegamenti non validi.

7.4.2 Tempistica della richiesta

Quando si configurano gli URL post-pagamento, bisogna scegliere anche quando inviare la richiesta di feedback:

  • Nessuna richiesta

    In questo caso il sistema non invia richieste di feedback. Quest'opzione consente di disattivare gli URL post-pagamento in caso di manutenzione o problemi sul server.
  • Sempre differita (non subito dopo il pagamento)

    La richiesta di feedback viene inviata poco dopo la fine del processo di pagamento. La richiesta di feedback è un'attività in background e non può essere utilizzata per inviare un feedback personalizzato al cliente sul sito Web.

    Se non si utilizza la pagina post-pagamento per personalizzare una risposta ai clienti, è possibile ricevere la richiesta di feedback in background e differita.
  • Sempre online (subito dopo il pagamento, per consentire la personalizzazione della risposta vista dal cliente)

    La richiesta di feedback viene inviata “online” dopo che il sistema riceve la risposta dell'acquirente e prima di notificare al cliente il risultato del pagamento.

    In questo caso, il processo di pagamento dura di più per il cliente, ma è possibile inviare al cliente una risposta personalizzata.

    Lo svantaggio del processo di feedback sul post-pagamento online è che il sistema si può rallentare in presenza di troppe richieste alla pagina di post-pagamento (ad es. volume elevato di transazioni al minuto). Ciò potrebbe allungare i tempi di risposta prima che il cliente riceva un feedback sullo schermo.
  • Online ma passa alla richiesta differita nei momenti in cui le richieste online non vengono effettuate

    Quest'opzione consente ai venditori che necessitano di feedback post-pagamento online (per personalizzare la risposta presentata al cliente) di avere un'opzione di riserva qualora la richiesta online sulla pagina di post-pagamento non riuscisse. In questo caso, il sistema ritenta la richiesta di feedback ogni 10 minuti per un massimo di quattro volte (differita). In questo modo non si perde il feedback sulla transazione qualora la richiesta di feedback dopo il pagamento online non riesca, ad es. a causa di temporanei problemi di server da parte nostra. Al cliente viene mostrato il feedback standard sulla transazione del sistema (v. Reazione predefinita).

7.4.3 Risposta al cliente

Per mostrare un feedback (fine della pagina della transazione) al cliente, utilizziamo una possibile risposta dalla vostra pagina post-pagamento.

Se la pagina post-pagamento risponde con una pagina HTML (contenente un tag <html>) oppure un reindirizzamento (HTTP 302 Object Moved), il nostro sistema invia la pagina HTML “così com'è” al browser del cliente oppure esegue il reindirizzamento anziché reindirizzare il cliente al termine del processo di feedback post-pagamento a uno dei quattro URL inviati nei campi nascosti (ACCEPTURL, EXCEPTIONURL, CANCELURL e DECLINEURL descritti nel capitolo Reindirizzamento in base al risultato della transazione).

In alternativa, se nessuna delle opzioni sopra viene utilizzata come feedback al cliente, la pagina di post-pagamento può rispondere con qualche riga di testo (senza tag <html>) che includiamo nella risposta standard, oppure il sistema mostra semplicemente la risposta standard (come descritto nel capitolo Reazione predefinita).

Il seguente schema mostra il processo al termine della transazione qualora il pagamento venga autorizzato o accettato con una richiesta di post-pagamento online. (Se il pagamento viene annullato, rifiutato o è incerto, il processo è simile ma vengono utilizzate le pagine "CANCELURL", "DECLINEURL", "EXCEPTIONURL" e di "annullamento/rifiuto").

7.4.4 Richiesta HTTP di cambiamenti di stato

Qualora lo stato della transazione cambi, è possibile anche ricevere una richiesta HTTP. A tal fine, è necessario immettere un URL nel campo "Richiesta HTTP di cambiamenti di statuto" della scheda "Ritorno d'informazione..." della pagina Informazione tecniche (e selezionare il momento in cui inviare la richiesta).

Questo processo è simile al feedback post-pagamento, con la differenza che è rilevante soltanto per i potenziali processi in background.

È possibile utilizzare lo stesso URL impostato nella sezione Richiesta HTTP diretta da server a server.

Nota: non è possibile utilizzare l'URL del cambiamento di stato per generare una risposta personale al cliente.

7.5 Parametri di feedback

Quando viene eseguita una transazione, possiamo inviare il seguente elenco di parametri agli URL di reindirizzamento e/o agli URL di feedback post-pagamento.

Campo Descrizione
ACCEPTANCE Il codice di accettazione restituito dall'acquirente
AMOUNT
Quantità dell'ordine (non moltiplicata per 100)
BRAND
Marca della carta (il nostro sistema lo ricava dal numero di carta)
CARDNO
Numero della carta mascherato
CN
Nome titolare della carta/cliente
CURRENCY
Valuta dell'ordine
ED
Data di scadenza
NCERROR
Codice di errore
ORDERID
Riferimento dell'ordine
PAYID
Riferimento del pagamento nel nostro sistema
PM
Metodo di pagamento
SHASIGN
Firma SHA calcolata dal nostro sistema (se SHA-OUT è configurato)
STATUS
Stato della transazione (v. Panoramica di stato)
TRXDATE
Data della transazione

Esempio (richiesta GET)

http://www.yourwebsite.com/acceptpage.asp?orderID=ref12345&currency=EUR&amount=25&PM=CreditCard&ACCEPTANCE=test123&STATUS=5&CARDNO=XXXXXXXXXXXX1111&PAYID=1136745&NCERROR=0&BRAND=VISA&ED=0514&TRXDATE=12/25/08&CN=John Doe

L'elenco dei parametri di feedback può allungarsi se si attivano alcune opzioni nell'account, ad esempio il modulo di rilevamento delle frodi. Per maggiori informazioni sui parametri di feedback aggiuntivi collegati a quest'opzione, consultare la relativa documentazione.

7.5.1 Parametri di feedback dinamici

È anche possibile scegliere quali parametri restituire.

A tale scopo, accedere alla scheda "Ritorno d'informazione..." nella pagina Informazione tecniche, dove è presente un elenco di campi "Disponibile" e "Selezionato". Solo i campi "Selezionato" verranno inclusi nella richiesta di feedback.

Per aggiungere o rimuovere parametri dalla richiesta di feedback, è sufficiente fare clic sul nome del parametro, poi sulla freccia corrispondente, per aggiungerlo/rimuoverlo dall'elenco.

Se si aggiungono o rimuovono parametri dall'elenco, non dimenticare di aggiornare la firma SHA-OUT di conseguenza. I parametri che non vengono selezionati qui NON saranno inclusi nel calcolo SHA-OUT.

7.5.2 Parametri di feedback variabili

È possibile inviarci due parametri aggiuntivi nei campi nascosti del modulo dell'ordine per recuperarli come parametri di feedback dopo la transazione. Sono disponibili i seguenti campi nascosti:

<input type="hidden" name="COMPLUS" value="">
<input type="hidden" name="PARAMPLUS" value="">

Campo
Descrizione
COMPLUS
Campo per l'invio di un valore che si desidera che venga restituito nella richiesta di feedback.
PARAMPLUS

Campo per l'invio di parametri e dei rispettivi valori che si desidera che vengano restituiti nella richiesta di feedback.

Il campo PARAMPLUS non è incluso nei parametri di feedback in quanto tale; invece, i parametri/valori trasmessi in questo campo vengono analizzati e i parametri ottenuti vengono aggiunti alla richiesta http.


Esempio

Ulteriori campi nascosti inviati:

<input type="hidden" name="COMPLUS" value="123456789123456789123456789">
<input type="hidden" name="PARAMPLUS" value="SessionID=126548354&ShopperID=73541312">

Provocano il reindirizzamento con i parametri del feedback:

https://www.yourwebsite.com/acceptpage.asp?[…standard.parameters…]
&COMPLUS=123456789123456789123456789&SessionID=126548354&ShopperID=73541312 

7.6 Reinizializzazione del feedback

Qualora una richiesta di reindirizzamento/feedback non sia stata eseguita a causa di un'azione bloccante da parte del cliente sulle nostre pagine di pagamento sicuro (ad esempio facendo clic sul pulsante indietro nel browser), possiamo reinizializzare la richiesta di post-pagamento e/o il reindirizzamento in modo che il cliente venga reindirizzato alla pagina da visualizzare e i database possano essere aggiornati.

Per attivare questa funzione nell'account, selezionare Configurazione > Informazione tecniche > Ritorno d'informazione... > General e selezionare la casella "Voglio Ingenico ePayments rilanciare il "fine di transazione", (richiesta/ridirezione post-pagamento) trattamento se richiesto.".

Tuttavia, è possibile che si ricevano più richieste di post-pagamento per lo stesso ID ordine, poiché la richiesta di reindirizzamento/feedback sarà reinviata se il cliente torna alle nostre pagine di pagamento sicuro utilizzando il pulsante indietro dopo essere stato reindirizzato al sito Web.

Controllare che lo script Post URL sia stato configurato per gestire queste "eccezioni". Ad esempio, è possibile configurare lo script Post URL per creare una riga nel database per ogni stato di transazione ripubblicato e/o generare un'e-mail per informare il commerciante di un'"eccezione" alle operazioni "previste" nella procedura della transazione.

Si consiglia di non sovrascrivere il primo messaggio di stato della transazione ricevuto con qualsiasi messaggio successivo ricevuto per lo stesso ID ordine; l'azione migliore è archiviare tutte le risposte per qualsiasi ordine e richiamare un processo per poterle controllare e gestire correttamente.

Se non si abilita questa funzione, quando un cliente fa clic sul pulsante indietro per tornare alle pagine di pagamento sicuro, visualizzerà un messaggio che indica che il pagamento è già stato elaborato.

7.7 Email di conferma

7.7.1 Email al venditore

Il nostro sistema può inviare un'email di conferma del pagamento per ogni transazione. È possibile configurarla nella sezione "E-mails del commerciante" (email al venditore) della scheda "E-mails della transazione" della pagina Informazione tecniche.

Nella stessa sezione, è possibile scegliere di ricevere email per essere avvisati circa variazioni di stato della transazione.

7.7.2 Email al cliente

Il nostro sistema può inviare automaticamente un'email al cliente per avvisarlo della registrazione della transazione. Si tratta di un'email standard il cui contenuto non può essere modificato. L'indirizzo del mittente (“Da”) usato per inviare l'email è l'indirizzo immesso nel campo “Indirizzo(i) E-mail per le E-mail relative alle transazioni”. Se gli indirizzi email immessi in questo campo sono più di uno, viene usato soltanto il primo nella riga.

È possibile attivare quest'opzione nella scheda "E-mails della transazione" della sezione "E-mail al cliente" della pagina Informazione tecniche.

È anche possibile scegliere di inviare e-mail al cliente al momento della conferma della transazione (acquisizione dati) e del rimborso della transazione, selezionando le caselle corrispondenti. Come indirizzo e-mail del mittente ("Da") per queste e-mail, è possibile configurare "Indirizzo email dell'assistenza da includere nelle email relative alle transazioni". Se non si immette nessun indirizzo e-mail qui, verrà utilizzato il primo indirizzo immesso in "Indirizzo email dell'assistenza da includere nelle email relative alle transazioni" nella sezione "E-mails del commerciante".

Per poter inviare email di conferma ai clienti, occorre includere l'indirizzo email del cliente nel campo nascosto:

<input type="hidden" name="EMAIL" value="">

Campo
Descrizione
EMAIL Indirizzo email del cliente

8. Collegamento al pagamento tramite email

È possibile inviare per email una richiesta di pagamento ai clienti che rimandi il cliente alla nostra pagina di pagamento sicuro tramite un pulsante o un collegamento nell'email.

Se l'email è in formato HTML, è possibile utilizzare un modulo con i campi HTML nascosti per inviarci i parametri necessari in formato POST.

Se l'email è in formato di testo semplice, è possibile aggiungere i parametri necessari all'URL in formato GET. (ad es. https://ogone.test.v-psp.com/ncol/test/orderstandard.asp / orderstandard_utf8.asp?PSPID=TESTSTD&OrderID=order123&amount=12500&currency=EUR&SHASIGN=8DDF4795640EB9FE9B367315C48E47338129A4F5& …)

Per maggiori informazioni leggere il capitolo Collegamento del sito Web alla pagina del pagamento.

Affinché e-Commerce funzioni tramite email, tenere presente i seguenti punti di controllo prima del pagamento:

  • Lasciare vuoti i campi referente/URL nel campo della scheda “Controllo dei dati e d'origine” nella sezione “Controlli per e-Commerce” della pagina Informazione tecniche dell'account, per evitare di visualizzare gli errori unknown order/1/r/ .
  • È necessario usare una firma SHA come metodo di verifica dei dati per i dettagli dell'ordine. Per maggiori informazioni relative a SHA-IN, consultare il capitolo Firma SHA-IN.

9. Opzioni di selezione del metodo di pagamento

9.1 Selezione del metodo di pagamento dal lato rivenditore

9.1.1 Come visualizzare un metodo di pagamento specifico

Quando un cliente viene reindirizzato dal sito Web/negozio del venditore alla nostra pagina di pagamento sicuro, gli vengono presentati i metodi di pagamento attivati nell'account Ingenico ePayments.

Se tuttavia si desidera che la selezione del metodo di pagamento avvenga sul proprio sito Web anziché sulla nostra pagina di pagamento, è possibile inviarci il nome e/o la marca del metodo di pagamento nei campi nascosti. In questo caso presentiamo questo particolare metodo di pagamento sulla nostra pagina di pagamento e il cliente può pagare soltanto con questo metodo.

Gli ulteriori campi nascosti inviati sono i seguenti:

<input type="hidden" name="PM" value="">
<input type="hidden" name="BRAND" value="">

Campo
Descrizione
PM
Metodo di pagamento o gruppo di metodi di pagamento (ad es. carta di credito)
BRAND
Marca del metodo di pagamento (ad es. VISA)

In base al metodo di pagamento, è necessario inviare entrambi i campi o un campo solo. In molti casi il valore nei campi PM e BRAND coincide: in questo caso, inviare soltanto PM o BRAND.

Esempi

  • Campi nascosti qualora si desideri che il cliente paghi con VISA:

<input type="hidden" name="PM" value="CreditCard ">
<input type="hidden" name="BRAND" value="VISA">

  • Campi nascosti qualora si desideri che il cliente paghi con carta di credito (non vengono visualizzati altri metodi di pagamento oltre le carte di credito):

<input type="hidden" name="PM" value="CreditCard ">
<input type="hidden" name="BRAND" value="">

  • Campi nascosti qualora si desideri che il cliente paghi con iDEAL:

<input type="hidden" name="PM" value="iDEAL">
<input type="hidden" name="BRAND" value="">

OPPURE

<input type="hidden" name="PM" value="">
<input type="hidden" name="BRAND" value="iDEAL">

9.1.2 Come tornare dalla pagina di pagamento alla schermata di selezione del metodo di pagamento

Se il cliente seleziona il metodo di pagamento sul sito Web, gli viene presentato soltanto il metodo di pagamento selezionato sulla pagina di pagamento.

Se il pagamento non viene effettuato con questo metodo di pagamento e il cliente vuole tentare di usare un altro metodo di pagamento, non gli viene presentato un elenco dei metodi di pagamento sulla pagina di pagamento sicuro dato che la scelta del metodo di pagamento è stata effettuata sul sito Web (e non sulla pagina di pagamento sicuro).

Pertanto, per reindirizzare il cliente a un URL sul proprio sito Web in cui possa selezionare un altro metodo di pagamento, è possibile utilizzare "BACKURL".

Con BACKURL, quando il cliente fa clic sul pulsante “Indietro” sulla pagina del pagamento sicuro, dopo il rifiuto dell'autorizzazione o l'annullamento ad opera di terzi o di un sito Web bancario il cliente viene reindirizzato all'URL immesso in “BACKURL”.

Nota: il pulsante "Indietro" descritto in questa sezione corrisponde al pulsante "Indietro" nelle nostre pagine di pagamento sicuro e NON al pulsante Indietro del browser.

È possibile immettere il “BACKURL” specificato nella scheda "Pagina dei pagamenti" della pagina “Informazione tecniche” dell'account.

Se tuttavia si preferisce evitare di usare sempre lo stesso URL, è possibile inviarci un “BACKURL” specifico nei campi nascosti. Il “BACKURL” inviato nei campi nascosti sostituisce il “BACKURL” generico immesso nell'account.

È possibile inviare il “BACKURL” nel seguente campo nascosto:
<input type="hidden" name="BACKURL" value="">

Campo
Utilizzo
BACKURL
URL della pagina Web che il cliente deve visualizzare quando seleziona il pulsante “Indietro” sulla nostra pagina di pagamento sicuro.

Se il cliente seleziona il metodo di pagamento nella pagina di pagamento sicuro e non nel sito Web, il “BACKURL” non viene preso in considerazione. Di conseguenza, quando il cliente fa clic sul pulsante “Indietro” sulla nostra pagina di pagamento sicuro, viene semplicemente reindirizzato alla pagina di scelta del metodo di pagamento sicuro.

9.2 Visualizzazione di uno specifico elenco di metodi di pagamento

Se il cliente deve selezionare il metodo di pagamento da uno specifico elenco di metodi di pagamento sulla pagina di pagamento, è possibile inviarci l'elenco dei metodi di pagamento nei campi nascosti in modo che il cliente visualizzi soltanto i metodi di pagamento specifici sulla pagina di pagamento.

Il campo nascosto è il seguente:

<input type="hidden" name="PMLIST" value="">

Campo
Descrizione
PMLIST
Elenco dei metodi di pagamento selezionati e/o delle marche di carte di credito. Separati da un “;” (punto e virgola).

Esempio

Se si desidera che il cliente scelga tra VISA e iDEAL nella pagina di pagamento (ad es. se ci sono anche altri metodi di pagamento che non si intende visualizzare), il campo nascosto e il suo valore saranno:

<input type="hidden" name="PMLIST" value="VISA;iDEAL">

9.3 Esclusione di metodi di pagamento specifici

Se non si desidera presentare al cliente uno specifico metodo di pagamento, è possibile usare un campo nascosto. Questa funzione è particolarmente utile per i marchi secondari quando si intende accettare un marchio (ad es. MasterCard) ma non uno dei suoi marchi secondari (ad es. Maestro).

Il campo nascosto è il seguente:

<input type="hidden" name="EXCLPMLIST" value="">

Campo
Descrizione
EXCLPMLIST
Elenco di metodi di pagamento e/o marche di carte di credito che NON devono essere mostrati. Separati da un “;” (punto e virgola).

9.4 Layout dei metodi di pagamento

È possibile disporre il layout/elenco dei metodi di pagamento sulla pagina di pagamento tramite il seguente campo nascosto:

<input type="hidden" name="PMLISTTYPE" value="">

Campo
Valori possibili
PMLISTTYPE
I valori possibili sono 0, 1 e 2:
  • 0: loghi raggruppati in orizzontale con il nome del gruppo a sinistra (valore predefinito)
  • 1: loghi raggruppati in orizzontale senza nomi di gruppo
  • 2: elenco verticale di loghi con un nome di marchio o un metodo di pagamento specifico

9.5 Window di 3-D Secure

9.5.1 3-D Secure v1.0

Se sono attivati i metodi di pagamento con 3-D Secure, è possibile scegliere come mostrare al cliente la pagina di identificazione inviandoci un parametro aggiuntivo nei campi nascosti.

Il campo nascosto è il seguente:

<input type="hidden" name="WIN3DS" value="">

Campo
Valori possibili
WIN3DS
  • “MAINW”: consente di visualizzare la pagina di identificazione nella finestra principale (valore predefinito);
  • “POPUP”: consente di visualizzare la pagina di identificazione nella finestra POPUP e alla fine di tornare alla finestra principale.

Importante

Per alcuni metodi di pagamento (ad es. Visa, MasterCard, JCB, ecc.), il valore ‘POPUP’ non è consentito e viene convertito in ‘MAINW’ dal sistema. Consigliamo di controllare il comportamento di questo campo per ogni metodo di pagamento. 

9.5.2 3-D Secure v2.1 (Disponibile in TEST)

Oltre ai parametri richiesti precedentemente (WIN3DS), si consiglia vivamente di includere il seguente parametro. Questo contiene le dimensioni preconfigurate di larghezza x altezza in pixel della finestra che compare nel browser del titolare di carta di credito.

NOTA: se non si invia questo parametro, il valore predefinito è 05 = Full screen.

Parametro
Valori possibili
Mpi.challengeWindowSize
  • 01 = 250 x 400
  • 02 = 390 x 400
  • 03 = 500 x 600
  • 04 = 600 x 400
  • 05 = Full screen
Per rendere più efficace l'approccio di 3DS v2 alla valutazione dei rischi, si consiglia di inviare i parametri aggiuntivi come descritto in questo elenco nella lista qui.
La fornitura di questi parametri può avere un impatto diretto sulla velocità di conversione, perché aiuta l’autenticazione del titolare della carta senza essere reindirizzati. Per ulteriori informazioni, far riferimento alla guida di DirectLink 3DS Version 2.

È possibile usare le seguenti carte di prova per simulare una carta registrata 3-D Secure nel nostro ambiente di prova:

Flusso senza attriti
Marchio Numero carta Data di scadenza
VISA 4186455175836497 Qualsiasi data futura
Mastercard
5137009801943438 Qualsiasi data futura
American Express
375418081197346 Qualsiasi data futura

Flusso difficile

Marchio Numero carta Data di scadenza
VISA 4874970686672022 Qualsiasi data futura
Mastercard
5130257474533310 Qualsiasi data futura
American Express
379764422997381 Qualsiasi data futura

Nota: è possibile scaricare più numeri di schede di prova qui.

9.6 Carte suddivise/carte di debito

La funzionalità di suddivisione di VISA e MasterCard in un metodo di pagamento di debito e di credito consente di offrire ai clienti due metodi di pagamento differenti (ad es. VISA Debit e VISA Credit), oppure è possibile decidere di accettare soltanto uno dei due marchi.

Per utilizzare la suddivisione di carte di credito e di debito tramite e-Commerce, è necessario includere il parametro CREDITDEBIT nei campi nascosti inviati nella pagina di pagamento (ed includerlo pertanto anche nel calcolo SHA-IN!).

Campo Formato
CREDITDEBIT "C": carta di credito
"D": carta di debito

Errore correlato: quando l'acquirente sceglie il metodo di carta di debito ma poi immette un numero di carta di credito, viene restituito il codice errore: ‘Wrong brand/Payment method was chosen’ (è stato scelto un marchio/metodo di pagamento sbagliato).

Se il pagamento viene elaborato correttamente con il parametro CREDITDEBIT, lo stesso parametro viene restituito nel feedback post-vendita. Tuttavia, mentre i valori trasmessi sono C o D, i valori restituiti sono "CREDIT" o "DEBIT".

Questi valori di restituzione sono riportati anche nella panoramica della transazione accessibile mediante "Visualizza le transazione" e "Storia Finanziaria" e nei report da scaricare successivamente.

Configurazione nell'account

La funzionalità suddivisa può essere attivata e configurata in base al metodo di pagamento nell'account Ingenico ePayments. Per maggiori informazioni, controllare la guida alle carte suddivise/carte di debito.

9.7 Elaborazione di transazioni con credenziali memorizzate

La transazione credential-on-file (COF) utilizza i dettagli della carta già salvati dai commercianti per elaborare il pagamento. Prima di avviare una transazione credential-on-file (COF), il titolare della carta di credito deve autorizzare il commerciante a memorizzarne i dettagli. La transazione credential-on-file (COF) viene utilizzata principalmente con i pagamenti ricorrenti e indica se il pagamento è stato avviato da un titolare di carta di credito o da un commerciante.

Esistono due tipi di transazione credential-on-file (COF): transazione avviata dal titolare di carta di credito (CIT) e transazione avviata dal commerciante (MIT). La transazione avviata dal titolare di carta di credito (CIT) dovrà sempre essere effettuata prima della transazione avviata dal commerciante (MIT).

Una transazione avviata dal titolare di carta di credito (CIT) è una transazione in cui il titolare della carta effettua e convalida personalmente la transazione, tramite firma, dispositivo 3D-Secure o documento d’identità.

Esempio di transazione avviata dal titolare di carta di credito (CIT):

Un titolare di carta di credito acquista un biglietto del treno online ed effettua il pagamento. Lui/lei effettua il pagamento con la propria carta e gli/le viene chiesto di autenticare e autorizzare il pagamento. Nello stesso momento, al titolare viene chiesto se desidera salvare i dettagli della carta di credito relativi al pagamento. Se il titolare acconsente, l’informazione può essere riutilizzata per transazioni future avviate dal commerciante.

Una transazione avviata dal commerciante (MIT) viene avviata da un commerciante successivamente a una transazione avviata dal titolare di carta di credito (CIT) e a un ordine permanente prestabilito di beni e servizi acquistati dal titolare della carta. Il titolare della carta di credito non è coinvolto nella transazione.

Esempio di transazione avviata dal commerciante (MIT):

Un commerciante può avviare automaticamente una transazione per il pagamento da parte del titolare della carta di un abbonamento mensile a una rivista.

In conformità ai regolamenti stabiliti da Visa e MasterCard per la transazione credential-on-file (COF), è necessario inviare nuovi parametri per determinare la transazione COF. 

Ne sono interessati coloro che:

  • utilizzano un alias.
  • prevedono di avviare transazioni ricorrenti (programmate o meno) dopo l’avvio di una transazione avviata dal titolare di carta di credito (CIT) per la prima volta.

Azione necessaria

Per impostazione predefinita, in una transazione online vengono utilizzati i seguenti parametri:

Valori dei parametri COF_INITIATOR-COF_TRANSACTION-COF_SCHEDULE

Descrizione

CIT-FIRST-UNSCHED
Quando viene creato o utilizzato un alias
CIT-FIRST-SCHED

Per il primo pagamento o abbonamento programmato

Se non si aggiungono parametri, i valori predefiniti vengono segnalati. Tuttavia, se si desidera modificarli, è possibile sovrascrivere questi valori predefiniti inviando i nuovi parametri. Occorre, inoltre, ricalcolare la firma digitale SHA (fai clic qui per maggiori informazioni sulla firma digitale SHA)

Parametri

Valori

Descrizione

COF_INITIATOR CIT Una transazione avviata dal titolare di carta di credito
  MIT Una transazione avviata dal commerciante
COF_SCHEDULE
SCHED Una transazione programmata
  UNSCHED Una transazione non programmata
COF_TRANSACTION
FIRST La prima di una serie di transazioni

SUBSEQ

Serie di transazioni successiva

COF_RECURRING_EXPIRY
Data YYYYMMDD (i.e. 20190914)
Data di fine: data dell'ultimo pagamento programmato di una serie
COF_RECURRING_FREQUENCY
numerico tra 2 e 4 cifre (i.e. 31, 031 or 0031)
Giorni tra i pagamenti per una serie programmata.

10. Campi facoltativi

10.1 Operazione

Importante

La possibilità di operare in due fasi (autorizzazione + acquisizione dei dati) dipende dai metodi di pagamento da utilizzare. (Vedere "Payment Methods Processing/Procedures" (Panoramica procedura/elaborazione metodi di pagamento) nella sezione di assistenza del proprio account.)

Se per una determinata transazione si preferisce evitare di utilizzare lo stesso codice operazione selezionato nella scheda "Parametri globali della transazione", nella sezione "Codice d'operazione predefinito" della pagina “Informazione tecniche” del proprio account, è possibile inviarci un codice operazione specifico per questa transazione.

Il codice operazione inviato nei campi nascosti sostituisce il codice operazione predefinito selezionato nella sezione "Codice d'operazione predefinito" della scheda "Parametri globali della transazione" nella pagina “Informazione tecniche” dell'account. È possibile inviare il codice operazione insieme al campo nascosto:

<input type="hidden" name="OPERATION" value="">   

Campo
Descrizione
OPERATION

Il codice operazione della transazione.

Valori possibili per i nuovi ordini:

  • RES: richiesta di autorizzazione
  • SAL: richiesta di vendita (pagamento)

Opzionale

  • PAU: richiesta di autorizzazione preliminare.

    In accordo con l’acquirente, potete usare questo codice operazione per bloccare temporaneamente i fondi sulla carta di un cliente.
    Qualora si cercasse di autorizzare in forma preliminare le transazioni mediante acquirenti o marche di carte di credito che non supportano l’autorizzazione preliminare, tali transazioni non saranno bloccate, bensì verranno elaborate come normali autorizzazioni (=RES).
    Non è possibile impostare come predefinita l’autorizzazione preliminare nell’account
Affinché questo parametro venga preso in considerazione dal sistema, deve essere incluso nel calcolo Firma SHA-IN per la transazione.

10.2 Campo utente

Se sono presenti diversi utenti nell'account e si desidera registrare le transazioni associate a uno specifico utente (ad es. per gli operatori dei call center che registrano le transazioni tramite e-Commerce), è possibile inviare l'USERID nel seguente campo nascosto:

<input type="hidden" name="USERID" value="">

Campo Descrizione
USERID
Nome utente specificato nella pagina di gestione dell'account

Questo campo serve unicamente a scopo informativo per aggiungere un USERID a una transazione specifica. Noi da parte nostra non eseguiamo controlli per verificare se ci siano errori di password per l'utente. L'unico controllo che eseguiamo è la verifica della validità di USERID. Se il codice USERID non esiste, lo sostituiamo con l'USERID predefinito dell'account (PSPID).

Ingenico ePayments è un provider mondiale di servizi di pagamento digitale, Ingenico Payment Services fornisce una risposta efficace alla complessità di pagamenti qualunque sia il canale: in rete, con il cellulare o in un negozio. Procura soluzioni innovative per il commercio in rete, per quanto riguardano l’aspetto finanziario, l’aspetto commerciale e la complessità dei canali, sostiene i commercianti a gestire, incassare e proteggere i propri pagamenti, prevenendo le frodi ed aumentando le entrate attraverso conversioni più elevate. Ingenico ePayments fa parte del gruppo Ingenico, leader mondiale nel settore di pagamenti in rete.

Questo sito web utilizza i cookie per essere in grado di darvi la migliore esperienza utente. Se non si desidera accettare i cookie, è possibile modificare le impostazioni dei cookie. Cliccate su 'Accetta' per consentire tutti i cookie di questo sito.

Impostazioni dei cookie

Introduzione

Funzionale

I cookies funzionali sono necessari per il funzionamento corretto del sito web. Non è possibile disattivare questi cookie.

Ottimizzato

I cookies per l’ottimizzazione ci permettono di analizzare l'utilizzo del sito in modo che possiamo monitorare e migliorare il nostro sito.
Questo è il livello predefinito.

Personalizzata

Cookies di personalizzazione vengono utilizzati per i social media e per personalizzazione avanzata, permettendoci di mostrarvi le informazioni collegate alla vostra azienda.


Esempio delle funzionalità consentite

  • Salvare le preferenze riguardanti il paese
  • Salvare le preferenze riguardanti la lingua

Esempio delle funzionalità non consentite

  • Salvataggio dei dati personali
  • Tracciamento per scopi di remarketing
  • Tracciamento anonimo tramite Google Analytics

Esempio delle funzionalità consentite

  • Salvare le preferenze riguardanti il paese
  • Salvare le preferenze riguardanti la lingua
  • Tracciamento anonimo tramite Google Analytics
  • Tracciamento per scopi di remarketing

Esempio delle funzionalità non consentite

  • Salvataggio dei dati personali
  • Tracciamento per scopi di remarketing

Esempio delle funzionalità consentite

  • Salvare le preferenze riguardanti il paese
  • Salvare le preferenze riguardanti la lingua
  • Tracciamento anonimo tramite Google Analytics
  • Mostrare contenuto in linea con i vostri interessi
  • Mostrare pubblicità in linea con i vostri interessi
  • Tracciamento per scopi di remarketing

Esempio delle funzionalità non consentite

  • Salvataggio dei dati personali