Payment Orchestration Platform

Il problema

Chi incassa per più clienti finisce a gestirlo a mano

Un'agenzia che tiene i checkout di più negozi si ritrova con conti bancari diversi, soglie contrattuali diverse, e nessun posto dove vedere chi ha incassato cosa. Tre cose vanno storte sempre, e sono sempre le stesse.

Il conto sbagliato

Si cambia il conto attivo e i rimborsi degli ordini vecchi vanno alla banca sbagliata, perché nessuno si era segnato chi aveva incassato davvero.

La soglia scoperta tardi

Il limite di volume del contratto si supera in silenzio. Ci si accorge quando l'acquirer scrive, non quando succede.

Il fallback che non si era chiesto

Un errore di rete sposta l'incasso su un altro provider, con altre commissioni e un altro contratto. Nessuno l'aveva deciso.

Come funziona

Dal metodo di pagamento al conto che incassa

Il core non sa cosa sia Redsys. Riceve cliente, importo e metodo; chiede al motore di routing chi serve quel metodo; prova i provider nell'ordine consentito. La rotazione fra conti è una particolarità di Redsys e vive dentro il suo adapter — mai nel checkout.

Checkouttenant + importo

→

Payment Routeridempotenza

→

Routingcard → redsys

→

Redsys Adapterrotazione

→

Ordineconto scritto

R1 · pieno

R2 · attivo

R10

Si ruota a volume, non a ordini

Soglia 1.000 €. Un ordine da 600 e uno da 300 restano sul primo conto. Quello da 200 la supera — e lo completa comunque il conto corrente. Il prossimo ordine va al conto successivo. La soglia decide chi incassa dopo, mai chi ha già cominciato a pagare.

Chi è fermo viene saltato

Solo i conti attivi entrano in catena: in pausa, disabilitati o in errore non vengono nemmeno tentati. L'ordine è deterministico — niente sorteggi, due esecuzioni uguali danno la stessa catena.

Il fallback non è mai cieco

Fra conti dello stesso provider è la rotazione normale. Per passare a un provider diverso serve un permesso scritto del cliente: cambiare da Redsys a Stripe vuol dire un altro contratto, non un ripiego tecnico.

Cosa c'è dentro

Le cose che di solito si scoprono di non avere

L'ordine si porta dietro il conto

Una rotazione successiva non cambia il provider storico. Anche la firma della notifica si verifica con la chiave di quel conto, non di quello attivo adesso.

Idempotenza centrale

Stesso cliente, stesso ordine, stessa chiave: la seconda richiesta restituisce la prima. Un doppio invio non diventa un doppio pagamento.

Clienti isolati davvero

Il tenant si risolve sul server, mai sulla parola del browser. Un conto forzato che appartiene a un altro cliente viene rifiutato, non solo nascosto.

Segreti fuori dal database

Nel record c'è un riferimento (env:NOME), mai una chiave. Le API restituiscono il riferimento; il valore non esce mai.

Webhook: prima la firma

Gateway unico per provider. Un evento che non si può verificare viene rifiutato con 401. Non esiste una scorciatoia «salta il controllo in sviluppo».

Audit di tutto

Chi, cosa, prima, dopo, IP. Compresi i tentativi di accesso falliti. Non si cancella.

La console

Schermate vere, non mockup

Queste immagini sono catturate dall'applicazione in funzione, con i tre clienti dimostrativi e i loro conti di prova.

Overview della piattaforma: clienti, conti Redsys, volume del giorno e del mese, ordini e rotazioni. — Overview: clienti, conti sul totale disponibile, volume, e per ogni cliente il conto in servizio con quanto manca alla prossima rotazione.

Dettaglio cliente: metodi di pagamento, pool Redsys con le barre del volume, pulsante ROTATE NOW. — Dettaglio cliente: l'albero dei metodi (Stripe e PayPal dichiarati non configurati, non nascosti), il pool con le barre del volume, e la rotazione manuale.

Gestione dei conti: stato, salute, priorità, volume del giro e azioni per ogni conto. — Gestione dei conti: stato e salute, priorità della catena, prova di connessione, pausa e disabilitazione. Il tetto dei dieci è applicato dall'API, non dal modulo.

Provider

Tre implementazioni, una interfaccia

Aggiungerne un quarto vuol dire scrivere un adapter e registrarlo: router, checkout e console non cambiano di una riga.

Redsys

operativo · ambiente di prova

Fino a dieci conti per cliente, con rotazione a volume. Redirect e InSite, firma HMAC verificata.

Stripe

adapter pronto · non collegato

Interfaccia completa e modello Connect. Senza chiavi si dichiara non disponibile, e Redsys incassa lo stesso.

PayPal

adapter pronto · non collegato

Stessa scelta: struttura al suo posto, sandbox, nessun account. Chi chiede PayPal riceve un no chiaro.

Sicurezza

Questa installazione non può toccare denaro vero

Non è una raccomandazione nei commenti: è un cancello che solleva, e non ha ripieghi.

LIVE PAYMENT PROVIDER BLOCKED.
This installation is TEST ONLY.

Un conto dichiarato live non entra nemmeno nell'archivio, quindi non può essere selezionato più tardi da nessuna strada.
Una chiave Stripe di produzione si riconosce dal valore (sk_live_…), non dal campo dichiarato nel record.
PayPal fuori da sandbox viene rifiutato allo stesso modo.
Un riferimento a segreto che punta a una variabile con LIVE o PROD nel nome non si risolve.
Gli script che toccano domini e temi pubblicati si rifiutano di partire da questa copia, ed escono con codice 78.

Stato del progetto

Cosa è pronto, e cosa no

Il quadro esatto, perché una piattaforma di pagamenti si valuta da quello che dichiara di non avere ancora.

Pezzo	Stato	Nota
Multi-tenant e isolamento	pronto	Tre clienti dimostrativi, verifica server-side su ogni rotta, prove automatiche.
Rotazione a volume Redsys	pronto	Soglia per cliente o per conto, cycle/stop, salto dei conti fermi, storico completo.
Routing e fallback	pronto	Regole per metodo e priorità; fallback fra provider solo su whitelist del cliente.
Console e simulatore	pronto	Nove schermate; il simulatore passa dallo stesso router del checkout.
Stripe e PayPal	adapter, non collegati	Interfaccia completa in sandbox. Restano tre chiamate reali per ciascuno.
Archivio	file JSON	Repository già astratti e campi in snake_case: il passaggio a PostgreSQL non tocca le firme.
Fatturazione SaaS	non iniziata	Il modulo è separato di proposito: gli incassi dei clienti e l'abbonamento non condividono codice.

Un incasso.
Molti conti.
Una regola sola.