Gateway di pagamento e API RESTful

Naviga le tue risposte
2

Ho un'API RESTful che offre funzionalità di eCommerce. Un'area che sto cercando di decidere sulla corretta implementazione è come elaborare i pagamenti.

Diciamo che ho il seguente URI GET ... / checkout / {id} / pagamento. Questa risorsa fornisce dettagli all'applicazione client di quali dettagli devono essere inviati per effettuare un pagamento. Le specifiche delle informazioni nella risorsa dipendono dalle implementazioni seguenti

Implementazione 1 La risorsa contiene i campi di pagamento di base da compilare come numero di carta, indirizzo di fatturazione ecc. I dati vengono inviati all'API utilizzando POST ... / checkout / {id} / pagamento . L'API invia quindi una richiesta al gateway di pagamento (ad es. Paypal), attende la risposta e quindi invia una risposta appropriata all'applicazione client.

Implementazione 2 La risorsa contiene dettagli su come inviare una richiesta direttamente al gateway di pagamento (ad esempio, paypal). Il client invia il pagamento al gateway, attende una risposta e quindi invia il riferimento di pagamento (normalmente sempre fornito da un gateway di pagamento) all'API utilizzando il POST ... / checkout / {id} / pagamento.

Il problema che sto avendo è che entrambi hanno pro e contro.

L'implementazione 1 direi che è il metodo più sicuro perché tutto è contenuto in una richiesta all'API. L'API può quindi aggiornare le tabelle di back-end una volta che il pagamento è stato elaborato e restituire lo stato di successo o di errore al client. Poiché l'API invia una risposta al gateway, sa che la risposta che riceve è autentica.

L'implementazione 2 libera l'API dal dover elaborare il pagamento che è ottimo, ma richiede al cliente di effettuare due richieste. Uno per il gateway di pagamento e uno per l'API con il riferimento. Inoltre, come posso convalidare il riferimento di pagamento sull'API senza chiamare il gateway? Un cliente disonesto potrebbe inviare qualsiasi riferimento all'API che potrebbe quindi essere contrassegnato in modo errato come pagato.

Volevo solo lanciare le mie idee là fuori, ma se qualcuno ha una soluzione davvero buona per l'implementazione dei gateway di pagamento e dei servizi web RESTful API sarebbe grandioso.

Aggiorna Ho appena pensato a Implementazione 3 . Potrei effettivamente creare un'API più piccola separata per gestire i pagamenti. Funzionerebbe in modo simile all'implementazione 1, tranne che l'applicazione client non registra su api.site.com / .... ma pubblica su gateway.site.com / ... Questo mi dà un grado di sicurezza come Controllo il codice su gateway.site.com e garantisce che api.site.com non venga impantanato aspettando che il fornitore di servizi di pagamento risponda. L'API del gateway diventa quindi essenzialmente un client dell'API principale e pubblica i dettagli del successo del pagamento.

Qualche idea su questo?

    
posta Gaz_Edge 07.01.2014 - 23:05
fonte

3 risposte

1

Suppongo che ti aspetti che il tuo sito abbia una grande quantità di traffico. Se questa ipotesi è corretta, direi andare con una versione ottimizzata di Implementazione 3 . Se api.site.com e gateway.site.com si trovano su due server diversi, avrei anche un terzo server per ospitare il DB e fare in modo che entrambe le app sfruttino il DB centralizzato. Ciò eliminerà la necessità di api.site.com e gateway.site.com di conoscersi l'un l'altro e di mantenere tutto il lavoro in un'area designata, rendendo più facile il debugging.

E se la mia ipotesi non è corretta, direi di andare su una versione modificata di Implementazione 3 . Quindi ti crearei due app separate che comunicano con lo stesso Db e che semplicemente ospitano tutto sullo stesso server. Che è fondamentalmente quello che ho appena detto sopra ma tutto sullo stesso server. Questo dovrebbe ridurre l'overhead iniziale e rendere il ridimensionamento un gioco da ragazzi quando sarà il momento.

    
risposta data 08.01.2014 - 15:38
fonte
0

Molto dipende dal fatto che stai costruendo una piattaforma, per cui l'Implementazione 1 è adatta o se è solo la tua piattaforma di eCommerce, l'Implementazione 2 può essere meglio.

L'implementazione 1 consente la scalabilità se prevedi di offrire più gateway di pagamento. Tutti offrono le proprie API REST e l'astrazione fornirà la scalabilità. Se si dispone di un gateway singolo, il vantaggio sarebbe la flessibilità di modificare il gateway di pagamento in una data successiva, che sta diventando una cosa comune ora a un giorno. Avrai anche il controllo in caso di problemi tecnici o di interruzione della rete. Se stai archiviando dati in qualsiasi forma, dovresti avere a che fare con la conformità PCI, che è tempo e denaro aggiuntivi.

Implementazione 2 Ti consentirà di essere operativo nel modo più rapido possibile, senza dover affrontare la conformità PCI. D'accordo, dovresti effettuare una seconda chiamata al gateway, ma fornisce sicurezza sulla validità della transazione, che sarebbe più veloce rispetto al pagamento dell'elaborazione.

    
risposta data 08.01.2014 - 01:51
fonte
0

Per la maggior parte dei casi, Implementazione 1 sarebbe più adatto. È più semplice da proteggere e probabilmente molto più facile da eseguire il debug / log.

Il grosso problema che ho con Implementazione 2 è che dovresti distribuire le credenziali al client affinché possano connettersi direttamente al gateway di pagamento. Questo potrebbe essere possibile per alcuni sistemi, ma dubito di tutto. Sospetto che sarebbe anche molto più difficile eseguire il debug in caso di problemi. Cosa succede, ad esempio, se il pagamento viene inviato al gateway, ma non si riceve mai il secondo messaggio di conferma?

    
risposta data 08.01.2014 - 05:50
fonte

Leggi altre domande sui tag

Entità nidificate in Google App Engine. Lo faccio bene? Rilevamento degli schemi di viaggio nei dati geospaziali