1. Home
2. Soluzioni di integrazione
3. Integrazioni
4. PostFinance e-Commerce

1. Introduzione

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

PostFinance e-Commerce consente di:

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

2. Pagina Informazione tecniche

Nell'account PostFinance è 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.

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.

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.

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://e-payment.postfinance.ch/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. Il parametro ORDERID viene utilizzato per verificare se le richieste vengono inviate per errore due volte alla nostra piattaforma Se due transazioni con lo stesso valore per ORDERID vengono inviate in un periodo di tempo di 45 giorni, bloccheremo la seconda transazione. Questo controllo si applica solo se il parametro PAYIDSUB della prima transazione ha raggiunto uno dei seguenti stati: 2 5 9 Di conseguenza, è possibile utilizzare un parametro ORDERID solo una volta ogni 45 giorni. Dopo tale periodo di tempo, è possibile utilizzare nuovamente il parametro ORDERIDs già inviato.
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. Se fate una richiesta 3DSV2.1, assicuratevi che il formato « e-mail » sia valido. In caso contrario, l’autenticazione cliente avanzata utilizzerà il protocollo 3DSV1.0.
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

4.3 Nous enverrons le PAYID en tant que communication structurée à la place

Per i metodi di pagamento KBC/CBC Online, ING Homepay e Belfius DirectNet è possibile includere una comunicazione strutturata (Gestructureerde mededeling) in base allo standard OGM-VCS nei tuoi report di pagamento dei servizi di acquiring.

Questa comunicazione strutturata può essere visualizzata nel nostro back office per singole transazioni da Operazioni > Visualizza le transazioni.

o è disponibile come parametro STRUCT tramite il nostro strumento di reportistica elettronica (Reporting).

Per il suo utilizzo, è necessario inviare il valore del parametro ORDERID contenente solo cifre.
A seconda della lunghezza di ORDERID, alla comunicazione strutturata verrà applicato il seguente contenuto:

Lunghezza di ORDERID	>12	12 (inclusa la somma di controllo Modulo 97)	11	10 (esclusa la somma di controllo Modulo 97)	Tra 1 e 9
Risultato	Per la comunicazione strutturata saranno utilizzati PAYID + due caratteri di controllo (come Modulo 97)	Per la comunicazione strutturata sarà utilizzato ORDERID Il risultato è lo stesso se questo valore è inviato con il parametro COM	Per la comunicazione strutturata saranno utilizzati PAYID + due caratteri di controllo (come Modulo 97)	Il nostro sistema aggiungerà ORDERID + due caratteri di controllo (come Modulo 97)	Per la comunicazione strutturata saranno utilizzati ORDERID + zeri a sinistra + due caratteri di controllo (come Modulo 97) A seconda della lunghezza di ORDERID, il numero di zeri a sinistra varierà per avere una lunghezza totale di 12 cifre

Stabilisci, insieme al tuo acquirente, di stampare la comunicazione strutturata nei tuoi report di pagamento, tenendo conto che ciò potrebbe implicare una modifica del tuo contratto di acquiring.

IMPORTANTE: Lo standard OMG-VCS non è disponibile tramite Full Service Questo servizio non è disponibile per questi metodi di pagamento se offerto tramite Full Service Invieremo, invece, il PAYID come forma di comunicazione strutturata

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), PostFinance 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.

Sebbene supportiamo i metodi hash SHA-1 / SHA-256 / SHA-512, consigliamo di utilizzare SHA-256 o SHA-512. Questi metodi forniscono la massima sicurezza per il processo di verifica.

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 PostFinance, 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.

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.

• 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: PostFinance 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 PostFinance

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 PostFinance dal back office di PostFinance, 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 PostFinance 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 5.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.

IMPORTANTE:

• Il nostro modello della pagina di pagamento responsiva richiede che i metodi di pagamento vengano visualizzati in ordine verticale. Inviare il parametro aggiuntivo PMLISTTYPE=2 per effettuare ciascuna transazione.
• 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>).
• Ti consigliamo di limitare le dimensioni dei loghi a 300 px in larghezza e in altezza. In questo modo, il tempo di caricamento su dispositivi mobili sarà minimo.

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 5.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 PostFinance.

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 , è necessario ospitare il modello (e i rispettivi file) in un ambiente con la certificazione PCI più elevata.

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.

