# Sicurezza di Checkout (/it/online/security/checkout_security)



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](/online/integration/hosted_checkout) sia per i [pagamenti incorporati](/online/integration/embedded_checkout).

Per sapere come Tapaya tratta i dati del titolare della carta e i dati personali, consulti [Protezione dei dati e privacy](/compliance/data_protection_and_privacy).

## Conservare le chiavi sul server [#keep-keys-on-the-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](/online/integration/api_integration#authentication).
* 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 [#own-the-order-on-your-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 [#verify-before-you-fulfill]

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 [#retry-safely]

* 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](/online/integration/api_integration#idempotency-and-errors).

## Limitare le origini di reindirizzamento [#restrict-redirect-origins]

* Aggiunga a **Allowed websites** nelle [impostazioni di Checkout](/online/integration/checkout_settings) 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 [#reporting-a-security-issue]

Se sospetta una vulnerabilità o un incidente di sicurezza, contatti il team di sicurezza come descritto in [Contatti](/support/contacts#security-issues).