Plăți
Securitatea și testarea plăților
Integrează mai întâi sandbox-ul. Publicarea unei instituții reale necesită configurare privată, conectivitate validată, limite operaționale și un test aprobat end-to-end.
Controale incluse
- Credențiale cu entropie ridicată, doar de la un server la altul și permisiunea de plată separată.
- Intenție de durată înainte de orice debut extern.
- Profil, beneficiar, concept, sumă și instituție stabilite și validate de server.
- Starea criptată și sensibilă; token de widget legat de companie, intenție, expirare și origine, păstrate doar ca hash.
- Identificatori determiniști ai încercărilor și fencing pentru a preveni o repornire automată după un rezultat ambiguu.
- Callback dedicat, consum unic, versiune optimistă și control al leasingului.
- Audit cu datele sensibile eliminate: nu include niciodată cheile de acces, IBAN complet, IP, callback-uri, răspunsuri complete sau statut opac.
- Au permis explicit destinațiile și redirecționările, cu HTTPS, timpi maxim și răspunsuri limitate.
- Mesagerie widget cu originea exactă, validarea
event.sourceși schema versionată.
Integrează sandbox-ul
Întreabă Wealth Reader:
- un cod de acces privat autorizat pentru plăți și pentru profilul necesar;
- sursa exactă HTTPS care va găzdui widget-ul;
- limitele convenite de cantitate și frecvență;
- Acces la modul sandbox, care nu mută bani.
Interoghează întotdeauna profile-institutions; în sandbox va returna doar o instituție simulată. Creează intenția cu expected_mode: "mock" și verifică că atestarea răspunsului indică și mock înainte de a livra token browserului.
Încearcă măcar:
- repetarea creației cu aceeași cheie și conflict cu un alt corp;
- instituție sau manieră modificată;
- token expirat și originea nu este permisă;
- popup blocat și returnare SCA;
- starea intermediară în așteptare, reconcilierea și închiderea widgetului;
- Confirmarea doar la primirea
payment_status: settled.
Solicită activare reală
Înainte de un test de numerar, confirmă cu Wealth Reader:
- că instituția apare în pre-consultarea pentru codul său de acces;
- ca profilul și versiunea sa să fie aprobate;
- că originea, callback și fluxul SCA erau validate de la un capăt la altul;
- că există limite privind cantitatea, frecvența, reconcilierea și dezactivarea de urgență;
- că există un om autorizat responsabil pentru testul minim.
Contul sursă poate fi necesar pentru o instituție, iar în acest caz, este solicitat de widget în timpul autorizării. Adresa de rețea a utilizatorului este derivată la granița controlată a API; clientul nu ar trebui să o trimită. Nici aceste date, nici IBAN debitorului nu sunt expuse în evenimente.
Secvența cu curl pregătește și interoghează intenția, dar nu finalizează autentificarea bancară. Utilizatorul trebuie să continue în browserul bancar sau în aplicație.
Activarea profilului necesită trei controale independente și exacte de implementare: WR_PAYMENTS_CRUZ_ROJA_PROFILE_ENABLED=1, WR_PAYMENTS_CRUZ_ROJA_PROFILE_VERSION=2026-09-04 și includerea companiei asociate cheii de acces în WR_PAYMENTS_CRUZ_ROJA_COMPANY_IDS. Aceste valori nu înlocuiesc permisiunea de plată și nici nu permit o instituție reală de unul singur.
Mărcile contractuale publicate în prezent psuIp ca neutilizate, dar testele istorice ale conectorului au impus acest lucru. Wealth Reader menține activarea blocată până când implementarea țintă este verificată, prin un test end-to-end și de opțiuni aprobat, atât câmpul exact, cât și politica proxy de încredere. Nu ar trebui activat folosind antete redirecționate arbitrare sau presupunând că declarația publicată reflectă comportamentul istoric.
Rezoluția DNS privată și terminarea TLS către serviciul intern depind de fiecare implementare: acest SDK nu presupune că acestea există sau sunt realizabile. Ele trebuie verificate din timpul de execuție API înainte de a activa ieșirea sau de a accepta noi intenții.
Ce să nu faci
- Trimite cheia API , beneficiarul complet sau datele interne către browser.
- Inventarea unei instituții care nu a fost returnată de pre-consultare.
- Repetă automat un start ambiguu.
- Înregistrează IBAN, adresa de rețea, callback sau răspunsul complet al băncii.
- Interpretează sfârșitul interacțiunii ca lichidare.
- Reutilizați rutele de agregare bancară, token-urile sau callback-urile.