Rivolgersi al nostro team Assistenza clienti, Tel. +41 (0)848 38 24 23, E-Mail: merchanthelp@postfinance.chper modificare il timeout (HTTPTimeOut).

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 PostFinance 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 Assistenza clienti 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://e-payment.postfinance.ch/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 PostFinance .

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
• Dettagli del pagamento
• Piè di pagina
• Sezione relativa allo stato del pagamento

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://e-payment.postfinance.ch/ncol/StandardMobileTemplate.htm

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

https://e-payment.postfinance.ch/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 PostFinance, quindi aprire "Configurazione" > "Modello" > "File Manager".

Importante Non è possibile usare simultaneamente i file precedentemente caricati da PostFinance e i file caricati con File Manager nella propria integrazione. Quindi, se sono presenti file caricati da PostFinance 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 Default merchant template

6.5.4 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 PostFinance 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, iDEAL e PayPal) usano il reindirizzamento, compromettendo il layout e/o causando problemi di navigazione.

Di conseguenza, PostFinance non consiglia IFrame, il cui eventuale utilizzo è di responsabilità dell'utente. PostFinance 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 PostFinance selezionare "Configurazione" > "Informazione tecniche" > "Ritorno d'informazione della transazione". Configurare le impostazioni come descritto di seguito: Reindirizzamento HTTP nel browser: Richiesta HTTP diretta da server a server: sempre differita:

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 PostFinance, 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 PostFinance: 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 PostFinance 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 PostFinance): 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. Non selezionare quest'opzione se si è obbligati a ricevere richieste di post-vendita (vedere il feedback sulla transazione al cliente e al venditore).

• 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 PostFinance 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. Se fate una richiesta 3DSV2.1, assicuratevi che il formato « e-mail » sia valido. In caso contrario, l’autenticazione cliente avanzata utilizzerà il protocollo 3DSV1.0.

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://e-payment.postfinance.ch/ncol/test/orderstandard.asp / orderstandard_utf8.asp?PSPID=TESTSTD&OrderID=order123&amount=12500¤cy=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: Se hai scelto di implementare questa funzione in una chiamata GET, assicurati che non vengano trasmessi dati personali del tuo cliente, come un'e-mail o un numero di telefono 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 PostFinance.

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 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 PostFinance. Per maggiori informazioni, controllare la guida alle carte suddivise/carte di debito.

9.6 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)	Attualmente è disponibile solo nell’ambiente di test 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)	Attualmente è disponibile solo nell’ambiente di test Giorni tra i pagamenti per una serie programmata.

* Assicurati di inviare i valori dei parametri secondo il formato definito nella tabella. Altrimenti la transazione verrà bloccata dal nostro sistema.

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 saranno bloccate, bensì verranno elaborate come normali autorizzazioni (=RES). Non è possibile impostare come predefinita l’autorizzazione preliminare nell’account PostFinance.

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).

11. Pagamento sicuro con 3-D Secure

Il servizio 3-D Secure (3DS) è una parte importante del flusso di elaborazione delle transazioni per il cliente. Non devi eseguire alcuna operazione particolare, è necessario solo che 3DS sia attivo su tutti i metodi di pagamento con carta. Penseremo noi a tutto il resto.

In seguito all’introduzione di 3DSv2, si applicano nuove regole. Sebbene raccogliamo tutti i dati rilevanti per te durante il processo di pagamento, puoi comunque rendere più efficace l’approccio di 3DSv2 alla valutazione del rischio. Puoi farlo inviando parametri aggiuntivi (consigliati / opzionali) insieme alla transazione.

