01Tutti i metodi in una pagina
Il checkout hosted mette affiancati carte, Apple Pay, Google Pay e USDC. L'ordine 9F21-0716 a sinistra — tre voci, una commissione di elaborazione di €0.50, €49.00 da pagare — e la scelta del metodo a destra. Il cliente sceglie; la pagina si adatta; il merchant ha integrato una volta sola.
- Pulsanti carta, USDC e wallet sulla stessa schermata
- L'ordine completo — voci, commissioni, totale — accanto al modulo di pagamento
- Un'unica azione Pay €49.00 a prescindere dal metodo
02Mobile dallo stesso URL
Lo stesso URL di checkout si riadatta al layout per smartphone: l'ordine si riduce a una barra di riepilogo, i pulsanti dei metodi restano al loro posto, il modulo carta mantiene le etichette. Ciò che va in produzione su desktop vale anche su mobile — e quando vuoi che il pagamento avvenga dentro la tua app anziché in un browser, gli SDK iOS e Android presentano lo stesso checkout in modo nativo sullo stesso ordine.
03Ricevute che si spiegano da sole
Pagare con USDC si conclude con una ricevuta che il commercialista del merchant sa leggere. Metodo: 52.95 USDC su Base →︎ regolamento in EUR, al cambio indicato in ricevuta, 1 EUR = 1.0807 USDC. Riferimento 9F21-0716, inviata via email al cliente e scaricabile subito. Il cliente ha pagato in crypto; i libri dicono €49.00.
04Un back office per i link, non solo link
I payment link hanno una scrivania vera: 8 link per Arc Studio SRL tra pagati, attivi e scaduti, con importo, numero di pagamenti e stato su ogni riga. Le card in alto tengono il conto — 4 link attivi, €2,304.50 incassati questo mese in 18 pagamenti da link, €49.00 pagati oggi. Crea, cerca, esporta, fatto.
- Ogni link con il suo URL, importo e stato
- Incassato del mese e pagato di oggi in alto
- Crea un link nella stessa vista in cui li monitori
05Rimborsi sull'ordine
Un rimborso punta all'ordine, non a un metodo di pagamento. Il pannello si apre su 9F21-0716 con l'importo preimpostato all'intero €49.00, un motivo obbligatorio e una nota facoltativa che finisce negli export e sulla ricevuta del cliente. I fondi tornano automaticamente sul circuito di pagamento originale — i rimborsi carta sulla carta, gli ordini USDC come regolamento in EUR — di norma in 1–3 giorni lavorativi.
- Totale o parziale — qualsiasi importo fino all'addebito originale
- Motivo obbligatorio, nota riportata in ricevuta
- Percorso originale stornato in automatico, su entrambi i circuiti
06Il tuo checkout, riconoscibilmente tuo
Il branding è una pagina di impostazioni, non un progetto di servizi: carica un logo, imposta i colori di accento, testo e superficie, scegli font e stile degli angoli. L'anteprima live mostra il tuo checkout reale — desktop o mobile — prima di salvare, e l'accento guida il focus del pulsante di pagamento, i segni di stato e il tab attivo. Usalo sull'host di checkout fornito con la tua sandbox o sul tuo dominio.
07Metodi da attivare, non da costruire
I metodi di pagamento sono interruttori con dei provider dietro: carte con 3-D Secure, Apple Pay e Google Pay come pulsanti wallet, USDC su Ethereum, Base e Solana, bonifico SEPA con riferimento vIBAN. Accanto, il pannello di regolamento dichiara l'accordo senza giri di parole: i clienti vedono la conversione prima di confermare; tu regoli sempre in EUR.
- Interruttori per metodo con il provider indicato sulla riga
- Regolamento USDC: conversione automatica, payout giornaliero alle 23:00
- Routing carte con policy 3-D Secure visibile
08Integrazione drop-in
Crea un ordine, reindirizza alla pagina hosted, ricevi il risultato. Gateway si occupa della UI di pagamento, della logica dei metodi e delle ricevute. Nessun frontend di checkout da costruire, correggere o tenere aggiornato al variare dei metodi.
09L'ordine è l'unità
Tutto ruota attorno all'ordine, non al metodo di pagamento. L'ordine 9F21-0716 porta le sue voci — uno sprint di brand identity da €38.50, licenza del font €6.00, consegna urgente €4.00 — una commissione di elaborazione di €0.50 e un solo totale. Comunque venga pagato, quel riferimento è ciò su cui interroghi, riconcili e rimborsi.
10Configurazioni che non sorprendono nessuna sessione
Le modifiche a metodi e branding si applicano alle nuove sessioni di checkout — lo dice la schermata in cui le salvi. Un cliente a metà pagamento non si ritrova mai la pagina cambiata sotto le dita.
11Le carte, fatte bene
Il percorso carta è la parte noiosa, risolta: validazione inline, 3-D Secure con autenticazione forte del cliente integrata nel flusso sotto una policy di routing leggibile, e carte di test per sandbox per le prove di integrazione. Accettare crypto non peggiora mai il flusso carta.
12Apple Pay e Google Pay
I wallet sono pulsanti, non progetti. Apple Pay e Google Pay appaiono come sheet a un tocco nella stessa pagina e pagano con token del dispositivo — il vero numero di carta non arriva mai alla pagina — attraverso lo stesso ordine e la stessa ricevuta. Attivarli è un interruttore nella schermata dei metodi.
13USDC regolati in EUR
Le crypto sono prezzate a un cambio mostrato al checkout e regolate in euro. Il merchant non si ritrova mai con una posizione in token per sbaglio; i conti restano in una sola valuta.
14USDC su tre network
Il metodo USDC copre Ethereum, Base e Solana dietro un unico interruttore. Il cliente paga sul network in cui si trova il suo wallet; per il merchant non cambia nulla.
15Bonifico con vIBAN
Il pagamento tramite bonifico porta un riferimento vIBAN, così un pagamento SEPA in arrivo identifica il proprio ordine per costruzione. Attivalo per i clienti che vogliono una fattura da pagare da banca, e la riconciliazione resta automatica.
16Metodi locali dove contano
Oltre a carte e wallet, il checkout offre i metodi account-to-account e locali che un acquirente europeo si aspetta di vedere, proposti in base al paese del cliente anziché buttati in un lungo elenco.
17Buy now, pay later
BNPL sta sulla stessa riga dei metodi come tutto il resto — il cliente rateizza il pagamento, il merchant viene pagato in un'unica soluzione e il riferimento dell'ordine non cambia. Un interruttore, stessa ricevuta, stessa riconciliazione.
18Metodi che leggono il cliente
La pagina ordina i metodi in base a ciò che il cliente userà con più probabilità — paese, lingua, dispositivo e se ha già pagato da te — così l'opzione giusta è la prima, non la quarta.
19Prezzi nella loro valuta, regolamento nella tua
Mostra l'importo nella valuta del cliente con la conversione dichiarata prima della conferma, e regola comunque in EUR. Il cliente vede un numero familiare; il tuo ledger ne vede uno solo.
20Un checkout nella loro lingua
La pagina hosted localizza etichette, errori e ricevute. Nessuno abbandona un pagamento perché il pulsante era nella lingua sbagliata.
21Carte salvate e one-click
Un cliente che torna paga con una carta salvata con un tocco. La carta è custodita nel nostro vault e referenziata tramite token, quindi i tuoi sistemi conservano un riferimento, mai un PAN — e il secondo acquisto è più breve del primo.
22Abbonamenti e fatturazione ricorrente
Gli addebiti ricorrenti seguono una pianificazione che definisci tu — importo, intervallo, inizio e fine — su una carta tokenizzata. Ogni ciclo genera un proprio ordine e una propria ricevuta, così un abbonamento si riconcilia riga per riga come tutto il resto.
23Retry che recuperano ricavi
Un soft decline su un addebito ricorrente viene ritentato secondo una pianificazione anziché essere dato per perso, e il cliente viene avvisato solo quando serve. I rinnovi falliti smettono di essere churn silenzioso.
24Network token e aggiornamento carte
Le carte salvate sono conservate come network token e seguono il titolare attraverso riemissioni e scadenze. L'abbonamento che si interrompeva quando la carta veniva sostituita continua ad addebitare.
25API e area sviluppatori
Gli ordini si creano via API con chiavi di idempotenza — una richiesta ripetuta restituisce il risultato originale, mai un secondo addebito — e la sezione sviluppatori contiene chiavi e documentazione. Il checkout è hosted; l'integrazione è un pugno di endpoint, documentati dove si trovano le impostazioni.
26Webhook sul ciclo di vita dell'ordine
Il tuo backend sa dei pagamenti nel momento in cui avvengono: eventi webhook firmati sul ciclo di vita dell'ordine — pagato, fallito, rimborsato — con verifica della firma da parte tua e protezione da replay da parte nostra.
27SDK mobile per iOS e Android
Le app native presentano lo stesso checkout in-app, senza mandare l'utente su un browser. L'SDK gestisce la logica dei metodi, i wallet sheet e il 3-D Secure; l'ordine e la ricevuta sono quelli che il tuo backend già conosce.
I plugin per carrelli e-commerce collegano un negozio esistente a Gateway senza uno sviluppatore — installi, incolli le chiavi, fai un pagamento di prova. Gli stessi ordini arrivano nello stesso back office di quelli via API.
29Campi incorporati nella tua pagina
Quando il pagamento deve avvenire dentro il tuo layout, incorpora direttamente i campi di pagamento: gli input sono hosted e in ambito PCI da parte nostra, la pagina intorno è interamente tua e i dati della carta non toccano mai i tuoi server.
30Monouso, multiuso, scadenza
Un link può chiudersi dopo un pagamento o continuare a incassare: il posto al workshop della demo ha raccolto 3 pagamenti, l'ora di consulenza 6. Per impostazione predefinita i link scadono dopo 30 giorni, e quelli scaduti lo dicono invece di fallire in silenzio.
31Modalità test
Le prove di integrazione girano su sessioni di test, con le carte emesse insieme alle chiavi sandbox, prima che si muova qualcosa di reale. I flussi sono identici: ciò che passa in test è ciò che va in produzione.
32Un routing leggibile
Il traffico carte segue una policy di routing scritta in termini che conosci — circuito, paese di emissione, valuta, importo — e non una scatola nera. Vedi quale route ha seguito un pagamento dalla stessa schermata del pagamento.
33Un secondo tentativo prima di perdere la vendita
Un rifiuto soft viene ritentato su una route alternativa nella stessa sessione di checkout, prima che il cliente veda un errore. La maggior parte dei pagamenti recuperati sono pagamenti che il cliente non ha mai saputo di avere a rischio.
34Rifiuti in parole semplici
I codici grezzi dell'emittente diventano motivi su cui un operatore può agire — carta scaduta, fondi insufficienti, rischio emittente — e vengono raggruppati, così un pattern su molti pagamenti si vede come tale.
353-D Secure come policy, non come attrito
La maggior parte dei pagamenti passa con i soli segnali del dispositivo e comportamentali; una sfida di step-up compare quando la policy lo richiede. La policy la decidi tu — sempre, basata sul rischio o in esenzione dove le regole lo consentono — e la pagina hosted gestisce il flusso.
36Una riga per riconciliare
Checkout, ricevuta e regolamento riportano lo stesso riferimento d'ordine. Chi cerca 9F21-0716 trova un'unica voce da €49.00 — non un record carta in un sistema e un record crypto in un altro.
37Regolamento e payout
Il regolamento è dichiarato dove lo configuri: conversione automatica in EUR, regolamento su RO49 •••• 0421, payout giornaliero alle 23:00. La cifra che il commercialista vedrà domani si decide oggi, su una schermata che il merchant può leggere.
38Un payout di cui ricostruire l'origine
Ogni payout si apre negli ordini che lo hanno generato, con le commissioni dettagliate. La riga in banca corrisponde a un elenco esportabile, così la chiusura di fine mese è una ricerca, non un'indagine.
39Rimborsi parziali
L'importo del rimborso è modificabile fino all'addebito originale: il pannello mostra il massimo e tratta come parziale qualsiasi importo inferiore. Dieci rimborsi parziali su un ordine si riconciliano comunque su un unico riferimento.
40I motivi dei rimborsi, a registro
Ogni rimborso ha un motivo obbligatorio e una nota facoltativa, e la nota viaggia: compare negli export e sulla ricevuta del cliente. Sei mesi dopo, nessuno deve ricordarsi perché l'ordine 9F21-0716 è stato rimborsato.
41Invio delle ricevute
Le ricevute vengono inviate al cliente via e-mail e si possono scaricare subito; le ricevute di rimborso seguono lo stesso percorso. Il merchant non deve mai creare un template di ricevuta.
42Storno prima del regolamento
Annullare prima del batch giornaliero rilascia il blocco dell'autorizzazione e non si muove denaro: nessun rimborso, nessuna commissione, nulla da spiegare sull'estratto conto del cliente.
43Controlli sul rischio attivi di default
I pagamenti con carta passano da 3-D Secure con una policy di routing leggibile. I pagamenti con wallet portano l'autenticazione del dispositivo, e gli eventi webhook vengono verificati tramite firma prima di essere considerati attendibili.
44Regole scritte a modo tuo
Le regole di screening si leggono come frasi — importo oltre X dal paese Y con una carta usata per la prima volta — e agiscono di conseguenza: consenti, sfida o blocca. Dietro la stessa schermata ci sono le liste di carte, e-mail e indirizzi fidati o bloccati.
45Velocity e segnali del dispositivo
I tentativi ripetuti dalla stessa carta, dallo stesso dispositivo o dallo stesso indirizzo vengono intercettati da regole di frequenza, non da qualcuno che se ne accorge dopo. I segnali sono mostrati sul pagamento, non sepolti in un punteggio.
46Contestazioni con le prove allegate
Un chargeback si apre insieme all'ordine che lo ha originato: esito dell'autorizzazione, esito 3-D Secure, ricevuta, consegna, storico dei rimborsi. Rispondi da quella schermata e il fascicolo di prove si compone dai dati registrati, non dalla memoria.
47I dati carta non ti arrivano mai
La pagina che raccoglie i dati della carta è nostra, in ambito PCI e hosted. Che il cliente paghi sul nostro dominio, sul tuo o dentro la tua app, i tuoi server vedono un token e un riferimento d'ordine — mai un numero di carta.
48Cifrati a riposo, nell'UE
I dati di pagamento sono cifrati a riposo ed elaborati nell'UE. Per un merchant europeo, dove risiedono i dati è una risposta, non una nota a piè di pagina.
49Ogni azione a registro
Rimborsi, cambi di metodo, modifiche di branding, rotazioni delle chiavi: ogni azione viene scritta in un audit trail con operatore, timestamp e motivo. Le azioni privilegiate richiedono un motivo prima di essere eseguite.
50Ruoli per chi ne ha bisogno
L'amministrazione vede i payout, il supporto vede gli ordini ed emette rimborsi, gli sviluppatori vedono chiavi e log. L'accesso si assegna per ruolo, senza condividere un unico login.
51Un'anagrafica clienti
I pagatori si accumulano in una vista clienti — chi ha pagato, quanto spesso, con quale metodo — così un cliente ricorrente è un record, non una coincidenza di e-mail uguali negli export.
52Ricerca ed export CSV
Trova un pagamento per link o riferimento dalla casella di ricerca; esporta in CSV la vista corrente quando serve alla contabilità. Il back office parte dal presupposto che prima o poi il commercialista chiederà.
53I numeri, per giorno e per metodo
Volume, tasso di approvazione, rimborsi e mix dei metodi, nel periodo che scegli. Quanto basta per capire dove sono andati i soldi e quale metodo vale la pena promuovere — senza esportare nulla.
54La vista operatore dietro le quinte
Gateway si collega a Protocore Center: il back office dei payment link mostra ogni link con il trasferimento di regolamento associato e un link per aprirlo in Tracer con la traccia completa. Il tuo team ops vede attraverso il checkout, fino al ledger.
55Whitelabel o powered-by
Il checkout della demo appartiene ad Arc Studio SRL: il loro nome, il loro marchio, il loro ordine. Usalo con il footer powered-by-Protocore o in whitelabel completo — in ogni caso la pagina appare come tua.
