POS - Banca Marche

Transcript

POS - Banca Marche

Pos Virtuale per
Pagamenti con Carte di
Credito
Descrizione del servizio
rel. 1.2.2
CLAUSOLA DI RISERVATEZZA
Il Cliente si impegna a mantenere la più assoluta riservatezza in merito alle
informazioni relative al servizio in oggetto e contenuti nel presente documento. Più
in generale, il Cliente si impegna a mantenere la più assoluta riservatezza in merito
a tutta la documentazione tecnica inviata da SIA e, pertanto, a non divulgare,
copiare o cedere a terzi la documentazione stessa, dichiarandosi responsabile, a tale
proposito, anche del comportamento del personale dipendente e non dipendente
che esso stesso metterà a conoscenza della suddetta documentazione. L'obbligo di
riservatezza dovrà essere mantenuto anche successivamente alla scadenza del
periodo in cui i servizi oggetto del presente documento saranno erogati, salvo
espressa autorizzazione scritta in merito da parte di SIA, o delle entità proprietarie
della documentazione medesima, ovvero salvo quando, in base alle vigenti leggi, le
informazioni divengano legittimamente di dominio pubblico.
@POS – Descrizione del servizio
rel. 1.2.2
pag. 2 di 30
Indice dei Contenuti
1.
2.
3.
4.
5.
Descrizione del Servizio................................................................................... 4
1.1
Premessa .................................................................................................. 4
1.2
Attori ........................................................................................................ 5
1.3
Strumenti di Pagamento........................................................................... 6
1.4
Protocolli di Sicurezza .............................................................................. 6
1.5
Caratteristiche del Servizio....................................................................... 7
1.6
Documentazione del Servizio ................................................................... 8
Architettura del Servizio .................................................................................. 9
2.1
Modalità MO/TO con Inserimento Manuale .............................................. 9
2.2
Modalità server-to-server con integrazione Merchant System .............. 10
2.3
Modalità Redirect con Transazione SSL .................................................. 11
2.4
Modalità Redirect con Transazione Verified by VISA/SecureCode ......... 12
2.5
Modalità Server-to-server Verified by VISA/SecureCode ...................... 13
Operatività del Servizio ................................................................................. 15
3.1
Attività del compratore e del venditore .................................................. 15
3.2
Adempimenti in fase di adesione ............................................................ 16
3.3
Acquisto e Pagamento ............................................................................ 16
3.4
Modalità operative scelte dal venditore ................................................. 17
3.5
Attività di SIA ......................................................................................... 18
Back-Office .................................................................................................... 19
4.1
Esercizio e Negozi ................................................................................... 19
4.2
Amministratore e Operatori.................................................................... 20
4.3
Funzionalità di Supporto ........................................................................ 22
4.4
Funzionalità di gestione degli ordini....................................................... 22
4.5
Ricerche.................................................................................................. 27
4.6
API di Back-Office .................................................................................. 28
Livelli di Servizio............................................................................................ 29
rel. 1.2.2
pag. 3 di 30
1.
Descrizione del Servizio
1.1 Premessa
@POS è un’applicazione di POS virtuale che permette di accettare e gestire in modo facile e
sicuro i pagamenti effettuati su Internet e, più in generale, su reti aperte.
Frutto di un’attività decennale nel mondo dei sistemi di pagamento innovativi, @POS è stato
progettato per offrire differenti esperienze di pagamento multicanale in grado di soddisfare
tutte le esigenze delle aziende e dei loro clienti finali.
La soluzione gestisce le principali carte di pagamento operanti in Italia e all’estero (VISA,
MasterCard, American Express, Diners e JCB) e, grazie alla componente @POS_payRID(1),
consente la gestione dei pagamenti tramite l’addebito sul conto corrente dell’acquirente.
Il servizio è in grado di accettare pagamenti:
•
di tipo MO/TO (Mail Order/Telephone Order), tramite API XML e connessione server to
•
•
•
•
in modalità redirect, utilizzando lo standard SSL;
in modalità redirect, secondo i protocolli Verified by Visa e SecureCode di MasterCard;
in modalità server to server secondo i protocolli Verified by Visa e SecureCode;
con inserimento manuale da parte del merchant direttamente dal back-office di @POS
(MO/TO).
server;
In caso di transazioni MO/TO l’esercente deve integrare sui propri sistemi la fase di raccolta dei
dati relativi alle carte di credito che vengono trasmesse al servizio @POS per il rilascio
dell’autorizzazione.
In alternativa, il servizio è in grado di accettare pagamenti in modalità redirect, veicolando il
compratore direttamente su @POS. In questo caso, i dati dello strumento di pagamento non
transitano sul portale del merchant ma vengono inseriti direttamente sul server sicuro di SIA.
Gli esercenti che dispongono di un sistema pregresso di vendite per corrispondenza (es. Call
Center) con la raccolta degli ordini completi degli estremi di pagamento, possono utilizzare
direttamente l’interfaccia grafica del back-office per inoltrare la richiesta di pagamento e
ottenere il rilascio dell’autorizzazione.
1 La soluzione @POS_payRID è una componente separata rispetto al servizio che gestisce le carte di
pagamento e viene descritta con apposita documentazione.
rel. 1.2.2
pag. 4 di 30
1.2 Attori
1.2.1 VENDITORE
Il venditore/esercente è l'organizzazione commerciale che effettua la vendita di beni o servizi su
Internet.
1.2.2 SIA
E' l'entità che, in relazione alle singole esigenze delle Banche e dei loro clienti (Internet Service
Provider, imprese, professionisti, privati) gestisce l’infrastruttura di sicurezza del sistema e
svolge il ruolo di gateway verso i circuiti autorizzativi.
1.2.3 BANCA DEL VENDITORE
E' la Banca presso la quale il venditore intrattiene il rapporto di conto corrente da accreditare a
fronte delle vendite.
1.2.4 ACQUIRER
E’ l’istituzione finanziaria che detiene il rapporto contrattuale con l’esercente al fine di consentire
l'accettazione delle carte di pagamento appartenenti ad un determinato circuito.
1.2.5 ISSUER
E’ l’istituzione finanziaria che detiene il rapporto contrattuale con il titolare della carta, ne cura il
processo di emissione e di autorizzazione al pagamento.
rel. 1.2.2
pag. 5 di 30
1.3 Strumenti di Pagamento
Il servizio @POS permette di accettare diverse tipologie di carte di credito in associazione con
gli standard e i protocolli di sicurezza previsti da parte dei circuiti di pagamento.
Di seguito vengono riportate le principali carte gestite abbinate alle modalità di utilizzo del
servizio :
VISA
Verified by
VISA
Master
Card
Diners
Amex
JCB
Aura
Secure
Code
SSL
MO/TO
Il servizio prevede inoltre la trasmissione delle informazioni legate al CVV2 e CVC2(2) nel caso in
cui la loro gestione venisse richiesta da parte dei circuiti di pagamento.
1.4
Protocolli di Sicurezza
Nell’ambito di @POS viene garantita la riservatezza con crittografia basata sullo standard SSL
con chiave simmetrica a 128 bit.
2 Questi codici costituiscono un’ulteriore misura di sicurezza nelle transazioni online con carta di credito e
consentono all’istituto che ha emesso la carta, di verificare l’identità del titolare, prevenendo possibili
frodi. I codici di sicurezza CVV (Card Verification Number) e CVC (Cardholder Verification Code) sono
solitamente presenti sul retro della carta.
rel. 1.2.2
pag. 6 di 30
1.5 Caratteristiche del Servizio
@POS consente di soddisfare ogni esigenza espressa da parte del merchant. Di seguito viene
fornita una sintesi delle principali caratteristiche e funzionalità di base disponibili nell’ambito del
servizio.
Modalità di utilizzo del POS Virtuale
SSL (re-direzione compratore su server sicuro SIA)
MO/TO (mail order/telephone order/contact center)
Server to Server
Verified by VISA/SecureCode
Gateway interfaccia per Mobile Commerce
Gateway interfaccia per TV Digitale Terrestre
Carte di credito gestite
VISA
MasterCard
Amex
Diners
JCB
Aura
Funzionalità di Back-office per l'esercente
Accesso user-id psw
Operatività differenziata amministratore /operatore
Utilizzo tramite API (application program interface)
Utilizzo tramite interfaccia grafica
Funzionalità di gestione ordini
Autorizzazione e Contabilizzazione Ordini
Immediata
Differita
Gestione ordini in lotti diversi
Autoriz. differita e contabiliz. immediata/differita
Autoriz. immediata e contabiliz. Differita
Autoriz. immediata e contabiliz. immediata
rel. 1.2.2
pag. 7 di 30
Funzioni dispositive
Richiesta autorizzazione
Richiesta contabilizzazione
Annullamento richiesta di contabilizzazione
Richiesta storno
Divisione/riduzione autorizzazione
Chiusura/annullamento ordine
Funzionalità di supporto
Mail notifica pagamenti vs esercente/compratore
Reportistica e storico degli ordini ricevuti
Prospetti statistici sui pagamenti/ordini ricevuti
Filtri dettagliati per la ricerca degli ordini.
Certificazioni
Certificazione ISO 27001
Certificazione PCI-DSS (Payment Card IndustryData Security Standard)
Flussi dispositivi vs banche
Assistenza Esercenti in fase di integrazione
Pagine di pagamento compliant con le regole
di accessibilità (W3C)
1.6 Documentazione del Servizio
Descrizione del Servizio:
@ POS - Pos Virtuale per Pagamenti con Carte di Credito
Specifiche Tecniche:
@POS – Manuale di Riferimento per l’Integrazione con i Merchant System
Modulo di adesione:
Modulo Adesione Esercente @POS
rel. 1.2.2
pag. 8 di 30
2.
Architettura del Servizio
2.1 Modalità MO/TO con Inserimento Manuale
@ POS - Inserimento Manuale
Venditore
Browser
Legenda:
1: Richiesta di autorizzazione a SIA-SSB (SSL 128)
1 (SSL 1 28)
2: Inoltr o richiesta di autorizzazione ai circuiti
3: Esito transazione
4 (SSL 128)
4: Esito transazione a video (SSL 128)
5
5: E-mail di conferma al venditore
3
2
CIRCUITI AUTORIZZATIVI E BANCHE
Tale modalità non richiede nessuna particolare attività d'integrazione da parte del Merchant.
Il Merchant deve compilare i campi del form @POS, come da specifiche operative, inserire il
numero di carta di credito e la relativa scadenza ed inoltrare il tutto verso SIA che processerà
l'operazione.
rel. 1.2.2
pag. 9 di 30
2.2 Modalità server-to-server con integrazione Merchant System
@ POS - Integrato con il Merchant System
M ERCHANT
Merchant System
Merchant
Server
1 (SSL 128)
Legenda :
1 : Richiesta di autorizzazione a SIA-SSB (SSL 128)
4 (SSL 128)
2 : Inoltro ichiesta di autorizzazione ai circuiti
3 : Esito transazione
4 : Esito transazione (SSL 128)
2
3
Sul server del venditore, deve essere presente un’ applicazione che utilizza un client HTTPS per
comunicare con il server SIA in modalità sicura tramite SSL 128 bit.
rel. 1.2.2
pag. 10 di 30
2.3 Modalità Redirect con Transazione SSL
Il compratore al momento del pagamento viene re-indirizzato sulla pagina web di @POS,
presente sul server sicuro di SIA, nella quale inserisce i dati della carta di debito/credito
(numero carta, data scadenza ed eventuali quantità di sicurezza) ed ottiene on-line l’esito
dell’operazione richiesta.
@Pos
MERCHANT
compratore
Browser
Merchant System
1
Merchant
Server
2
8
4 (SSL 128)
8
5 (SSL 128)
3
7
6
Legenda:
1: ordine
2,3: totale ordine
4: form per inserimento dati di pagamento
5,6: richiesta di autorizzazione
7,8: esito
Questa modalità di pagamento garantisce una maggior sicurezza nella transazione sia al titolare
delle carta che all’esercente in quanto i dati della carta utilizzata per il pagamento transitano
solo sul server sicuro di SIA.
rel. 1.2.2
pag. 11 di 30
2.4 Modalità Redirect con Transazione Verified by VISA/SecureCode
In questa modalità di pagamento, del tutto simile a quella descritta nel precedente capitolo, il
sistema @POS rileva che la carta utilizzata è abilitata al servizio VbV/SC innescando così il flusso
di seguito riportato.
Step 1
: il titolare chiede di effettuare un acquisto su un sito di un esercente abilitato ai
servizi VbV/SC ed inserisce i dati della carta di credito dando inizio alla transazione;
Step 2
: il sito dell’esercente si collega attraverso la componente Merchant Plug-In (MPI) al
Directory Server (di Visa o Mastercard) che verifica se la carta aderisce al servizio
VbV/SC (contattando l’ACS appropriato);
: se la carta aderisce al servizio, l’MPI invia una richiesta d’autenticazione del titolare
all’ACS (Access Control Server) attraverso una redirect del browser del titolare;
: l’ACS richiede la password al titolare e la verifica;
: l’ACS restituisce un identificativo univoco della transazione (CAVV) e l’esito
dell’autenticazione all’MPI attraverso una redirect del browser del titolare;
: il Merchant Server Plug-in verifica la risposta dell’ACS;
: se l’autenticazione ha avuto esito positivo, il sito dell’esercente prosegue con il
normale processo autorizzativi.
Step 3
Step 4
Step 5
Step 6
Step 7
N.B. La componente Merchant Plug-In è integrata nella piattaforma @POS. L’esercente non ha
bisogno di alcun software aggiuntivo.
rel. 1.2.2
pag. 12 di 30
2.5 Modalità Server-to-server Verified by VISA/SecureCode
Le autorizzazioni Verified By Visa per le carte VISA e SecureCode per le carte MasterCard si
applicano solo alle carte Visa e Mastercard che sono abilitate a tale sistema di sicurezza.
Nonostante questa premessa l’integrazione @POS offre un’unica interfaccia per trattare tutti i
tipi di carte di credito; ovviamente per le carte che risultano abilitate a VbV/SC il
comportamento del sistema è necessariamente differente.
Di seguito viene riportato lo schema di funzionamento del sistema nei due scenari possibili.
1
1.1
Negozio
1.2
Directory
@POS
1.3
Circuiti Internazionali
1.
Il compratore è connesso al sito del negozio e inserisce i dati della carta di credito.
1.1.
Il negozio inizia il processo di richiesta autorizzazione, qualsiasi sia la carta,
semplicemente inoltrando un messaggio al sistema @POS;
1.2.
Nel caso di carta VISA e MasterCard, @POS si collega alle directory opportune e verifica
se la carta è abilitata al servizio VBV
1.3.
Se la carta non è abilitata a VBV/SC (o non è VISA/MC) @POS inoltra direttamente un
messaggio autorizzativo ai circuiti internazionali. La risposta fornita al sito del negozio contiene
l’esito della transazione.
rel. 1.2.2
pag. 13 di 30
Se al passaggio 1.2 il sistema @POS rileva che la carta è abilitata al servizio VbV/SC, viene
innescato il seguente scenario:
Protocollo @POS
1
1.1
1.2
2.1
1.3
Negozio
@POS
Directory
2
2.2
Sito ACS
Circuiti Internazionali
1.3.
Se la carta è abilitata a VbV/SC, la risposta al messaggio di 1.1 invece di contenere il
risultato della transazione contiene i dati per la redirect del compratore verso il sito ACS
dell’Issuer.
2.
L’utente, connesso al sito ACS, inserisce la sua password e viene rediretto nuovamente
verso il sito del negozio.
2.1.
Il negozio, con le informazioni arrivate da ACS, compila il messaggio e lo inoltra al
sistema @POS.
2.2.
@POS decodifica i dati ACS, inoltra la richiesta di autorizzazione ai circuiti internazionali,
e fornisce quindi l’esito della transazione in risposta al messaggio pervenuto.
rel. 1.2.2
pag. 14 di 30
3.
Operatività del Servizio
3.1 Attività del compratore e del venditore
Di seguito sono riportate schematicamente le attività del compratore e del venditore nelle
diverse fasi che caratterizzano il processo di pagamento con @Pos.
La descrizione che segue è valida per la modalità di acquisto di tipo redirect, mentre per la
modalità server to server, la fase di raccolta dei dati di pagamento è lasciata al venditore:
•
•
•
•
il compratore visita il negozio virtuale e mette la merce nel carrello virtuale;
terminata la fase di acquisto, il compratore inizia la fase di checkout, in cui il sistema gli
presenta un riassunto dell’ordine con eventuali spese di spedizione, valuta, dati per l’invio
della merce ecc., a fronte del quale il compratore effettua il controllo, conferma l’operazione
e prosegue;
a questo punto il merchant system fa si che il browser del compratore si colleghi al server di
SIA comunicando i dati riepilogativi dell’ordine (importo, valuta, numero d’ordine, ecc.) e gli
indirizzi internet necessari per il completamento della transazione;
il server SSL di SIA presenta al compratore una pagina che contiene:
•
•
•
i dati dell’ordine ricevuti;
i campi da compilare per il numero di carta di credito e la sua scadenza;
un pulsante per tornare al carrello virtuale del negozio, un pulsante per
confermare il pagamento;
il compratore compila i campi presenti e conferma il pagamento inviando i dati in SIA;
SIA processa i dati della carta e fornisce una pagina di risposta al cliente;
contemporaneamente SIA, in funzione della scelta effettuata dal venditore in fase di
adesione al servizio, può notificare l’esito al merchant system del venditore tramite una GET
HTTP verso l’indirizzo del merchant system deputato a ricevere l’esito;
in caso di risposta positiva, l’utente verrà indirizzato verso l’indirizzo del merchant system
deputato alla conclusione della transazione, in caso di risposta negativa verrà indirizzato al
carrello virtuale.
Al fine di evitare che nel processo di comunicazione dell’esito tra SIA e merchant vi sia
l’intromissione di un soggetto estraneo che cerchi di comunicare al merchant system false
autorizzazioni concesse, SIA autentica il messaggio di esito mediante la quantità segreta
condivisa con il venditore all’atto dell’adesione al servizio.
rel. 1.2.2
pag. 15 di 30
3.2 Adempimenti in fase di adesione
3.2.1 ADESIONE DELLA BANCA DEL VENDITORE
SIA aggiorna la directory contenente l'elenco delle banche convenzionate tramite il modulo di
adesione al servizio fornito all’atto dell’adesione.
3.2.2 ABILITAZIONE DEL VENDITORE
Il venditore che intende essere abilitato all’utilizzo del servizio @POS deve convenzionarsi con
una banca aderente e convenzionarsi con un Acquirer, per poter accettare presso il proprio
negozio virtuale pagamenti con carte di credito.
A fronte del convenzionamento di ciascun venditore, la banca inoltra a SIA il modulo contenente
le informazioni necessarie per la sua abilitazione.
In fase di abilitazione, SIA comunica a ciascun venditore in modo riservato:
- la quantità segreta necessaria per l’autenticazione dei messaggi;
- l’identificativo e la password necessari per accedere alle funzioni di invio transazioni, di
monitoraggio degli esiti, di contabilizzazione e di disposizione degli storni sul sito web di SIA
(back-office).
3.3 Acquisto e Pagamento
3.3.1 ATTIVITÀ VENDITORE
Di seguito sono riportate schematicamente le attività del venditore nelle diverse fasi che
caratterizzano il processo di pagamento con @POS, in funzione dell’architettura scelta:
@POS con inserimento manuale
Il venditore inserisce in un apposito form i dati relativi alla transazione, quali numero ordine,
importo, valuta, numero di carta, data scadenza carta, etc.
I dati vengono inoltrati in modalità sicura via SSL 128 bit verso SIA per essere processati,
l'elaborazione della transazione avviene online ed in risposta il server di SIA genera una pagina
HTML con l'esito. L'esito viene inoltrato verso il venditore in modalità sicura SSL 128 bit, dove
viene visualizzato a video.
Il venditore viene avvisato dell' esito della transazione anche mediante la spedizione di una email da parte di SIA, contenente il riepilogo dell' operazione.
rel. 1.2.2
pag. 16 di 30
@POS modalità server-to-server
Sul server del venditore, deve essere presente una applicazione che utilizza un client HTTPS per
comunicare con l'interfaccia web di SIA.
I dati della transazione vengono inoltrati in modalità sicura SSL 128 bit verso SIA per essere
processati, l'elaborazione della transazione avviene on-line ed in risposta il server di SIA genera
l'esito per il merchant system.
@POS modalità redirect con transazione SSL
Il compratore riempie il proprio carrello virtuale sul sito web del venditore; al momento del
pagamento il browser del compratore viene rediretto in modalità HTTPS sul server di SIA, nel
quale inserisce i dati di pagamento e conferma l’operazione. L’esito della richiesta viene
mostrato su una pagina web e, contestualmente, viene notificato tramite apposito messaggio al
venditore.
@POS modalità redirect con transazione Verified by VISA/SecureCode
La logica di funzionamento è identica a quella della modalità redirect SSL; in questo caso se
venditore e compratore sono entrambi aderenti ai protocolli Visa e MasterCard (Verified by Visa
e SecureCode) al compratore verrà richiesto da parte del proprio Issuer l’inserimento di una
quantità di sicurezza – password - per poter portare a termine con successo l’acquisto.
@POS modalità Server-to-server con Transazione Verified by VISA/SecureCode
La logica di funzionamento è quella descritta nella modalità server-to-server. Il compratore
inserisce le informazioni della carta di credito sul sito dell’esercente che le trasmette a SIA al
fine di innescare il protocollo VbV/SC. Nel caso di carta aderente al servizio, viene fatto
pervenire un apposito messaggio al server del venditore così da permettere l’indirizzamento del
browser del compratore verso i sistemi di autenticazione dell’Issuer.
3.4
Modalità operative scelte dal venditore
In fase di invio di ogni singolo ordine il venditore ha la facoltà di decidere a seconda delle
proprie necessità le seguenti modalità operative:
•
•
autorizzazione on-line o differita;
contabilizzazione immediata o differita.
Ciascuna delle due modalità di autorizzazione è compatibile con ciascuna delle due modalità di
contabilizzazione, ossia il venditore può scegliere di utilizzare ad esempio l’autorizzazione on-line
e la contabilizzazione immediata o differita.
rel. 1.2.2
pag. 17 di 30
3.4.1.1 Modalità di autorizzazione
Qualora il venditore tratti prodotti a magazzino infinito o effettui normalmente la verifica del
magazzino contestualmente all’acquisizione dell’ordine, può scegliere di operare con
l’autorizzazione on-line.
In questo caso, alla ricezione delle istruzioni di pagamento da parte del venditore, SIA innesca
immediatamente il processo di richiesta di autorizzazione nei confronti del circuito di carte di
credito e restituisce immediatamente l’esito.
3.4.1.2 Modalità di contabilizzazione
A fronte della scelta di contabilizzazione immediata, al termine della stessa giornata in cui è
stata concessa l’autorizzazione, SIA inoltra le informazioni per il regolamento contabile
dell’operazione alla banca convenzionante del venditore ed all’Acquirer.
A fronte della scelta di contabilizzazione differita, il venditore deve accedere al back-office per
confermare o annullare la contabilizzazione dell’operazione, entro il periodo di tempo stabilito in
fase di adesione di concerto con la banca convenzionante e con l’Acquirer. A fronte di ogni
operazione per la quale sia stata confermata la contabilizzazione, SIA procede all’inoltro delle
informazioni per il regolamento contabile dell’operazione alla banca convenzionante del
venditore ed all’Acquirer.
3.5
Attività di SIA
A fronte della compilazione del modulo di pagamento da parte del venditore, SIA effettua le
seguenti attività:
•
•
•
•
•
•
effettua i controlli formali;
qualora i controlli abbiano dato esito negativo, rifiuta la richiesta di pagamento ed inoltra
la segnalazione di errore al venditore;
qualora i controlli abbiano dato esito positivo, effettua la traduzione del messaggio
contenente le istruzioni di pagamento ed i riferimenti all’ordine nel
formato della richiesta di autorizzazione prevista dal relativo circuito di pagamento;
in funzione delle esigenze espresse dal venditore in fase di adesione, effettua i tipi di
operatività alternativi, denominati rispettivamente “autorizzazione on line” e
"autorizzazione differita a lotti";
rileva le informazioni per il regolamento contabile che provvede ad inoltrare alla banca
convenzionatrice e all’Acquirer,;
aggiorna gli archivi gestionali (movimenti, statistiche, fatturazione, etc).
rel. 1.2.2
pag. 18 di 30
4.
Back-Office
Il servizio di back office messo a disposizione da @POS ha una struttura gerarchica basata sulla
distinzione tra negozi che compongono, nel loro insieme, l’esercizio commerciale (esercente). In
modo trasversale la struttura organizzativa degli utenti che hanno accesso al back office è
basata sulla distinzione tra amministratore e operatori.
4.1
Esercizio e Negozi
La struttura su cui è basato il back office gestionale prevede che un unico esercente
(identificato da un’unica ragione sociale) possa distinguere al suo interno diversi negozi virtuali
di e-commerce. Questo non implica necessariamente che a ogni negozio sia associato un sito
web o un’area del sito diversa, ma può essere anche una suddivisione interna dell’esercizio
commerciale che raggruppa i prodotti in vendita in diverse vetrine virtuali. In questo modo
l’esercente può mantenere traccia della segmentazione delle vendite all’interno della propria
gamma di prodotti/servizi.
rel. 1.2.2
pag. 19 di 30
Infatti, all’atto della redirect del consumatore al momento del pagamento, tra le informazioni
trasmesse al sistema POS virtuale è prevista anche l’informazione relativa al negozio (tra quelli
presenti nell’organizzazione dell’esercente) da cui è stato generato l’ordine.
Nel caso in cui l’esercente non ritenga opportuno usufruire dell’articolazione dell’esercizio
commerciale in diversi negozi, può ovviamente mantenere la completa corrispondenza tra
esercizio e negozio. In questo caso l’esercizio commerciale definito dalla ragione sociale viene
identificato con un unico negozio all’interno del back office.
Qualora, invece, l’esercente opti per una gestione delle transazioni in funzione di una
segmentazione in negozi, l’esercente, in qualità di amministratore del sistema di back office ha
la possibilità di limitare l’operatività degli operatori solo ad alcuni negozi, mantenendo all’interno
del suo staff una chiara separazione delle responsabilità.
4.2
Amministratore e Operatori
In sede di convenzionamento al servizio l’esercente indica il responsabile amministratore del
servizio di back office, specificando i dati personali dello stesso. Vengono quindi fornite
all’esercente le chiavi di accesso (user-id e password) al back office che permettono
all’esercente di autenticarsi sul sito e di usufruire di tutte le funzionalità che il servizio offre.
Tra le funzioni specifiche accessibili solamente all’amministratore ci sono quelle che riguardano
la gestione degli operatori, ovvero quegli utenti che all’interno della organizzazione
dell’esercente avranno accesso al back office usufruendo di funzionalità limitate, così come
definite dall’amministratore stesso.
L’amministratore crea i profili degli operatori e ne definisce visibilità (i.e. negozi gestibili
all’interno dell’esercizio) e operatività (funzioni cui è abilitato nella gestione dei negozi su cui ha
visibilità).
Le operatività disponibili sono sostanzialmente di due tipi:
•
•
abilitazione alla consultazione: consente all’operatore solo l’accesso alle reportistiche e
statistiche degli ordini del negozio senza poter disporre o operare sulle transazioni di
pagamento;
abilitazione alla gestione: permette all’operatore di operare sugli ordini in modo
dispositivo usufruendo di tutte le funzionalità legate alla gestione delle transazioni di
pagamento.
rel. 1.2.2
pag. 20 di 30
4.2.1 Funzionalità di Accesso al Back-Office
L’accesso dell’amministratore e degli operatori al back office gestionale dell’esercente viene
effettuato direttamente dal browser accedendo attraverso login direttamente su un sito di SIA.
Per procedere all’autenticazione è necessario inserire user-id e password. Nel caso l’utente del
back office (amministratore, operatori) stia effettuando il primo accesso al, dopo
l’identificazione viene chiesto di cambiare obbligatoriamente la password segreta di accesso a
tutela della sicurezza nell’autenticazione.
Di seguito sono riportate due delle principali mappe di accesso alle varie funzionalità di backoffice.
rel. 1.2.2
pag. 21 di 30
4.3 Funzionalità di Supporto
Accanto alle funzionalità dispositive che permettono all’utente (amministratore o operatore) la
gestione operativa degli ordini, sono disponibili nel back office gestionale funzionalità di
supporto che rendono disponibili:
•
reportistica e storico degli ordini ricevuti
•
prospetti statistici sui pagamenti e sugli ordini ricevuti
•
filtro dettagliati per la ricerca degli ordini.
Le funzionalità di supporto sono disponibili sia all’amministratore dell’esercizio sia agli operatori
abilitati (in consultazione o in gestione) ad un negozio/esercizio.
4.4
Funzionalità di gestione degli ordini
4.4.1 MODALITÀ DI AUTORIZZAZIONE E CONTABILIZZAZIONE DEGLI ORDINI
L’esercente, sia per l’autorizzazione che per la contabilizzazione delle transazioni (ordini), può
operare secondo le seguenti modalità alternative:
•
“immediata”: la fase di processing dell’operazione (autorizzazione o contabilizzazione) è
contestuale alla finalizzazione dell’ordine da parte del consumatore;
•
“differita”: la richiesta di autorizzazione o contabilizzazione verso i circuiti di pagamento
avviene solamente a seguito di una successiva disposizione dell’esercente attraverso il back
office gestionale.
rel. 1.2.2
pag. 22 di 30
4.4.2 AUTORIZZAZIONI NON CONCESSE DAI CIRCUITI DI PAGAMENTO
A seguito di un’autorizzazione negata da parte dei circuiti a fronte di una “autorizzazione
immediata”, al consumatore verrà data evidenza direttamente on-line durante la fase di
pagamento ed avrà la possibilità di finalizzare l’acquisto utilizzando un’altra carta di pagamento
tra quelle accettate dall’esercente.
4.4.3 EVASIONE DI UN ORDINE IN DIVERSI LOTTI
Il sistema è in grado di supportare la gestione di un ordine “spezzando” la consegna in
successive e diverse spedizioni della merce in oggetto(3).
L’esercente che decide di effettuare lo split shipment di un ordine può trovarsi in tre differenti
situazioni, a seconda della modalità di autorizzazione e contabilizzazione prescelta:
Autorizzazione differita e contabilizzazione immediata/differita
In questo caso è sufficiente richiedere l’autorizzazione ai circuiti solo per la parte dell’ordine che
viene recapitata e che deve essere addebitata al consumatore.
Autorizzazione immediata e contabilizzazione differita
In questo caso è necessario accedere alla funzione “divisione/riduzione autorizzazione” in cui
viene visualizzato l’ordine in oggetto (autorizzato dai circuiti per l’intero importo): selezionando
l’ordine e modificando il valore dell’importo autorizzato (da addebitare al consumatore per la
consegna della merce) il sistema effettua uno split dell’operazione e riduce l’autorizzazione
concessa dai circuiti all’importo definito, mentre mantiene la rimanente parte dell’ordine ancora
operabile da parte dell’esercente nello stato di importo ancora “da autorizzare”.
Autorizzazione immediata e contabilizzazione immediata
In questo caso è possibile solo stornare la parte di importo che non deve essere addebitata al
consumatore (es: merce in parte non recapitabile), però non è più possibile operare sull’importo
stornato.
3
Questa modalità di consegna di un ordine può essere necessaria all’esercente per differenti motivi, ad
esempio perché la merce è solo parzialmente presente nel magazzino e si decide ugualmente di
recapitare al consumatore la parte dei prodotti presenti addebitandogli il solo importo relativo alla parte
della merce recapitata.
pag. 23 di 30
rel. 1.2.2
4.4.4 FUNZIONI DISPOSITIVE
Dopo aver scelto il negozio su cui operare, l’utente può fruire delle seguenti funzioni dispositive:
•
Richiesta autorizzazione;
•
Richiesta contabilizzazione;
•
Annullamento richiesta di contabilizzazione;
•
Richiesta storno;
•
Divisione/riduzione autorizzazione;
•
Chiusura/annullamento ordine.
4.4.4.1 Richiesta Autorizzazione
Consente di richiedere ai circuiti l’autorizzazione per l’importo dell’ordine o una parte di esso.
Selezionando questa funzionalità, all’utente vengono proposti tutti gli ordini che sono ancora da
autorizzare totalmente (autorizzazione differita) o parzialmente. Per ogni ordine vengono
evidenziate le informazioni peculiari che lo identificano (numero ordine, data ordine, importo e
valuta ordine) e altre caratteristiche associate alla modalità di pagamento (circuito di
pagamento).
Qualora la richiesta di autorizzazione venisse effettuata per un importo inferiore a quello totale
autorizzabile, l’utente contestualmente alla richiesta di autorizzazione, può disporre anche la
chiusura dell’ordine che, a questo punto, compare nell’archivio storico in quanto non è più
autorizzabile la parte residua dell’importo.
Qualora l’esercente non gestisca gli ordini in modalità autorizzazione differita e non operi
l’evasione di un ordine in pagamenti successivi, la selezione della funzionalità “richiesta
autorizzazione” darà luogo ad un insieme vuoto perché nessun ordine sarà in uno stato
consistente con la funzione in oggetto.
4.4.4.2 Richiesta contabilizzazione
Consente di richiedere ai circuiti di pagamento la contabilizzazione dell’importo definito, ovvero
disporre l’accredito dell’importo dell’ordine d’acquisto per l’esercente (e l’addebito sul conto
della carta utilizzata per il pagamento per il consumatore).
L’utente ha comunque la possibilità di valorizzare l’importo da contabilizzare con un valore
minore (es: sconti sull’importo totale dell’ordine). Qualora venga definito per la contabilizzazione
un importo inferiore rispetto a quello autorizzato, la rimanente parte dell’importo non è più
operabile; quindi, se l’utente necessita di contabilizzare solo una parte dell’ordine per gestire la
rimanente parte dell’ordine in un secondo tempo (split shipment) è necessario utilizzare la
rel. 1.2.2
pag. 24 di 30
funzione “divisione/riduzione autorizzazione” che permette di gestire in modo corretto l’evasione
degli ordini attraverso accrediti successivi mantenendo di volta in volta operabile il residuo
dell’importo.
4.4.4.3 Annullamento richiesta di contabilizzazione
Nel caso in cui l’utente abbia disposto per errore la contabilizzazione di un ordine, la stessa
richiesta può essere annullata senza alcun effetto sui circuiti di pagamento purché venga fatto
entro le ore 24:00 del medesimo giorno in cui è stata effettuata. Entro questo termine, infatti,
la transazione non è ancora stata processata dai circuiti. L’operazione disposta (“richiesta di
contabilizzazione”) risulta quindi, essere ancora totalmente reversibile e lo stato dell’ordine
viene ripristinato ad “autorizzato”. Gli ordini per i quali è stata richiesta la contabilizzazione nei
giorni precedenti non consentono questa reversibilità di gestione in quanto, il clearing delle
transazioni è già avvenuto In questo caso, l’unico modo per riaccreditare il consumatore
dell’importo contabilizzato è lo storno dell’operazione.
4.4.4.4 Richiesta storno
E’ possibile stornare, totalmente o parzialmente, un ordine autorizzato o contabilizzato con la
conseguenza che l’importo stornato non è più operabile dall’esercente. L’effetto dello storno è
diverso a seconda che venga applicato ad ordini autorizzati o contabilizzati:
•
Storno di un ordine autorizzato
ripristino del plafond della carta di pagamento del consumatore per l’importo dell’autorizzazione.
•
Storno di un ordine contabilizzato
riaccredito al consumatore pari all’importo stornato.
4.4.4.5 Divisione/riduzione autorizzazione
Permette l’evasione in successivi pagamenti di un ordine gestito con modalità di autorizzazione
immediata e contabilizzazione differita, qualora l’esercente debba addebitare al consumatore
solo una parte dell’ordine, addebitando la rimanente in un momento successivo. Accedendo a
questa funzionalità, l’utente ha a disposizione filtri di ricerca per identificare l’ordine in oggetto e
definire l’importo che rimane autorizzato e dovrà essere contabilizzato. In questo modo la parte
residua dell’importo risulta essere nello stato “da autorizzare”, permettendo così all’utente di
gestire successivamente l’addebito al consumatore come un ordine ad autorizzazione differita.
Gli unici ordini compatibili con la funzionalità “divisione/riduzione autorizzazione” sono quelli
gestiti con autorizzazione immediata e contabilizzazione differita e quindi saranno gli unici
visualizzabili nella tabella di interfaccia di questa funzione. Negli altri casi:
Gli ordini gestiti con autorizzazione differita supportano per loro natura la gestione split
shipment. Nel caso in cui un ordine sia gestito con autorizzazione differita e ne venga disposta
l’autorizzazione dell’importo (totale o parziale) non è possibile utilizzare questa funzionalità per
ridurre/dividere l’autorizzazione concessa. Qualora si renda comunque necessario l’addebito al
consumatore di un importo inferiore a quello autorizzato è possibile procedere in due modi:
rel. 1.2.2
pag. 25 di 30
•
Richiedere direttamente la contabilizzazione solo della parte che interessa
•
Procedere allo storno della parte di autorizzazione che non interessa e richiedere la
contabilizzazione dell’altra parte
In entrambi i casi è opportuno ricordare che la parte dell’importo autorizzato che non è stato
contabilizzato non risulta più essere operabile (processabile) dall’esercente. Gli ordini gestiti con
autorizzazione e contabilizzazione immediate necessitano di uno storno di transazione sui circuiti
di pagamento.
4.4.4.6 Chiusura/annullamento di un ordine da autorizzare
Questa funzionalità fornisce la possibilità all’utente di stabilire che un ordine, sebbene sia
ancora in parte o totalmente da autorizzare, venga chiuso e quindi che l’importo in oggetto non
sia più operabile (processabile). In particolare la funzione è quindi applicabile agli ordini il cui
importo risulti:
•
totalmente ancora da autorizzare. L’esercente ha ricevuto un ordine che è ancora da
autorizzare (modalità di gestione ordini con autorizzazione differita), ma che deve essere
annullato (es: merce non più recapitabile/esaurita/fuori produzione, disdetta dell’ordine)
•
parzialmente contabilizzato, rimanendone una parte da autorizzare (split shipment).
L’esercente ha ricevuto un ordine che è stato addebitato al consumatore (contabilizzato)
solo per una parte del suo importo totale e la parte rimanente deve essere annullata (es:
sconto al consumatore, parte della merce non più recapitabile/esaurita/fuori produzione,
disdetta di parte dell’ordine).
In entrambi i casi l’utente ha la necessità di stabilire che l’ordine in oggetto deve essere
considerato dal sistema gestionale come “chiuso” nonostante non sia stato del tutto addebitato
al consumatore. Il sistema back office invece, poichè parte dell’importo dell’ordine è ancora
operabile (autorizzabile e contabilizzabile), lo considera ancora come un ordine “attivo”, di
conseguenza lo visualizza nei prospetti dispositivi come un ordine su cui è ancora possibile
disporre un’autorizzazione e una contabilizzazione. Proprio per eliminare quest’ordine
dall’archivio degli ordini operabili e gestirlo come un ordine esaurito (storico degli ordini),
l’operatore utilizza la funzione “chiusura ordine”.
4.4.5 Reportistica e Storico Ordini
Attraverso questa funzionalità l’utente ha la possibilità di ottenere un report sullo stato degli
ordini ricevuti on-line.
Sono disponibili alcuni parametri di ricerca/filtri che possono essere definiti dall’utente e
consentono di personalizzare la reportistica (intervallo temporale di acquisizione degli ordini,
circuito di pagamento, numero d’ordine e importo dell’ordine).
I report visualizzati dall’interfaccia riportano:
•
dati identificativi dell’ordine (numero, data, circuito di pagamento, modalità di pagamento
del consumatore, stato dell’ordine, Acquirer e importo dell’ordine);
rel. 1.2.2
pag. 26 di 30
•
dettaglio dell’importo dell’ordine: autorizzato, contabilizzato, ancora operabile (da
autorizzare), non autorizzato (che non ha ottenuto l’autorizzazione dai circuiti),
eventualmente stornato e importo chiuso (inutilizzato a seguito della “chiusura” di un
ordine).
Dal report degli ordini è possibile accedere al dettaglio del singolo ordine contenente tutte le
informazioni relative dell’ordine e la storia cronologica delle operazioni effettuate su di esso,
dell’esito e dell’utente che ha operato.
4.4.6 Statistiche
Questa funzionalità permette all’utente di ottenere alcuni prospetti statistici che riassumono i
totali delle transazioni effettuate durante un certo intervallo temporale.
Definito uno specifico intervallo temporale la pagina di statistica visualizza il numero totale degli
ordini ricevuti in quel periodo con le totalizzazioni degli importi autorizzato, contabilizzato,
stornato.
4.5 Ricerche
Attraverso questa funzionalità è possibile interrogare il database degli ordini ricevuti per
effettuare una ricerca puntuale di un ordine o di una transazione (autorizzazione,
contabilizzazione, storno). La ricerca viene effettuata su due livelli:
•
“Ricerca” attraverso i dati identificativi dell’ordine: data ordine (intervallo temporale),
numero d’ordine, importo dell’ordine,
•
“Ricerca Avanzata” attraverso i dati identificativi della transazione associata ad un ordine:
operatore, data autorizzazione/contabilizzazione/storno (intervallo temporale), numero
autorizzazione, id transazione.
rel. 1.2.2
pag. 27 di 30
4.6 API di Back-Office
SIA mette a disposizione delle API che permettono di far dialogare il servizio @POS con il
sistema di gestione ordini dell'esercente. L’API è resa disponibile sotto forma di una web
application che accetta chiamate POST HTTP generate da una applicazione merchant. Tramite
questo meccanismo possono essere effettuate le operazioni di: richiesta di autorizzazione,
storno di un pagamento, contabilizzazione di una transazione autorizzata, verifica dello stato di
una transazione e interrogazione dei movimenti effettuati da un merchant in un certo periodo.
Per quanto riguarda la sicurezza della tratta di comunicazione Internet il grado di affidabilità
offerto è quello del protocollo SSL con cifratura a 128 bit, considerato “strong encryption”.
Per quanto concerne l’abilitazione API, l’amministratore del back office dopo essersi autenticato
tramite user-id e password può chiedere l'abilitazione all'utilizzo delle API @POS accedendo
all’interno del profilo negozio, in particolare nel dettaglio negozio.
rel. 1.2.2
pag. 28 di 30
5.
Livelli di Servizio
Il Servizio viene erogato con i seguenti tempi ed orari:
Autorizzazioni
Le richieste di autorizzazione vengono gestite da SIA in modalità on-line, dalle 00:00 alle 24:00,
sette giorni su sette. Contestualmente alla ricezione della richiesta pervenuta dal POS Virtuale,
SIA ritrasmette l’informazione verso gli Acquirer/Circuiti di pagamento.
Flussi Batch di rendicontazione
I flussi Batch necessari alla contabilizzazione delle operazioni vengono inviati agli Acquirer entro
il primo giorno lavorativo successivo alla data di ricezione da parte di SIA delle operazioni
pervenute dal POS Virtuale.
rel. 1.2.2
pag. 29 di 30
© copyright– SIA S.p.A
Tutte le informazioni riportate nel presente documento sono CONFIDENZIALI e non
possono essere utilizzate in toto o in parte, né cedute o riprodotte senza il permesso scritto
da parte del Gruppo SIA
rel. 1.2.2
pag. 30 di 30

POS - Banca Marche

Transcript

Documenti analoghi

Modulo FAST CLAIM - Deutsche Bank Easy

Privacy Policy - Dati societari

VOLKSWAGEN MOD. TOUAREG VERS. 08

- GE Elettronica

autorizzazione al subingresso nell`esercizio di

FIAT QUBO 08

Fulimeni pomate e creme meltonian

Sentenza 28 - Osservatorio di diritto comunitario e nazionale

Atto Dirigenziale N. 2731 del 17/07/2015 Il Dirigente

IN CUSTODY Venerdì 10 marzo - ore 20.45