Il seguente documento vi offre una panoramica generale sui diversi tipi di integrazione e sul nostro processo di pagamento. Se volete saperne di più sui diversi argomenti, trovate nei testi o nel menu dei link diretti. Vi porteranno a una descrizione più dettagliata comprensiva di esempi.
Elaborare pagamenti significa trattare dati sensibili. Soprattutto quando elaborate
carte di credito, ciò comporta grandi responsabilità e obblighi anche per gli esercenti. In particolare,
PCI DSS è rilevante
in questo contesto. Se siete un esercente ed elaborate dati di carte di credito, dovete essere almeno
level 4 compliant. Se memorizzate o elaborate dati di carte tramite il vostro server, i requisiti
salgono al level 3 o superiore.
La nostra piattaforma vi offre una sicurezza di classe A ed è naturalmente PCI Level 1 compliant.
Il nostro obiettivo principale è tenere voi, l’esercente, fuori dal perimetro PCI,
al fine di garantire un’integrazione dei pagamenti fluida e sicura per il vostro negozio online.
Abbiamo progettato la nostra API e i nostri esempi per permettervi di integrare in modo conforme al level 4.
Dall’introduzione di PCI V 3.0 gli esercenti non possono più ospitare i moduli di pagamento direttamente sul proprio sito web. I moduli in cui il cliente inserisce i propri dati di pagamento devono essere generati e ospitati da un fornitore conforme PCI Level 1.
Esistono due modi per implementare le pagine di pagamento nel vostro negozio online:
-
Integrazione con pagina di pagamento
-
Integrazione con iframe
Il secondo motivo per cui abbiamo scelto l’iframe è l’astrazione della raccolta dei dati. La raccolta dei dati può differire tra gestori e tipi di pagamento, costringendo l’esercente a integrare ogni tipo di pagamento singolarmente. Il nostro iframe, invece, contiene tutti i campi del modulo per raccogliere le informazioni di pagamento. In questo modo l’esercente può utilizzare un’unica API per ogni tipo di pagamento.
L’integrazione con pagina di pagamento è un’integrazione in cui reindirizzate il cliente alla nostra pagina di pagamento, dove inserisce i dati di pagamento.
Figure 1. Immagine di esempio di un’integrazione con pagina di pagamento
Ulteriori informazioni tecniche ed esempi di integrazione si trovano nella sezione dedicata alla pagina di pagamento.
Se non volete reindirizzare il vostro cliente fuori dal vostro negozio, avete anche la possibilità di implementare la nostra pagina di pagamento in un iframe direttamente nel vostro negozio online.
Abbiamo progettato le pagine di pagamento in modo che possiate integrare l’iframe direttamente nel processo di pagamento del vostro negozio online, dove viene selezionato il tipo di pagamento. Il JavaScript e l’iframe stesso sono progettati in modo che l’invio del contenuto all’interno dell’iframe possa essere attivato da un pulsante esterno all’iframe, nel negozio. Ciò significa che il cliente può prima inserire tutti i dati, l’applicazione dell’esercente crea l’ordine e poi il modulo viene inviato. Anche una convalida può essere attivata dall’esterno dell’iframe.
Il modulo all’interno del frame può essere personalizzato utilizzando template Twig. Questo consente di adattare il layout a quello dell’applicazione dell’esercente.
Figure 2. Immagine di esempio di un’integrazione con iframe integrata direttamente nel processo di checkout, dove viene selezionato il tipo di pagamento.
Ulteriori informazioni tecniche ed esempi di integrazione si trovano nella sezione dedicata all’iframe.
L’API è un’interfaccia unificata per elaborare tutti i tipi di pagamento supportati attraverso ogni gestore disponibile con un processo di pagamento standardizzato. In altre parole, una volta integrate le richieste obbligatorie, potete aggiungere ulteriori gestori o tipi di pagamento senza cambiare nulla nella vostra applicazione. Nel caso in cui aggiungiate tipi di pagamento che richiedono informazioni aggiuntive che non ci vengono inviate nella vostra richiesta, chiederemo semplicemente al vostro cliente di fornire queste informazioni aggiuntive.
Il concetto dell’API unifica le diverse integrazioni dei gestori in un’unica API di pagamento. Per raggiungere questa unificazione abbiamo dovuto sviluppare un’astrazione dei dati.
Questo comporta per voi i seguenti vantaggi:
-
Un’unica integrazione per collegare tutti i vostri gestori di pagamento
-
Potete aggiungere gestori o tipi di pagamento senza modificare la vostra applicazione
L’astrazione dei dati ha anche alcune implicazioni per voi:
-
Per adattarci a tutte le diverse API e alle loro restrizioni, può darsi che dobbiamo modificare o troncare alcuni dei dati che ci avete inviato nelle richieste, per conformarci ai diversi gestori.
-
Nel caso in cui manchino alcune informazioni, dobbiamo chiedere queste informazioni aggiuntive.
Non abbiamo standardizzato solo il modello dei dati per tutti i gestori, ma anche il processo di pagamento per ogni tipo di pagamento e ogni gestore.
Ogni transazione effettuata sulla piattaforma rispetta rigorosamente questo processo.
Quando una transazione viene creata, viene posta nello stato Pending, in cui può essere modificata liberamente.
Avete anche la possibilità di annullare la transazione. Verrà quindi spostata nello stato Voided.
Una volta che una transazione è Confirmed, non può più essere modificata. Non appena inizia l’elaborazione della
transazione, la transazione viene posta nello stato Processing.
Da Processing il pagamento può passare direttamente a fail oppure, se il pagamento ha successo, viene
impostato su Authorized o, nel caso in cui il pagamento venga acquisito direttamente, viene spostato nello stato Completed.
Non appena sappiamo che il pagamento è garantito o è arrivato sul vostro conto, spostiamo lo
stato della transazione su Fulfill. Nel caso in cui il pagamento non sia arrivato o non sia garantito
entro un periodo di tempo definito (a seconda delle caratteristiche di un tipo di pagamento), spostiamo la transazione
su Decline. Può anche darsi che dobbiamo chiedervi di decidere se volete impostare la transazione su Fulfill o Decline.
Gli stati Decline, Voided, Failed o Fulfill sono stati finali e vi danno un’indicazione chiara se,
ad esempio, la merce debba essere spedita nel caso di beni fisici o se il download debba essere sbloccato nel
caso di beni digitali.
La standardizzazione è uno strumento potente per voi come esercenti, perché standardizza il processo per la vostra integrazione indipendentemente dal tipo di pagamento che integrate. Tuttavia, ciò comporta anche alcune restrizioni o implicazioni di cui dovreste essere consapevoli:
-
Alcune integrazioni di pagamento richiedono di adattare dinamicamente le fatture che inviate al cliente. Per questo abbiamo integrato anche un motore di template per documenti e un’integrazione e-mail che vi permettono di inviare questi documenti direttamente al vostro cliente.
-
È possibile una sola chiusura finale. Potete modificare le voci della vostra transazione, ma una volta che la transazione è completata, non può più essere modificata.
Le nostre pagine di pagamento sono completamente responsive e ottimizzate per i dispositivi mobili per impostazione predefinita.
Sappiamo però che un’integrazione armoniosa nel design del negozio online è fondamentale per l’esperienza di acquisto del vostro cliente. Per questo abbiamo creato un editor di risorse che vi consente di personalizzare completamente e al volo il template della pagina di pagamento. Informazioni più dettagliate sul linguaggio di template che utilizziamo ed esempi si trovano nella documentazione delle risorse.
Figure 3. L’editor di risorse vi consente di definire l’aspetto della pagina di pagamento all’interno dell’applicazione.
Se avete più connettori per un tipo di pagamento, potete instradare le transazioni applicando delle condizioni. Le condizioni vi aiutano anche a definire quando un tipo di pagamento è visibile in generale al vostro cliente.
Mettiamo a disposizione un ampio insieme di condizioni diverse che un esercente può selezionare e configurare. Un elenco di tutte le condizioni disponibili si trova qui
In base alla condizione selezionata dovrete specificare ulteriormente quando e come questa condizione debba essere applicata. Il concetto di condizioni è pratico e vi consente di realizzare alberi decisionali molto complessi che altrimenti dovrebbero essere programmati nella vostra applicazione.
Esempio
Avete due contratti di gestore. Uno che vi consente di elaborare transazioni con carta di credito senza 3-D Secure e un altro contratto con 3-D Secure. Per ridurre al minimo il vostro rischio e le frodi, volete elaborare ogni transazione al di fuori del Regno Unito e superiore a 30 GBP con il terminale che richiede 3-D Secure. Ogni transazione inferiore a 30 GBP all’interno del Regno Unito può essere elaborata senza 3-D Secure. Per ottenere questo risultato potete impostare 2 condizioni e applicarle alla configurazione del vostro connettore:
-
Create un filtro per il paese dell’indirizzo di fatturazione e di spedizione e impostatelo sul Regno Unito.
-
Create un filtro per gli importi inferiori a 30 GBP.
-
Applicate il filtro alla configurazione del connettore per il gestore senza 3-D Secure.
Potete applicare più condizioni a una configurazione di connettore. Le condizioni possono quindi essere utilizzate anche per selezionare il connettore che elaborerà infine la transazione.
Esempio
Avete due gestori di pagamento. Un gestore viene utilizzato per l’Europa e uno per gli Stati Uniti per elaborare le carte. Volete elaborare gli ordini con un indirizzo di fatturazione e di spedizione statunitense tramite il gestore statunitense e il resto tramite il vostro gestore europeo. Per ottenere questo risultato potete creare i connettori per i due gestori.
-
Create una condizione per il paese dell’indirizzo di fatturazione e di spedizione, impostatela sugli Stati Uniti e applicate le condizioni al gestore statunitense.
-
Create una condizione per il paese dell’indirizzo di fatturazione e di spedizione, impostatela su tutto tranne gli Stati Uniti e applicatela al gestore europeo.
Tutte le configurazioni dei connettori sono ordinate in base alla loro priorità. Quando un determinato connettore non funziona, proviamo quello successivo. Ad esempio, quando un gestore è offline, proviamo semplicemente quello successivo. Proviamo quello successivo anche quando la transazione viene rifiutata da uno dei gestori.
I prodotti ricorrenti sono sempre più interessanti per gli esercenti. Tuttavia, la gestione degli abbonamenti è complessa e richiede una piattaforma sofisticata e potente per gestire carte di credito scadute, processi di sollecito ecc.
Forniamo un servizio astratto per la gestione dei pagamenti ricorrenti. Il servizio gestisce l’aggiornamento delle informazioni di pagamento (ad esempio i dati della carta di credito) e la gestione degli errori.
Possiamo effettuare un pagamento ricorrente in tre modi diversi:
1) Tokenizzazione: utilizziamo un token delle informazioni di pagamento creato in precedenza per addebitare il cliente. Ad esempio, per la carta di credito utilizziamo un token collegato a una carta memorizzata.
2) Addebito asincrono: alcuni tipi di pagamento non richiedono alcuna interazione dell’utente. In questa situazione possiamo addebitare comunque il cliente.
3) Addebito sincrono: inviamo un link, ad esempio via e-mail, che punta alla nostra pagina di pagamento e chiediamo al cliente di fornire su questa pagina le informazioni di pagamento di cui abbiamo bisogno per addebitarlo.
Potete applicare questi tre metodi in un charge flow. Ogni charge flow è composto da diversi livelli. A ogni livello proviamo tutti e tre i metodi per addebitare il cliente nell’ordine indicato sopra. Il numero e l’intervallo di questi livelli sono controllati dall’esercente. Questo offre la flessibilità di ricordare più volte al cliente di aggiornare le informazioni di pagamento prima che una transazione venga infine contrassegnata come riuscita o fallita.
La piattaforma si occupa dei diversi casi di errore o dell’aggiornamento dei tipi di pagamento. Tutto ciò che un esercente
deve fare è utilizzare il nostro charge endpoint e fornire il customerID e l’importo da addebitare. In base al
charge flow configurato, proviamo ad addebitare il cliente. Trascorsi i tempi definiti, un webhook informerà
la vostra applicazione se la transazione è andata a buon fine o se l’abbonamento deve essere interrotto.
Esempio
Il cliente paga la prima volta tramite la normale pagina di pagamento e crea con questo pagamento iniziale un token. L’applicazione dell’esercente può memorizzare questo token insieme al cliente. Per le transazioni successive l’applicazione fornisce questo token al nostro servizio. Quando i dati di pagamento memorizzati con il token non sono più validi, devono essere inviati più solleciti al cliente per aggiornare queste informazioni. Tuttavia, poiché tipicamente il conto non dispone di fondi sufficienti, vogliamo ritentare l’addebito dopo 5 giorni prima di iniziare a sollecitare il cliente.
Il servizio che forniamo si occuperà dell’intero processo. Il charge flow e i livelli del charge flow possono quindi essere applicati nel modo seguente:
-
Il primo livello prova semplicemente ad addebitare il cliente con il token. In caso di errore non deve essere inviato alcun messaggio e-mail. Il livello è impostato su una durata di 5 giorni. Ovvero, passiamo al livello successivo dopo 5 giorni.
-
Il secondo livello prova di nuovo ad addebitare il cliente con il token. In caso di errore viene inviata un’e-mail con un link di pagamento. Il livello specifica anche il tempo prima del passaggio al terzo livello.
-
Il terzo livello prova di nuovo ad addebitare il cliente con il token. Se anche questo fallisce, inviamo di nuovo un messaggio e-mail con il link, questa volta però con un messaggio più severo.
-
Dopo il terzo livello non definiamo alcun altro livello e quindi la transazione è considerata fallita.
È anche possibile creare più charge flow e applicarli ai diversi casi in base a condizioni. Il numero di livelli non è limitato.
Per ulteriori informazioni consultate la sezione sui charge flow e la tokenizzazione.
Investiamo anche molto del nostro tempo per offrire migliori analisi post-vendita. Per darvi statistiche più dettagliate sui tassi di conversione dei vostri pagamenti, abbiamo introdotto il concetto di gruppi di transazioni.
Le transazioni vengono raggruppate in gruppi di transazioni in base al customerID inviato. Le transazioni vengono raggruppate in
gruppi di transazioni. Gli strumenti tradizionali effettuano le loro analisi in base al numero di tentativi sulla pagina di pagamento e
confrontano poi le transazioni riuscite con quelle fallite. Tuttavia, un’informazione interessante sarebbe analizzare questo
per cliente e raggruppare le transazioni in gruppi di transazioni. Questo consente di identificare i molteplici tentativi di un
cliente, che possono essere distribuiti su un certo periodo di tempo quando un cliente prova a pagare più volte, e di contrassegnare infine una
transazione come riuscita anche se al primo tentativo con carta di credito il pagamento non è andato a buon fine, ma alla fine è
riuscito a pagare tramite un altro mezzo di pagamento come la fattura.
|
Important
|
Le transazioni vengono raggruppate in base al customerID. Nel caso in cui il customerID non venga fornito (NULL),
ogni transazione viene trattata come un gruppo di transazioni separato.
|
Tutte le transazioni raggruppate possono essere visualizzate in: Space > Pagamento > Gruppi di transazioni.
Se volete ottenere maggiori informazioni sui diversi tentativi, potete aprire i gruppi di transazioni per visualizzare tutte le transazioni associate. Avete anche la possibilità di filtrare i gruppi di transazioni falliti, riusciti o in sospeso applicando i filtri in alto.