PSD2 migliora la trasparenza del processo di pagamento per te e per i tuoi clienti. Ciò risulta particolarmente utile nel caso di transazioni con stato 2.
Il nostro parametro di feedback CH_AUTHENTICATION_INFO ti fornisce informazioni dettagliate dagli emittenti quando rifiutano le transazioni dei tuoi clienti.
Condividi queste informazioni con i tuoi clienti per aiutarli a capire il motivo per cui la loro banca ha rifiutato la transazione.

Per ricevere CH_AUTHENTICATION_INFO nei tuoi URL di reindirizzamento, seleziona questo parametro nel Back Office tramite Configurazione >Informazione tecniche > Ritorno d’informazione della transazione > Parametri e-Commerce dinamici. Ciò garantirà inoltre che queste informazioni siano visibili nella panoramica della transazione in Operazioni > Visualizza le transazioni / Storia Finanziaria.
Poiché non riceverai le informazioni in tempo per modificare i tuoi URL di reindirizzamento una volta finalizzata una transazione, ti consigliamo di contrassegnare "Voglio PostFinance mostrare un testo corto al cliente sulla pagina di pagamento se una ridirezione al mio sito web è individuata appena dopo il processo di pagamento." nel Back Office da Configurazione >Informazione tecniche > Ritorno d’informazione della transazione > eCommerce > Ridirezione HTTP nel navigatore. La nostra piattaforma reindirizzerà quindi i tuoi clienti alla nostra pagina dei risultati intermedi che mostra le informazioni prima che i tuoi clienti finiscano sui tuoi URL di reindirizzamento.

11.1 Esclusioni dalla regola 3DSv2

Alcune transazioni sono escluse dalla SCA. Se una delle tue transazioni è tra queste, non verrà effettuata l’implementazione di 3-D Secure. Per ulteriori informazioni sul tipo di transazioni specifiche, consulta la nostra guida dedicata qui. 

Puoi richiedere di omettere 3-D Secure in due modi

1. Autenticazione selezionando i parametri Mpi.threeDSRequestorChallengeIndicator e 3DS_EXEMPTION_INDICATOR
   

   Campo	Valore
   Mpi.threeDSRequestorChallengeIndicator	Lunghezza: 2 caratteri Tipo di dati: stringa Valori accettati: 01 = Nessuna preferenza; 02 = Nessuna verifica richiesta - Utilizza questo valore per transazioni di importo ridotto (inferiore a 30 euro); 03 = Verifica richiesta - Preferenza del commerciante; 04 = Verifica richiesta - Autorizzazione - Utilizza questo valore quando configuri una transazione ricorrente con il cliente o quando riprovi a effettuare la transazione in seguito a un Soft Decline; 05 = Nessuna verifica richiesta - Analisi del rischio transazionale già eseguita - Utilizza questo valore se hai concordato con l’acquirente le esenzioni TRA; 07 = Nessuna verifica richiesta - SCA già eseguita - Utilizza questo valore quando esegui la SCA, deve essere approvata dall’acquirente
   3DS_EXEMPTION_INDICATOR	Lunghezza: 2 caratteri Tipo di dati: stringa Valori accettati: 03 = TRA* emittente 04 = esenzione per bassi importi 05 = TRA* Commerciante / Acquirente 06 = Whitelisting 07 = Corporate 08 = Spedizione ritardata 09 = Autenticazione ritardata (portafoglio certificato) * Transaction risk analysis

   Controlla il registro di autenticazione el Back Office e cerca "TransStatus = I" per scoprire se la banca emittente della carta ha concesso l’esenzione. Tuttavia, perderai il trasferimento della responsabilità in caso di transazione fraudolenta.

