Accettazione delle migliori pratiche di pagamento

Question

Sto creando un sito di e-commerce che utilizza il gateway di pagamento DPS. Il gateway di pagamento prende solo i dettagli degli utenti e restituisce se il pagamento è andato a buon fine o meno.

Mi chiedo solo se qualcuno ha delle buone risorse su come creare una pagina di pagamenti davvero solida in grado di gestire grandi volumi di transazioni in modo sicuro. Esistono tecniche e strategie ben collaudate per le pagine di pagamento ad alto volume?

Answer 1

Io non sono un esperto di elaborazione dei pagamenti e lo sviluppo di applicazioni e-commerce, ma alcuni dei miei orientamenti (di buon senso) sono:

1. Forza HTTPS per la presentazione delle informazioni da parte degli utenti CC (praticamente tutto l'elaborazione dei pagamenti i gateway impongono l'uso di SSL quando comunicano con il loro gateway);
2. Non conservare le informazioni della carta di credito nel database dopo l'elaborazione; *
3. Seguire le linee guida generali di sicurezza (ad esempio non salvare le password in testo normale o le password e-mail);

* Nota:

PCI fa consentire la memorizzazione dei dati della carta di credito dopo l'elaborazione, ma avete bisogno di hosting PCI-compliant, che di solito è piuttosto costoso. E anche allora stai correndo un rischio enorme. Quindi se decidi di offrire ai tuoi clienti questa opzione (e so che è molto allettante dato che siti di grandi dimensioni come Amazon offrono tutti "one-click" checkout), è meglio assicurarsi che l'applicazione e il server siano bloccati.

Non so molto sui problemi di scalabilità con l'elaborazione dei pagamenti perché non ho esperienza in quell'area. Tutte le mie applicazioni elaborano solo circa 5-25 ordini al giorno.

Answer 2

Usa SagePay (precedentemente Protx) supporta PayPal e ti permette di prendere i pagamenti con carta. Si integra anche in Sage Suite (un sogno da sogno) che può automatizzare un sacco di tempo per l'immissione dei dati.

www.sagepay.com

Come altri stanno dicendo - A volte per i siti più piccoli non vale la pena correre il rischio di conservare le schede di te stesso. Preferisco pagare su siti web in cui sono reindirizzato a un servizio di pagamento noto (come paypal, sagepay o google checkout) perché so che molti soldi sono spesi per proteggere questo software. Se sei un sito web che sto usando per la prima volta, beh, sto per essere scoraggiato.

Answer 3

Ti consigliamo di progettare il codice in modo tale da mantenere i tuoi dati in uno stato valido.

La grande responsabilità che si deve affrontare è che si inviano i dati per Auth/Capture, e quindi, per qualsiasi ragione, qualcosa sulla propria parte non riesce. Hai addebitato il tuo cliente, ma per qualsiasi motivo, non sai questo fatto! Alla fine, un cliente irato inizierà a urlare per telefono. È un brutto momento.

L'idea generale è di mettere alcune misure di sicurezza in atto in modo da poter identificare questo tipo di problemi. Il problema dovrebbe essere molto raro, se mai dovesse succedere, quindi risolvere il problema sarà probabilmente un processo manuale.

Ecco cosa farei:

1. design una tabella di database che tiene traccia dei pagamenti (chiamiamolo "pagamento"), e si riferiscono al vostro tavolo "ordine" (riferimenti così payment.order_id order.id).
2. Quando è il momento di interagire con il gateway, impostare un nuovo record di pagamento, contenente tutti i dati non sensibili che si sta per passare al gateway di pagamento. Avere una colonna "stato" nella tabella dei pagamenti e impostarla su "in sospeso"
3. Tentare la transazione di autenticazione/acquisizione con il gateway. Dopo aver ricevuto una risposta, aggiornare lo stato del record di pagamento su "approvato", "rifiutato" o "errore" e salvare eventuali metadati pertinenti (motivi di rifiuto, ID transazione, ecc.). Se il gateway va in timeout, probabilmente si tratta solo di una sorta di "errore", anche se potresti riprovare una o due volte.

Eseguire un cron job ogni tanto cercando i record di pagamento "in sospeso" e più vecchi di, diciamo, 30 secondi. Se ne trovi qualcuno, prendi il panico e dillo a uno sviluppatore/operatore.

Ci sono sicuramente altre cose che potrebbero andare storte, ma questo è il grande che mi viene in mente e la strategia che ho descritto è quella che ho usato in più occasioni per mitigare il rischio.