Newsgroup: it.comp.java
Titolo: pagamento con banca

Ho la seguente situazione:
devo fornire all'utente del sito la possibilita' di pagare tramie carta di 
credito, e per questo mi hanno messo a disposizione un pagamento online.
La successione di operazioni e' la seguente:
- l'utente seleziona la modalita' di pagamento: carta di credito... e qui 
siamo nel nostro sito.
- poi viene mandato a una pagina con iframe, che ospita il sito della banca. 
La pagina della banca permette di immettere il codice e di confermare il 
pagamento.
- a questo punto dentro l'iframe si carica una pagina loro nuova, che fa una 
richiesta al nostro sito ad un indirizzo accordato (richiama una servlet sul 
mio sito). I parametri passati a questa mi fanno capire se il pagamento e' 
riuscito o e' stato abbandonato.
Ora come avere la certezza che un pagamento confermato da loro venga anche 
confermato nel mio sito? Impossibile direi.
Potrebbe succedere il mio server va giu proprio mentre la banca cerca di 
contattare la mia servlet, in linea di principio, perdendo cosi' l'ordine. 
Beh bisogna dire che la mail della banca arriva cmq all'amministratore.
Come procedereste voi? 

cicap wrote:

Direi che ti devi gestire degli stati per le transazioni di pagamento:
o) quando invochi il gateway dei pagamenti metti in stato di "pending" la
    tua transazione
o) se ricevi la conferma dal gateway, la tua transazione passa in stato
    di "confirmed" e quindi puoi procedere con l'evasione dell'ordine
o) se ricevi una risposta negativa dal gateway, la tua transazione di
    pagamento passa in stato di "refused" (carta non valida, credito non
    disponibile, annullamento da parte dell'utente, ecc.) e l'ordine
    non viene processato
Ovviamente il tutto deve essere "loggato" (su file, su db, ...) e se
qualcosa va storto nella comunicazione tra la tua applicazione e
il gateway, ti rimarranno delle transazioni in stato di "pending" che
dovrai trattare in modo opportuno.
In quanto alla e-mail di conferma, in realta' neanche l'arrivo di questa
ti e' assicurato al 100%...
Ciao!
Roberto

 writes:
c> Ora come avere la certezza che un pagamento confermato da loro
c> venga anche confermato nel mio sito? Impossibile direi.
Impossibile  no. Arduo  si, se  ti vuoi  rifare la  ruota da  solo. Le
transazioni distribuite sono cose "antiche" ed in ambito Java sono pane
per i denti per la Enterprise Edition che è nata proprio per quello.
-- 
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico  
\/		    e allevatore di bug da competizione


ok ma i db mio e quello della banca dovrebbero essere strettamente 
accoppiati per un cosa del genere.
Io non ho nessun controllo sulla parte della banca.
L'unica cosa che ho e' quella richiesta fatta dal mio browser alla 
servlet...


Certo, beh ho avuto la conferma che quello che ho fatto era giusto allora, 
perche' piu' o meno ho implementato gli stati che hai descritto.
Comunque purtroppo il gestionale sul quale mi appoggio non ha alcuna nozione 
di stato dell'ordine al momento, quindi il negoziante si trova nel 
gestionale sia gli ordini confermati che quelli pendenti. 

 gestionale sia gli ordini confermati che quelli pendenti. 
Non conosco il sistema che stai sviluppando, ma non dovrebbe essere
molto complicato mettere a disposizione del negoziante un piccolo
front-end di amministrazione con il quale egli possa controllare
lo stato delle transazioni di pagamento e verificare quali sono
state confermate e quali no. Ovvio che sarebbe piu' comodo avere
tutto integrato in un unico strumento, ma se non si puo' fare altrimenti...
In piu' puoi gestire un sistema di messaggistica e-mail che notifichi
le transazioni di pagamento rimaste in stato di "pending".
Ciao!
Roberto

> 
c> ok ma i db mio e quello della banca dovrebbero essere strettamente 
c> accoppiati per un cosa del genere.
No, non è richiesto.
I  sistemi di  controllo delle  transazioni distribuite  fanno proprio
questo, garantirti che al momento in cui ti dicono è andato tutto bene
sia andato  tutto bene  su varie parti  senza richiedere che  le varie
parti  siano strettamente  accoppiate come  accade per  le distributed
transactions, che so, di Oracle.



Forse mi sono spiegato male o in modo incompleto.
Ti faccio un esempio, consideriamo l'atomicita' delle transazioni:
se scrivo nel database della banca, e poi successivamente scrivo nel 
database interno del mio sito, e la scrittura su quest'ultimo fallisce, 
oppure il mio server salta, non ho nessun modo per annullare la write sul db 
della banca: non ho alcun controllo sul loro db. Infatti la banca non mi 
fornisce mica un db da interrogare, ma solo un interfaccia web. 

riuscito o e' stato abbandonato.
E se l'utente, in modo fraudolento, riuscisse a passare alla tua
servlet un falso OK prima che arrivi la risposta della banca?
Ti troveresti un ordine accettato e pagato, la merce spedita e...
nessun bonifico sul conto del venditore. 
Ci hai pensato? 
Alessio
_____________________________________
Per rispondermi in email togli NOSPAM

 servlet un falso OK prima che arrivi la risposta della banca?
In una transazione del genere ci sarą pure qualche piccolo accorgimento
di sicurezza, non credi?

 di sicurezza, non credi?
Esatto i pagamenti tramite carta di credito sono loggati sulla banca, e 
quella fa testo non il mio db che e' solo un aiuto e anche un modo per 
vedere cosa e' stato comprato. 

 Ci hai pensato? 
Aggiungo alle altre precisazioni che le transazioni di questo tipo
possono essere basate su un meccanismo di autenticazione con
One Time Password (BancaSella ad esempio fa cosi') che rende
praticamente impossibili le operazioni fraudolente.
Ciao!
Roberto

 writes:
c> Ti faccio un esempio, consideriamo l'atomicita' delle transazioni:
c> se scrivo nel database della banca, e poi successivamente scrivo
c> nel database interno del mio sito,
c> Infatti la banca non mi fornisce mica un db da
c> interrogare, ma solo un interfaccia web.
Sicuro che non ti metta  pure a disposizione dei servizi invocabili da
remoto ?
Solo l'iframe ? Che scarsi :>
(Peraltro  da  loro, 10  a  1, c'č  un  CICS  in funzione,  l'antenato
mainframe degli EJB...)
Anyway
c> Ti faccio un esempio, consideriamo l'atomicita' delle transazioni:
c> se scrivo nel database della banca, e poi successivamente scrivo
c> nel database interno del mio sito,
Se PRIMA alteri il db  locale sotto transazione (applicativa o del DB)
e POI passi la palla alla banca vedi che:
     se da te le  cose non vanno a buon fine puoi  evitare di tirar di
     mezzo la banca.
     se  la banca  dice  picche al  pagamento,  un bel  rollback e  la
     vendita va in cavalleria, altrimenti una commit e grazie per aver
     comprato da noi.
Aggiungere poi  del sano e robusto  logging che permetta  di avere uno
strumento in  piů per  ricuperare le situazioni  in cui le  cose vanno
male...