2. Autorizzazione selezionando i parametri 3DS_EXEMPTION_INDICATOR and FLAG3D appropriati
   Per saltare del tutto 3-D secure, inviare i seguenti parametri:
   
   

   Campo	Valore
   FLAG3D	N = Salto del processo di autenticazione 3DS
   3DS_EXEMPTION_INDICATOR	Lunghezza: 2 caratteri Tipo di dati: stringa Valori accettati: 03 = TRA* emittente 04 = esenzione per bassi importi 05 = TRA* Commerciante / Acquirente 06 = Whitelisting 07 = Corporate 08 = Spedizione ritardata 09 = Autenticazione ritardata (portafoglio certificato) * Transaction risk analysis

   
   Tuttavia, spetta ancora alla banca emittente della carta l’eventuale processo di autenticazione. Nel caso in cui la banca emittente della carta insista su 3DS, la transazione verrà rifiutata con il codice di errore 40001139. .
   Se la transazione viene accettata senza 3-D Secure, perderai la protezione contro le frodi.
   
   
   Quando i tuoi clienti configurano un nuovo pagamento ricorrente con te, secondo le regole PSD2, la prima transazione deve sempre essere sottoposta all’autenticazione forte. Invia tutti i parametri 3DS rilevanti, i parametri COF insieme a Mpi.threeDSRequestorChallengeIndicator=04. Ciò assicurerà che la banca emittente della carta sia a conoscenza di questa richiesta e approvi la transazione

Flusso privo di attriti / Flusso difficile

Se non desideri richiedere un’esenzione, ma fare affidamento sulle banche emittenti delle carte che implementano un flusso privo di attriti e mantengono la protezione contro le frodi, invia alcuni parametri aggiuntivi.
L’invio di questi parametri per questi schemi aumenta la possibilità di un flusso privo di attrito:

• Carte Bancaire (se fai parte di un programma per commercianti a basso rischio, sono fortemente richieste)
  

  ECOM_BILLTO_POSTAL_CITY
  ECOM_BILLTO_POSTAL_COUNTRYCODE
  ECOM_BILLTO_POSTAL_STREET_LINE1
  ECOM_BILLTO_POSTAL_POSTALCODE
  EMAIL
  OWNERTELNO
  ADDMATCH
  REMOTE_ADDR

• MasterCard
  ECOM_BILLTO_POSTAL_CITY
  ECOM_BILLTO_POSTAL_COUNTRYCODE
  ECOM_BILLTO_POSTAL_STREET_LINE1
  ECOM_BILLTO_POSTAL_POSTALCODE
  EMAIL
  OWNERTELNO
  Mpi.shippingIndicator
  REMOTE_ADDR

Puoi persino aumentare le possibilità di un flusso senza attriti e un tasso di conversione più elevato inviando più parametri opzionali.

Soft Decline

A typical flow of a soft declined transaction looks like this:

1. In your first request, send FLAG3D=N together with the appropriate value for 3DS_EXEMPTION_INDICATOR and no further authentication parameter. This way you indicate that you wish to skip 3-D Secure. The transaction might be accepted already now.
   If it is rejected by your customer’s bank because it insists on 3-D Secure, we will indicate this in the feedback parameter by sending NCERROR=40001139. The transaction will be put in status 2.
2. To recover this declined transaction, resubmit the transaction by sending the following parameters to our platform
   
   1. The standard request for e-Commerce / DirectLink parameters as sent in your first request as a new order
   2. FLAG3D=Y to indicate 3-D Secure needs to be rolled out
   3. The 3DSv2 authentication parameters as described here
   4. Mpi.threeDSRequestorChallengeIndicator=04 to indicate that your customer’s bank insists on 3-D Secure following the Soft Decline

Your customer will have to pass the 3-D Secure authentication during this second request. Finally, the transaction will reach either status 2 or 9. This depends on both whether your customer passed the authentication and the payment is accepted by both your and your customer’s bank.

Soft Decline is currently available for payment methods Visa, MasterCard, American Express and Carte Bancaire.

11.2 Test cards

You can use the following test card to simulate a 3-D Secure registered card in our test environment:

Frictionless Flow
Brand	Card number	Expiry date
VISA	4186455175836497	Any date in the future
Mastercard	5137009801943438	Any date in the future
American Express	375418081197346	Any date in the future
Carte Bancaire	4150557357382737	Any date in the future

Challenge Flow
Brand	Card number	Expiry date
VISA	4874970686672022	Any date in the future
Mastercard	5130257474533310	Any date in the future
American Express	379764422997381	Any date in the future
Carte Bancaire	4150550997933993	Any date in the future

More test cards numbers can be downloaded here.