Sicurezza e test dei pagamenti

Controlli inclusi

• Credenziale ad alta entropia, utilizzata solo da server a server, e autorizzazione ai pagamenti separata.
• Intenzione persistita prima di qualsiasi avvio esterno del pagamento.
• Profilo, beneficiario, concetto, importo e istituzione stabiliti e convalidati dal server.
• Stato sensibile criptato; token di widget legato a società, intento, scadenza e origine, preservato solo come hash.
• Identificatori deterministici dei tentativi e fencing per prevenire un riavvio automatico dopo un risultato ambiguo.
• Callback dedicato, consumo singolo, versione ottimista e controllo del leasing.
• Audit oscurato: non include mai chiavi di accesso, IBAN piena, IP, richiami, risposte complete o stato opaco.
• Esplicitamente permessi destinazioni e reindirizzamenti, con HTTPS, tempi massimi e risposte limitate.
• Messaggistica widget con origine esatta, validazione event.source e schema versionato.

Integra il sandbox

Chiedi Wealth Reader:

1. un codice di accesso privato autorizzato per i pagamenti e per il profilo richiesto;
2. la sorgente esatta HTTPS che ospiterà il widget;
3. i limiti concordati di quantità e frequenza;
4. Accesso alla modalità sandbox, che non sposta soldi.

Interroga sempre profile-institutions; in Sandbox restituirà solo un'istituzione simulata. Crea l'intento con expected_mode: "mock" e verifica che anche l'attestazione della risposta indichi mock prima di consegnare il token al browser.

Prova almeno:

• ripetizione della creazione con la stessa chiave e conflitto con un altro corpo;
• istituzione o modo alterato;
• token scaduta e l'origine non consentita;
• popup bloccato e ritorno SCA;
• stato intermedio in attesa, riconciliazione e chiusura del widget;
• Conferma solo al ricevimento payment_status: settled.

Richiedi attivazione reale

Prima di un test di cassa, conferma con Wealth Reader:

• che l'istituzione compaia nella pre-consultazione per il suo codice di accesso;
• che il profilo e la sua versione siano approvati;
• che origine, callback e flusso SCA venivano validati da un capo all'altro;
• che ci sono limiti su quantità, frequenza, riconciliazione e disattivazione d'emergenza;
• che esiste un essere umano autorizzato responsabile del test minimo.

L'account sorgente può essere richiesto per un'istituzione e, in tal caso, viene richiesto dal widget durante l'autorizzazione. L'indirizzo di rete dell'utente viene ricavato al confine controllato del API; il cliente non deve inviarlo. Né quei dati né la IBAN del debitore vengono esposti negli eventi.

La sequenza con curl prepara e interroga l'intento, ma non completa l'autenticazione bancaria. L'utente deve continuare nel browser o nell'app bancaria.

L'attivazione del profilo richiede tre controlli di distribuzione indipendenti ed esatti: WR_PAYMENTS_CRUZ_ROJA_PROFILE_ENABLED=1, WR_PAYMENTS_CRUZ_ROJA_PROFILE_VERSION=2026-09-04 e la società della chiave di accesso inclusa in WR_PAYMENTS_CRUZ_ROJA_COMPANY_IDS. Questi valori non sostituiscono il permesso di pagamento né abilitano da soli un istituto reale.

I marchi contrattuali attualmente pubblicati psuIp come non utilizzati, ma i test storici del connettore lo richiedevano. Wealth Reader mantiene l'attivazione bloccata fino a quando il deployment target non viene verificato, tramite un test end-to-end e option approvato, sia il campo esatto che la policy proxy affidabile. Non dovrebbe essere attivato utilizzando intestazioni inoltrate arbitrarie o assumendo che la dichiarazione pubblicata rifletta il comportamento storico.

La risoluzione DNS privata e la terminazione TLS al servizio interno dipendono da ogni deployment: questo SDK non presume che esistano o siano realizzabili. Devono essere verificati dal runtime API prima di abilitare le connessioni in uscita o accettare nuovi intenti.

Cosa non fare

• Invia la chiave API , il beneficiario completo o i dati interni al browser.
• Inventare un'istituzione non restituita dalla pre-consultazione.
• Ripeti automaticamente un inizio ambiguo.
• Registra IBAN, indirizzo di rete, callback o risposta completa della banca.
• Interpreta la fine dell'interazione come liquidazione.
• Riutilizza rotte di aggregazione bancaria, token o callback.