Integrazione con un fornitore di pagamenti; Approccio OOP corretto e robusto

Come sviluppatore che lavora quasi esclusivamente con i pagamenti, forse posso darti alcuni suggerimenti su dove sono le possibili insidie. Sto lavorando per un sito ad alto traffico, ~ 40 fornitori di servizi di pagamento attivi (PSP) e che gestiscono decine di migliaia di transazioni al giorno. E credimi, lo sh * t colpirà sempre il fan e tutto ciò che puoi fare è prepararti il più possibile a gestire la situazione da quel punto.

Accedi, registra e registra ancora ...

Questa è la parte più importante della tua procedura di pagamento, assicurati di avere un record di tutto . Porsi le domande "questa informazione potrebbe aiutarmi una volta su un milione di transazioni?". Se la risposta è sì, registralo!

La nostra configurazione è che il punto principale di registrazione è il database. Ogni transazione avviata, non riuscita, risolta, reindirizzata, ecc. Viene memorizzata per PSP nelle tabelle. Se la PSP utilizza un'API, vengono registrate tutte le chiamate API (sia le richieste inviate sia le risposte). Tutti i callback sono registrati anche nelle tabelle. E così via ..

Quando incontriamo un evento imprevisto o un'eccezione, lo registriamo nel file di registro PHP con un determinato formato per renderlo ricercabile e facilmente reperibile in base all'ID transazione, all'ID utente, ecc.

Ti sarà grato di avere tutti i dati se per esempio ti viene fatto causa.

Monitoraggio e avvisi

Costruisci la logica di monitoraggio con alcuni semplici test che ti avviseranno tramite email quando qualcosa va storto. Ad esempio, se 3 callback in una riga falliscono per una PSP. Tutte queste piccole cose che possono aiutarti a risolvere rapidamente i problemi invece di reagire a loro dopo che i tuoi clienti ti hanno reso consapevole di loro (cosa che non sempre accade) è molto importante.

Transazioni di database

Se hai il lusso di configurare o modificare la struttura del tuo database per supportare le transazioni del database, ad esempio usa InnoDB su MySQL. Dai un'occhiata a questa risposta su come gestirlo nel codice. Dovresti assicurarti che ogni fase di una transazione sia completata o che nessuna di queste funzioni, poiché le transazioni parzialmente completate sono solo un onere per te e il tuo sistema. Ad esempio: 1) L'utente completa la transazione, 2) L'utente viene premiato in qualche modo. Se non vengono soddisfatti entrambi i passaggi 1 e 2, la transazione non deve essere impostata come completata nel passaggio 1.

Persone tecniche da contattare

Quando hai un problema tecnico, assicurati di avere qualcuno tecnico da contattare immediatamente. Avere un account manager è piuttosto inutile, specialmente se quella persona decide di mediare tra te e il loro tecnico.

Esempio di live world che mi è successo: una PSP ha smesso di funzionare all'improvviso, nulla nel nostro codice è cambiato e dicono che non hanno cambiato nulla. Dopo aver inviato informazioni di debug avanti e indietro con loro (tramite il loro account manager), uno dei loro tecnici si accorge che i recuperi dello schema WSDL sembrano non funzionare. Poi si rendono conto che hanno aggiornato il loro schema WSDL e dopo un po 'di debug mi rendo conto che PHP ha memorizzato nella cache il vecchio schema WSDL. Questo potrebbe essere stato colto prima come risolto se avessi solo una persona tecnica su Skype da contattare direttamente. O se hanno appena ammesso di aver modificato il proprio schema WSDL, ma è spesso difficile ottenere una confessione dai PSP quando qualcosa va storto ...

Parole finali ...

Prepara tutto quello che puoi e presumi che QUALSIASI possa accadere:)

Non sono sicuro che questo fosse esattamente il tipo di risposta che cercavi, ma sto cercando di fornire un esempio reale di pagamenti e di come evitare le trappole e le insidie più grandi. Fammi sapere se c'è qualcosa che vorresti che io approfondissi o se sei interessato a un altro argomento.

