Betalingssikkerhed og bevis

Kontroller inkluderet

• Høj-entropi legitimation kun server-til-server og separat betalingstilladelse.
• Varig intention før enhver ekstern indtræden.
• Profil, begunstiget, koncept, beløb og institution er sat og valideret af serveren.
• Krypteret følsom tilstand; token af widget knyttet til selskab, hensigt, udløb og oprindelse, bevaret kun som hash.
• Deterministiske forsøgsidentifikatorer og hegn for at forhindre en automatisk genstart efter et tvetydig resultat.
• Dedikeret callback, enkeltforbrug, optimistisk version og leasingkontrol.
• Redigeret revision: inkluderer aldrig adgangsnøgler, fuld IBAN , IP, tilbagekald, fulde svar eller uigennemsigtig status.
• Eksplicit tilladte destinationer og omdirigeringer, med HTTPS, maksimale tider og begrænsede svar.
• Widget-beskeder med præcis oprindelse, event.source validering og versioneret skema.

Integrer sandkassen

Spørg Wealth Reader:

1. en privat adgangskode autoriseret til betalinger og til den krævede profil;
2. den præcise HTTPS kilde, der skal hoste widgetten;
3. de aftalte mængder og frekvensgrænser;
4. Adgang til sandbox-tilstand, som ikke flytter penge.

Sæt altid kryds profile-institutions; i sandbox vil den kun returnere en simuleret institution. Opret intentionen med expected_mode: "mock" og verificer, at attestationen af svaret også indikerer mock , før token leveres til browseren.

Prøv i det mindste:

• gentagelse af skabelsen med samme toneart og konflikt med en anden krop;
• ændret institution eller måde;
• token udløbet, og oprindelse ikke tilladt;
• popup låst og returner SCA;
• afventende mellemliggende status, afstemning og lukning af widgetten;
• Bekræftelse kun ved modtagelse payment_status: settled.

Anmod om reel aktivering

Før en kontanttest, bekræft med Wealth Reader:

• at institutionen fremgår af forhåndskonsultationen for sin adgangskode;
• at profilen og dens version godkendes;
• at oprindelsen, callback og strømmen SCA blev valideret fra ende til anden;
• at der er grænser for mængde, hyppighed, afstemning og nøddeaktivering;
• at der er en autoriseret person ansvarlig for minimumstesten.

Kildekontoen kan være påkrævet af en institution, og i så fald anmodes widgetten om den under autorisationen. Brugerens netværksadresse udledes ved den kontrollerede grænse af API; kunden bør ikke indsende den. Hverken disse data eller debitorens IBAN eksponeres i begivenheder.

Sekvensen med curl forbereder og forespørger hensigten, men fuldfører ikke bankgodkendelse. Brugeren skal fortsætte i bankbrowseren eller -appen.

Profilaktivering kræver tre uafhængige og præcise implementeringskontroller: WR_PAYMENTS_CRUZ_ROJA_PROFILE_ENABLED=1, WR_PAYMENTS_CRUZ_ROJA_PROFILE_VERSION=2026-09-04 og selskabet af adgangsnøglen, der er inkluderet i WR_PAYMENTS_CRUZ_ROJA_COMPANY_IDS. Disse værdier erstatter ikke betalingstilladelsen eller muliggør en reel institution alene.

Den aktentligt offentliggjorte kontrakt markerer psuIp som ubrugt, men historiske tests af connectoren krævede det. Wealth Reader holder aktiveringen låst, indtil målimplementeringen er verificeret, gennem en godkendt end-to-end og optionstest, både det præcise felt og den betroede proxy-politik. Den bør ikke aktiveres ved hjælp af vilkårlige videresendte headers eller antagelse, at den offentliggjorte erklæring afspejler historisk adfærd.

Privat DNS-opløsning og TLS-terminering til den interne tjeneste afhænger af hver enkelt implementering: dette SDK antager ikke, at de eksisterer eller er opnåelige. De skal verificeres fra API runtime, før output aktiveres eller nye intentioner accepteres.

Hvad man ikke skal gøre

• Send API -nøglen, den fulde begunstigede eller interne data til browseren.
• At opfinde en institution, som ikke blev gengivet af forhåndskonsultationen.
• Gentag automatisk en tvetydig start.
• Optag IBAN, netværksadresse, callback eller fuld bankrespons.
• Tolk afslutningen på interaktionen som likvidation.
• Genbrug bankaggregationsruter, tokens eller callbacks.