Integration Types
Altre funzionalità
Card Payments
Mobile Wallets
Alternative Payment Methods
Resources
Questa pagina descrive come inviare al gateway le transazioni avviate dal titolare della carta di credito e avviate dall'esercente al fine rispettare gli standard dei circuiti delle carte di credito per l'elaborazione di tali transazioni.
L'esercente può avere un'integrazione in cui raccoglie i dettagli di pagamento dai paganti, li archivia e li utilizza per elaborare pagamenti futuri per i paganti. In tal caso, fornire informazioni al gateway nella transazione iniziale che indicano che si stanno archiviando dettagli di pagamento e che si intendono usare per un utilizzo futuro. È inoltre necessario fornire queste informazioni al gateway quando si utilizzano i dettagli di pagamento archiviati per eseguire i pagamenti successivi, avviati dal pagante (transazione avviata dal titolare della carta di credito) o dall'esercente a seguito di un accordo di pagamento con il pagante (transazione avviata dall'esercente).
Questa operazione è necessaria per rispettare gli standard del circuito delle carte di credito per l'elaborazione dei pagamenti avviati dal titolare della carta di credito e avviati dall'esercente utilizzando i dettagli di pagamento archiviati (noti anche come requisiti di credenziali su file (COF)). L'invio di informazioni al gateway per identificare i dettagli di pagamento archiviati, le transazioni avviate dal titolare della carta di credito e le transazioni avviate dall'esercente può fornire:
Il gateway supporta i seguenti pagamenti utilizzando i dettagli di pagamento archiviati dal DirectAPI a partire dalla versione 54.
È possibile utilizzare 3-D Secure con i pagamenti avviati dal titolare della carta di credito. Per ulteriori informazioni, leggere i seguenti dettagli specifici.
Una transazione avviata dal titolare della carta di credito è una transazione avviata con la partecipazione attiva del pagante. Ad esempio, una transazione per ordini e-commerce, tramite posta o telefono.
Per indicare che la transazione è stata avviata dal pagante, è necessario impostare transaction.source
su INTERNET
/MOTO
/MAIL_ORDER
/TELEPHONE_ORDER
/VOICE_RESPONSE
/CALL_CENTER
. In questa guida, utilizziamo un pagamento via Internet (transaction.source
=INTERNET
) per illustrare una transazione avviata dal titolare della carta di credito; tuttavia, è possibile modificarlo in uno qualsiasi degli altri valori consentiti.
Una transazione avviata dal titolare della carta di credito può essere un pagamento una tantum in cui generalmente non si memorizzano i dettagli di pagamento forniti dal pagante. Tuttavia, è possibile stipulare un accordo con il pagante per archiviare i dettagli di pagamento per un utilizzo futuro (di solito come parte di un processo di registrazione o creazione di un account del cliente) ed eseguire le successive transazioni avviate dal titolare della carta di credito utilizzando i dettagli di pagamento archiviati.
Laddove, durante un'interazione con il pagante, il pagante accetta che l'esercente possa archiviare i dettagli di pagamento per un uso futuro, è necessario fornire i seguenti campi nella transazione iniziale:
sourceOfFunds.type
=CARD
oppure SCHEME_TOKEN
sourceOfFunds.provided.card.*
oppure sourceOfFunds.token
transaction.source
=INTERNET, and
sourceOfFunds.provided.card.storedOnFile
:TO_BE_STORED.
Per i pagamenti successivi avviati dal pagante (non dall'esercente) e in cui vengono utilizzati i dettagli di pagamento archiviati del pagante, è necessario fornire:
sourceOfFunds.type
=CARD
oppure SCHEME_TOKEN
sourceOfFunds.provided.card.*
oppure sourceOfFunds.token
transaction.source
=INTERNET, and
sourceOfFunds.provided.card.storedOnFile
:STORED.
Per informazioni su come indicare al gateway se i dettagli di pagamento sono archiviati, non archiviati o se si intende archiviarli, vedere Domande frequenti.
Una transazione avviata dall'esercente è una transazione che viene eseguita utilizzando i dettagli di pagamento archiviati, ma senza la partecipazione attiva del pagante. Nelle transazioni avviate dall'esercente, l'esercente offre:
In tali casi, l'esercente dovrò stipulare un accordo con il pagante su tali servizi. Il pagante deve concordare che l'esercente memorizzi i suoi dettagli di pagamento a tale scopo e gli consenta di avviare successivamente i pagamenti con i dettagli di pagamento memorizzati senza la sua partecipazione attiva.
Quando si stipula un accordo con il pagante che consente di inviare successivamente pagamenti avviati dall'esercente, è necessario fornire i seguenti dettagli dell'accordo nella transazione iniziale della serie, ovvero la transazione avviata dal titolare della carta di credito:
agreement.id
: un valore univoco generato dall'esercente per identificare un accordo di pagamento con il pagante. È inoltre necessario inviarlo nelle successive transazioni avviate dall'esercente per collegare i pagamenti in una serie. Ciò è necessario per ottemperare ai requisiti del circuito della carta di credito, nel quale l'ID dell'accordo funge da identificativo per collegare la precedente transazione avviata dal titolare della carta di credito ai successivi pagamenti avviati dall'esercente. agreement.type
: Indica se è stato stabilito l'accordo commerciale con il pagante. È necessario fornirlo solo quando si definisce l'accordo con il pagante, vale a dire, nella transazione avviata dal titolare della carta di credito.
Riferimento API per dettagli accordo [REST][NVP]
Quando si inviano pagamenti, effettuare una distinzione tra la prima transazione della serie, ovvero la transazione avviata dal titolare della carta di credito, e i successivi pagamenti della serie avviati dall'esercente. A tal fine è possibile utilizzare il campo transaction.source
, dove per la transazione iniziale, è necessario impostare transaction.source
=INTERNET
o qualsiasi altro valore consentito per indicare che la transazione è stata avviata dal pagante. Per i pagamenti successivi della serie, l'esercente deve impostare transaction.source
=MERCHANT
per indicare che la transazione è stata avviata dall'esercente. Il Your payment service provider deve avere "MERCHANT" abilitato come origine della transazione consentita sul collegamento all'acquirer dell'esercente.
Riferimento API per l'origine della transazione [REST][NVP]
Quando si invia la prima transazione avviata dal titolare della carta di credito o i successivi pagamenti avviati dall'esercente in una serie, è necessario indicare al gateway se i dettagli di pagamento sono archiviati, non archiviati o si intende archiviarli. Per ulteriori informazioni, vedere le Domande frequenti.
Il pagamento periodico è un accordo in cui il pagante autorizza l'esercente a elaborare pagamenti per fatture o fatture periodiche a intervalli concordati (ad esempio, settimanale, mensile). L'importo potrebbe essere fisso o variabile.
È possibile inviare pagamenti periodici per l'elaborazione al gateway se si dispone di un accordo di pagamento con il pagante in base al quale il pagante autorizza l'esercente ad archiviare i dettagli di pagamento per un utilizzo futuro e ad avviare pagamenti periodici successivi senza la sua partecipazione attiva.
A tale fine, è necessario fornire i seguenti campi nella richiesta di transazione iniziale nella serie:
sourceOfFunds.type
=CARD
oppure SCHEME_TOKEN
sourceOfFunds.provided.card.*
oppure sourceOfFunds.token
transaction.source
=INTERNET, and
sourceOfFunds.provided.card.storedOnFile
=TO_BE_STORED
agreement.id
agreement.type
=RECURRING
Per i pagamenti successivi di una serie avviati dall'esercente, è necessario fornire:
sourceOfFunds.type
=CARD
oppure SCHEME_TOKEN
sourceOfFunds.provided.card.*
oppure sourceOfFunds.token
transaction.source
=MERCHANT
sourceOfFunds.provided.card.storedOnFile
=STORED, and
agreement.id
: Lo stesso agreement.id specificato nella transazione iniziale. Ciò consente al gateway di collegare i pagamenti in una serie.La tabella seguente specifica diversi scenari o casi d'uso per elaborare un'autenticazione 3-D-Secure con pagamenti avviati dal titolare della carta di credito. Per ulteriori informazioni sull'autenticazione 3-D Secure, fare riferimento alla Guida all'integrazione di 3D-Secure.
Per le transazioni esterne autorizzate, fare riferimento alle Linee guida per l'autenticazione.
I seguenti campi sono necessari per avere una transazione periodica corretta quando si utilizza l'API WS AUTHENTICATE_PAYER dalla richiesta della versione 61:
I seguenti campi sono necessari per avere una transazione periodica corretta quando si utilizza l'API WS AUTHENTICATE_PAYER dalla richiesta della versione 57-60.
Caso di utilizzo | Passaggi di integrazione |
---|---|
Stabilire un accordo periodico con il pagante che includa un addebito iniziale e avviare una nuova serie di pagamenti periodici. |
|
Stabilire una serie di pagamenti periodici quando inizialmente non è dovuto alcun pagamento Se si desidera stabilire una serie di pagamenti periodici con il pagante in cui non vi è alcun pagamento dovuto al momento in cui il pagante si iscrive al servizio. Esempio: Servizi di abbonamento mensile senza alcun pagamento richiesto quando il cliente si iscrive. |
Quando si fa riferimento alle Linee guida per l'autenticazione, utilizzare questi parametri aggiuntivi specificati nei passaggi seguenti per integrare 3DS per i pagamenti periodici. I passaggi 1 e 2 devono essere completati mentre il titolare della carta di credito è in sessione. Il passaggio 3 deve essere utilizzato quando si è pronti per elaborare il pagamento.
Mentre il titolare della carta di credito è in sessione, completare i passaggi 1 e 2. Quando si è pronti per elaborare il pagamento, utilizzare il passaggio 3. Passaggio 1: Avvio autenticazione
Passaggio 2: Autenticazione del pagante
Passaggio 3: Eseguire l'operazione di verifica e quindi scegliere una delle seguenti opzioni:
o
|
Aggiungere la carta senza stabilire un accordo sui pagamenti Se si desidera fornire un'opzione ai paganti per aggiungere i dettagli della loro carta durante la creazione del loro profilo o account senza avere un accordo di pagamento in vigore al momento della registrazione. La carta aggiunta può essere utilizzata in futuro. |
Quando si fa riferimento alle Linee guida per l'autenticazione, utilizzare questi parametri aggiuntivi specificati nei passaggi seguenti per integrare 3DS. Passaggio 1: Avvio autenticazione
Passaggio 2: Autenticazione del pagante
|
Il pagamento a rate è un accordo in cui il pagante autorizza il pagamento per un singolo acquisto da suddividere in una serie di pagamenti elaborati a intervalli concordati. Ad esempio, paga per un acquisto in sei rate mensili.
È possibile inviare pagamenti a rate per l'elaborazione al gateway se si dispone di un accordo di pagamento con il pagante e il pagante accetta di archiviare i propri dettagli di pagamento per un utilizzo futuro e autorizza l'esercente ad avviare pagamenti successivi a rate senza la sua partecipazione attiva.
A tale fine, è necessario fornire i seguenti campi nella richiesta di transazione iniziale nella serie:
sourceOfFunds.type
=CARD
oppure SCHEME_TOKEN
sourceOfFunds.provided.card.*
oppure sourceOfFunds.token
transaction.source
=INTERNET
sourceOfFunds.provided.card.storedOnFile
=TO_BE_STORED
agreement.id, and
agreement.type
=INSTALLMENT
Per i pagamenti a rate di una serie avviati dall'esercente, è necessario fornire:
sourceOfFunds.type
=CARD
oppure SCHEME_TOKEN
sourceOfFunds.provided.card.*
oppure sourceOfFunds.token
transaction.source
=MERCHANT
sourceOfFunds.provided.card.storedOnFile
=STORED
agreement.id
: lo stesso agreement.id specificato nella transazione iniziale. Ciò consente al gateway di collegare i pagamenti in una serie.Un pagamento non pianificato è un accordo in cui il pagante autorizza l'esercente a detrarre automaticamente i fondi per un pagamento per un acquisto concordato quando richiesto (non pianificato). Ad esempio, ricariche automatiche quando il valore del conto scende al di sotto di una determinata soglia.
È possibile inviare pagamenti non pianificati per l'elaborazione al gateway se si dispone di un accordo di pagamento con il pagante e il pagante accetta di archiviare i propri dettagli di pagamento per un utilizzo futuro e autorizza l'esercente ad avviare pagamenti successivi non pianificati senza la sua partecipazione attiva.
A tale fine, è necessario fornire i seguenti campi nella richiesta di transazione iniziale nella serie:
sourceOfFunds.type
=CARD
oppure SCHEME_TOKEN
sourceOfFunds.provided.card.*
oppure sourceOfFunds.token
transaction.source
=INTERNET
sourceOfFunds.provided.card.storedOnFile
=TO_BE_STORED
agreement.id, and
agreement.type
=UNSCHEDULED
Per i pagamenti pianificati successivi di una serie avviati dall'esercente, è necessario fornire:
sourceOfFunds.type
=CARD
oppure SCHEME_TOKEN
sourceOfFunds.provided.card.*
oppure sourceOfFunds.token
transaction.source
=MERCHANT
sourceOfFunds.provided.card.storedOnFile
=STORED, and
agreement.id
: lo stesso agreement.id specificato nella transazione iniziale. Ciò consente al gateway di collegare i pagamenti in una serie.Per rispettare gli standard del circuito della carta di credito per l'elaborazione delle transazioni avviate dal titolare della carta di credito e avviate dall'esercente, è necessario indicare al gateway se i dettagli di pagamento sono archiviati, non archiviati o si intende archiviarli utilizzando il campo sourceOfFunds.provided.card.storedOnFile
.
Per la transazione iniziale, ovvero la transazione avviata dal titolare della carta di credito:
sourceOfFunds.provided.card.storedOnFile
.sourceOfFunds.provided.card.storedOnFile
=TO_BE_STORED
. Ciò indica al gateway che il pagante ha accettato di archiviare i propri dettagli di pagamento. È necessario impostare questo valore: Per i pagamenti successivi, sia nel caso di una transazione avviata dal titolare della carta di credito in cui vengono utilizzati i dettagli di pagamento archiviati del pagante, sia nel caso di transazioni avviate dall'esercente utilizzando i dettagli di pagamento archiviati, impostare sourceOfFunds.provided.card.storedOnFile
=STORED
Con la tokenizzazione del gateway, il gateway imposta i valori predefiniti per conto dell'esercente.
sourceOfFunds.provided.card.storedOnFile
=NOT_STORED
sourceOfFunds.provided.card.storedOnFile
pari al valore fornito dall'utente nella richiesta di transazione. È possibile fornire TO_BE_STORED
o NOT_STORED
nella transazione avviata dal cliente.
sourceOfFunds.provided.card.storedOnFile
=STORED
Riferimento API per archiviazione su file [REST][NVP]
Se non si dispone di un identificativo univoco per l'accordo con il pagante, è possibile:
Se al momento di stabilire un accordo di pagamento con il pagante non si intende effettuare alcun addebito al pagante, ad esempio, se si tratta di un abbonamento a una rivista che prevede il primo pagamento dopo 30 giorni, è necessario inviare una richiesta Verify con i dettagli del contratto:
agreement.id
agreement.type
La transazione Verify diventa la prima transazione della serie avviata dal titolare della carta di credito. Per eventuali pagamenti successivi, utilizzare l'agreement.id
per collegare i pagamenti della serie.
Se il pagante è stato autenticato utilizzando l'autenticazione 3-D Secure in MPGS, è possibile fornire il authentication.transactionId
utilizzato nella transazione originale.
Per le transazioni autenticate esternamente, consultare la pagina Implementazione di un'integrazione 3DS utilizzando l'API di autenticazione e andare alla sezione Opzioni > Invia una richiesta di pagamento preautenticata.
I dettagli di pagamento a fronte di un accordo possono cambiare, ad esempio, se:
Se i dettagli della carta sono cambiati (tranne in caso di riemissione di token scaduti di carte e circuiti della carta di credito), è necessario eseguire una transazione avviata dal titolare della carta di credito utilizzando lo stesso ID accordo per aggiornare i dettagli di pagamento o il token del gateway prima di eseguire una transazione avviata dall'esercente con il nuovo numero della carta. A seconda del modello di business, è possibile scegliere di creare un nuovo accordo.
Se si utilizza un token del circuito della carta di credito, il numero della carta archiviato associato al token del circuito può essere automaticamente aggiornato dal circuito.