Secondo la mia opinione sincera, il modo migliore per gestire le transazioni attraverso un Payment Gateway è attraverso i servizi web. Un certo numero di gateway di pagamento diversi offre questo tipo di servizi per percentuali percentuali piane competitive per transazione + la tipica commissione di carte di credito che verrà utilizzata anche dalla carta di credito del cliente (ad esempio Cybersource ). Con molto di tutto nella vita, ottieni quello per cui paghi, un 9 cent / transazione non esiste con un processore di pagamento affidabile che non ti obbliga a reindirizzare gli utenti.

Tokenizzazione e dati protetti

Memorizzare i dettagli della carta di credito sul tuo sistema è solo un problema e, a seconda di dove vivi, potrebbero esserci anche requisiti legali e possibili leggi penali contro il modo in cui questi dati vengono gestiti. A meno che tu non sia Amazon, non dovresti preoccuparti di tutta quella complessità tecnica e legale. Il responsabile del pagamento prende questo rischio e la complessità lontano da te con servizi Web crittografati SSL in cui i dettagli della carta di credito possono essere passati attraverso il tuo sito al tuo server e dal tuo server ai servizi web del processore di pagamento per inviare un pagamento tramite il tuo account con il processore. In cambio, il servizio web ti restituirà un codice di autorizzazione o un token che indica in modo univoco la transazione sul loro sistema e ti fornisce un numero di riferimento per cercare rapidamente nel tuo account transazioni specifiche. Puoi conservare il token nel tuo database e non è una vera conseguenza per gli utenti se i token sono compromessi sul tuo sistema. Inoltre, non memorizzando i dettagli della carta di credito sul tuo sistema, gli account bancari degli utenti sono sicuri anche se il tuo sistema è stato compromesso.

Conservazione dei record di pagamento

Questo approccio all'integrazione con un processore di pagamento ha il vantaggio di essere in grado di mantenere i propri pagamenti e acquistare record separati da quello del processore di pagamento, ma collegati tramite il token. Ciò consente di eseguire report sulle entrate attraverso il proprio sistema, query analitiche e gli utenti possono visualizzare i propri acquisti senza dover effettivamente interrogare il processore di pagamento per ottenere informazioni.

Conformità PCI

Qualsiasi rispettabile processore di pagamento avrà tutti i suoi sistemi e dati ospitati in server e strutture conformi PCI. Per ulteriori informazioni sui dettagli della stessa conformità PCI e sul motivo per cui è importante, vedere questo sito .

Ci sono determinati requisiti che devono rispettare, il loro data center deve essere protetto fisicamente e tecnicamente. Non possono avere alcun WAP non criptato sulla loro rete, ecc ... Niente di tutto questo ti preoccupa veramente, ma ci sono alcuni requisiti che i sistemi mercantili si aspettano che possano rivendicare anche la conformità PCI. Alcuni di questi requisiti includono ma non sono limitati a:

• Utilizzo della crittografia SSL su qualsiasi richiesta di pagamento tramite il tuo sito.

• In nessun caso i numeri delle carte di credito dovrebbero essere archiviati ovunque nei tuoi sistemi, inclusi i file di registro e persino gli oggetti serializzati.

• I server di applicazioni che comunicano con il processore di pagamento devono essere protetti da un firewall ben configurato che consente solo il numero minimo di porte aperte richieste.

• Solo personale tecnico appropriato dovrebbe avere accesso fisico o remoto a questi server applicazioni sulla rete.

• Altri ...

In genere la maggior parte dei processori di pagamento fornirà uno strumento online che può essere eseguito sulla rete e identificare possibili problemi con la conformità PCI. Non è ancora necessario NECESSARIO o NECESSARIO lavorare con un processore di pagamento, ma il processore di pagamento si riserva il diritto di addebitare costi aggiuntivi se si utilizzano i propri servizi e non si rispettano gli standard di conformità PCI.

Grazie alle idee di precedenti risposte, vorrei proporre la soluzione che ho ora; Spero che questo possa invitare uno o due commenti dalla conoscenza ciclopedica presente qui e aiutarmi a migliorarlo. Solo per chiarimenti: nonostante le questioni importanti, la mia domanda non riguardava come scegliere un Payment Service Provider (PSP), requisiti PCI DSS o implicazioni legali di qualsiasi cosa, ma solo le insidie tecniche che potrebbero incappare quando si implementa un "diretto" invece di un modello di "reindirizzamento" con qualsiasi PSP.

Prerequisiti

