Sicurezza e custodia delle chiavi, subprocessori di un gateway di pagamento, informativa sulla privacy di un gateway crypto, termini legali per l'accettazione di crypto

Questa traduzione è fornita per comodità. La versione inglese è quella legalmente vincolante.

1. Custodia delle chiavi

Questo è quello importante, quindi leggilo due volte. Per impostazione predefinita, gli indirizzi di ricezione sono derivati da materiali chiave detenuti dall'Operatore, non da te: i pagamenti arrivano agli indirizzi dell'Operatore e vengono accreditati sul tuo saldo, e tu prelevi da lì. La firma non è automatizzata: l'applicazione web non ha un percorso che trasmette un trasferimento da sola; i prelievi e i pagamenti vengono esaminati, firmati e trasmessi dall'Operatore al di fuori di essa. Un commerciante che non vuole che l'Operatore detenga i propri fondi può richiedere la derivazione dal proprio xPub; quindi i pagamenti si stabiliscono solo su indirizzi che quel commerciante controlla, e l'Operatore non ha mai le chiavi di essi.

2. Integrità dell'API e dei webhook

2.1 Firma

Le richieste API e i webhook sono firmati con HMAC-SHA256, con una finestra temporale per limitare il replay, e chiavi di idempotenza in modo che una chiamata ripetuta non agisca due volte. Le firme vengono confrontate in tempo costante.

2.2 Webhook in uscita

I webhook in uscita sono protetti da SSRF: solo https, inviati all'URL configurato dal commerciante, bloccati a un indirizzo IP convalidato, con intervalli privati, CGNAT e NAT64 negati.

3. Credenziali a riposo

Le password sono hashate con bcrypt. L'api_secret è crittografato a riposo con AES-256-GCM. Le chiavi private, le frasi seed e i numeri di carta non vengono mai memorizzati.

4. Sicurezza dell'account

Autenticazione a due fattori TOTP opzionale con codici di recupero. Le sessioni sono tracciate lato server e possono essere revocate. I token CSRF proteggono le richieste che modificano lo stato. Il rate limiting si applica per IP e per chiave.

5. Trasporto e indurimento del browser

HSTS, una Content Security Policy, X-Frame-Options impostato su DENY, X-Content-Type-Options nosniff e una Referrer-Policy.

6. Integrità del denaro

I regolamenti sono registrati in un libro mastro append-only con un ancoraggio di idempotenza UNICO, quindi lo stesso deposito non può essere accreditato due volte. I blocchi di consulenza serializzano le modifiche di saldo, quindi le operazioni concorrenti non possono portare un saldo nello stato sbagliato.

7. Cosa non rivendichiamo

Payora non possiede alcuna certificazione PCI-DSS, SOC 2 o ISO 27001, né licenza da parte di un regolatore. Chiunque ti dica il contrario si sbaglia. Il software fornisce all'Operatore impostazioni predefinite solide; la sicurezza di un'istanza in esecuzione dipende anche dal server, dall'hosting e dalle pratiche dell'Operatore.

8. Il tuo lato

Mantieni segreti il tuo API e la password. Attiva l'autenticazione a due fattori. Verifica le firme dei webhook piuttosto che fidarti del payload. Controlla attentamente gli indirizzi di pagamento, inclusi eventuali tag di destinazione o memo, poiché una transazione inviata non può essere richiamata.

9. Segnalazione di una vulnerabilità

Segnala problemi di sicurezza all'Operatore a support@payora.money. Si prega di fornire dettagli sufficienti per riprodurre, e si prega di non testare contro gli account o i dati di altre persone.

Ultimo aggiornamento: 16 luglio 2026. Se apportiamo modifiche sostanziali a questa pagina, la versione aggiornata sarà pubblicata qui.

Legale

Ogni politica, in un unico posto.

I documenti che governano questa istanza di Payora. Le traduzioni sono fornite per comodità; la versione in inglese è quella legalmente vincolante.

Termini di servizioConti, custodia dei fondi, commissioni e responsabilità.Informativa sulla privacyQuali dati vengono memorizzati, cookie e i tuoi diritti.Politica di utilizzo accettabilePer cosa il servizio non può essere utilizzato e come viene applicato.Informativa sui cookieQuali cookie sono impostati e perché.Accordo sul trattamento dei datiTermini di elaborazione dei dati tra il commerciante e l'Operatore.SubprocessoriOgni terza parte con cui il servizio entra in contatto.Politica di Conservazione dei DatiPer quanto tempo viene conservato ciascun tipo di record.

SicurezzaControlli di sicurezza e come vengono gestite le chiavi.Sei qui

Dichiarazione di RischioI veri rischi di accettare e detenere criptovalute.Rimborsi e ChargebackNessun chargeback e cosa sia realmente un rimborso.

FAQ

Domande frequenti

Risposte dirette, comprese quelle scomode: custodia, commissioni e cosa succede quando qualcosa va storto.

Centro assistenza

Dove sono le chiavi private?

Non sul server. Gli indirizzi di ricezione sono derivati solo da materiale di chiave pubblica, come un xPub, una chiave pubblica master o un pool generato offline, e nessuna chiave di spesa è memorizzata sul server. I pagamenti sono firmati sulla macchina dell'Operatore e trasmessi da lì.

Payora è certificata PCI-DSS, SOC 2 o ISO 27001?

No. Payora non detiene tale certificazione né licenza regolamentare, e non ne rivendica alcuna. Il software fornisce impostazioni predefinite solide, ma la sicurezza di un'istanza in esecuzione dipende anche dal server dell'Operatore, dall'hosting e dalle pratiche.

Come viene impedito che un deposito venga accreditato due volte?

I regolamenti vanno in un libro mastro append-only con un ancoraggio di idempotenza UNICO, quindi lo stesso deposito non può essere accreditato due volte, e i blocchi di consulenza serializzano le modifiche di saldo in modo che le operazioni concorrenti non possano correre il saldo.

Come faccio a sapere se un webhook proviene realmente da Payora?

Verifica la firma HMAC-SHA256 piuttosto che fidarti del payload. Le firme utilizzano una finestra temporale per limitare il replay e le chiavi di idempotenza in modo che un tentativo di ripetizione non agisca due volte e vengano confrontate in tempo costante.