Sicurezza di Checkout

Tapaya ospita i campi della carta e gestisce tokenizzazione, autenticazione della carta e addebito, quindi i Suoi sistemi non gestiscono mai dati della carta in chiaro. A Lei resta il server che crea i pagamenti e decide quando un ordine è pagato. Queste regole valgono sia per il Hosted Checkout sia per i pagamenti incorporati.

Per sapere come Tapaya tratta i dati del titolare della carta e i dati personali, consulti Protezione dei dati e privacy.

Conservare le chiavi sul server

• Salvi la chiave checkout dell'esercente o la Secret key dell'organizzazione solo nella configurazione lato server. Nessuna delle due va nel codice del browser, nei bundle delle app mobili o nel sistema di controllo versione. Al browser arrivano solo la publishable key e il client secret di un pagamento.
• Chiami la Checkout API dell'esercente dal Suo ambiente server. Non esegua queste richieste nel browser del cliente.
• Una chiave checkout dell'esercente dà accesso solo al proprio esercente. Al backend dell'esercente fornisca quella chiave, mai la Secret key della Sua organizzazione.
• La Secret key dell'organizzazione ha privilegi su tutta l'organizzazione. In modalità piattaforma, la invii con X-Tapaya-Merchant-Token in ogni richiesta; l'API verifica che l'esercente appartenga all'organizzazione della chiave. Si veda Autenticazione di Checkout.
• Le chiavi dell'esercente vengono mostrate una sola volta e salvate solo come hash. Revochi una chiave che sospetta sia stata esposta, dopo averne creata una sostitutiva.

Gestire l'ordine sul server

• Calcoli il totale dell'ordine sul Suo server e salvi l'ordine prima di creare una sessione o un tentativo di pagamento.
• Legga importi, valuta e ID dell'ordine dallo snapshot dell'ordine salvato. Non accetti valori sostitutivi inviati dal browser.
• Per i pagamenti incorporati, vincoli i Suoi endpoint prepare e submit a un checkout autenticato o a un cookie HTTP-only firmato e convalidi l'origine delle richieste che modificano i dati.

Verificare prima di evadere

Un reindirizzamento del browser, una visita al Suo URL di successo, i parametri della query, i cookie di ritorno e i messaggi del browser sono dati di navigazione. Nessuno di essi prova il pagamento.

• Recuperi la sessione dal Suo server e confronti riferimento dell'ordine, importo, valuta e stato del pagamento con l'ordine salvato.
• Evada l'ordine solo quando questo controllo conferma paymentStatus: successful. Una risposta HTTP 200 da sola non prova il pagamento.
• Registri l'evasione in modo atomico, così che ritorni ripetuti o controlli di stato ripetuti non possano evadere due volte lo stesso ordine.
• Se la sessione è ancora unpaid o il recupero non riesce, conservi l'ID della sessione e ripeta il controllo con un numero limitato di tentativi. Non crei un'altra sessione perché il primo esito è sconosciuto: una nuova sessione per l'ordine sostituisce quella vecchia. I webhook non sono ancora disponibili, quindi esegua la riconciliazione tramite polling.

Ripetere le richieste in sicurezza

• Salvi una idempotency key univoca insieme all'ordine prima di creare una sessione. Se una richiesta va in timeout o la sua risposta va persa, la ripeta con la stessa chiave e un corpo invariato.
• Non generi una nuova chiave per un esito incerto. Le regole di ripetizione sono descritte in Idempotenza ed errori.

Limitare le origini di reindirizzamento

• Aggiunga a Allowed websites nelle impostazioni di Checkout solo le origini dei Suoi negozi.
• Usi HTTPS per i negozi pubblicati online. Le sostituzioni di successUrl e cancelUrl per singola sessione devono comunque corrispondere a un'origine configurata.

Segnalare un problema di sicurezza

Se sospetta una vulnerabilità o un incidente di sicurezza, contatti il team di sicurezza come descritto in Contatti.