Il cliente è nella fase in cui inserisce i dati della carta di credito nel modulo. So cosa deve e quale importo e valuta voglio addebitare sulla carta di credito che invia.

Soluzione (?)

1. Al momento dell'invio del modulo contenente i dettagli della carta di credito, utilizzerò Javascript per interrompere l'azione predefinita sul pulsante di invio (che, se JS o AJAX non erano disponibili, potrebbe andare a una pagina di errore che indica all'utente di ottenere un browser più recente ...)
2. La richiesta (ripetuta da un timer) AJAX chiamerebbe uno script di aggiornamento dello stato, che di per sé attiva l'elaborazione effettiva in un file separato; utilizzando "ignore_user_abort () se il client chiude il browser o qualcosa di simile
3. quindi AJAX chiama per es. il metodo - > StatusUpdate () - se chiamato per la prima volta, avvia il processo e restituisce "pleasewait", nelle chiamate successive valuterà una variabile di sessione o qualcosa per aggiornare lo stato
4. Vorrei aggiornare il record dell'utente nel database per impostare un flag "lockSession" su "locked" - se qualcosa dovesse accadere prima di sbloccarlo, l'utente sarebbe informato sugli accessi successivi di contattare l'ufficio per risolvere qualsiasi disordine che potrebbe avere accadesse ...
5. inserire un record di pagamento nel DB con uno stato "preparato"
6. Invia la richiesta a PSP, utilizzando l'ID ordine del record di pagamento preparato. A seconda del PSP, la richiesta può essere presentata come una transazione in ritardo (il che significa che non sarà risolta automaticamente)
7. aggiorna il record preparato con il suo nuovo stato (se rifiutato, sblocca la sessione e torna alla pagina di pagamento; in caso di successo, aggiorna con lo stato "trasmesso")
8. Se avesse avuto successo, non avremmo il riferimento all'autenticazione e altri dettagli importanti dalla PSP, quindi invia la richiesta "stabilisci" alla PSP per il riferimento dell'autorizzazione ottenuto.
9. In caso di successo, aggiorna il record di pagamento per completarlo (o, nel mio caso, spostarlo e aggiornarlo da PendingTransactions a PaymentTransactions)
10. Rimuovi il flag "lock" dal record dell'utente

Altre considerazioni

Per favore, capisci quanto sopra come un invito a condividere le tue conoscenze e idee - sono solo idee finora!

Accesso

Sarei molto d'accordo con i nerdklers sulla registrazione - Attualmente sto considerando di utilizzare una qualche forma di registrazione basata su file per ogni fase del processo sopra (e di tenere i registri per alcuni giorni anche se completi e verificati - chi lo sa ...)

Transazioni di database

Non sono sicuro che sarei d'accordo con l'utilizzo delle transazioni del database. Stiamo utilizzando MS SQL e, con le impostazioni predefinite, qualsiasi transazione verrebbe ripristinata in caso di perdita della connessione. E quando si imposta la transazione su non eseguire il commit automatico o il rollback automatico, si potrebbe finire con alcune transazioni DB aperte e alcune implicazioni sul blocco record / tabella ecc. Penso che preferirò più aggiornamenti nel processo; nel caso uno di questi dovesse fallire (e il processo di conseguenza dovesse essere interrotto) l'utente sarebbe comunque impedito di inviare nuovamente una transazione eventualmente completata (ma non ancora registrata) fino a quando non è stata risolta manualmente.

AJAX, politico

Non sono completamente sicuro se dobbiamo ancora considerare i browser che non supportano AJAX. Immagino che sia comunque un argomento "politico". Penso che potremmo permetterci di prenderci delle libertà nei nostri affari, altri forse no.

AJAX, tecnico

Non sono così sicuro del mio approccio con la chiamata in modo asincrono di un metodo "StatusUpdate", che sarà in grado di avviare il processo vero e proprio alla prima chiamata. Ma farò di questa una domanda separata se non trovassi dei buoni esempi - che immagino potrei benissimo trovare. In ogni caso, se conosci una buona pratica, per favore lascia che me (e altri) sappiano nel tuo commento.

Considerazioni finali

Sarebbe bello se avessi un pensiero anche lontanamente avvicinandomi al termine "finale" - questo se lavori in corso per me e sono molto obbligato per qualsiasi feedback e ulteriori suggerimenti su come questo potrebbe essere migliorato.