Betalingssikkerhet og testing

Kontroller inkludert

• Høy entropi-legitimasjon kun server-til-server og separat betalingstillatelse.
• Varig intensjon før noen ytre innledning.
• Profil, mottaker, konsept, beløp og institusjon satt opp og validert av serveren.
• Kryptert sensitiv tilstand; token av widget knyttet til selskap, intensjon, utløp og opprinnelse, bevart kun som hash.
• Deterministiske forsøks-ID-er og fencing for å forhindre automatisk omstart etter et tvetydig resultat.
• Dedikert tilbakeringing, enkeltforbruk, optimistisk versjon og leiekontroll.
• Redigert revisjon: inkluderer aldri tilgangsnøkler, full IBAN , IP, tilbakeringinger, fullstendige svar eller ugjennomsiktig leverandørtilstand.
• Eksplisitt tillatte destinasjoner og omdirigeringer, med HTTPS, maksimale tider og begrensede svar.
• Widget-meldinger med eksakt opprinnelse, event.source validering og versjonert skjema.

Integrer sandkassen

Spør Wealth Reader:

1. en privat tilgangskode autorisert for betalinger og for den nødvendige profilen;
2. den eksakte HTTPS kilden som skal være vert for widgeten;
3. de avtalte mengde- og frekvensgrensene;
4. Tilgang til sandkassemodus, som ikke flytter penger.

Sjekk alltid profile-institutions; i sandbox vil den kun returnere en simulert institusjon. Lag intensjonen med expected_mode: "mock" og verifiser at attesteringen av svaret også indikerer mock før token leveres til nettleseren.

Prøv i det minste:

• gjentakelse av skapelsen med samme idempotensnøkkel og konflikt med en annen kropp;
• endret institusjon eller måte;
• token utgått og opprinnelse ikke tillatt;
• popup låst og returner SCA;
• pending intermediate status, avstemming og avslutning av widgeten;
• Bekreftelse kun ved mottak payment_status: settled.

Be om reell aktivering

Før en kontanttest, bekreft med Wealth Reader:

• at institusjonen vises i forhåndshøringen for sin tilgangskode;
• at profilen og dens versjon godkjennes;
• at opprinnelse, callback og flyt SCA ble validert fra ende til annen;
• at det finnes grenser for mengde, hyppighet, avstemming og nøddeaktivering;
• at det finnes en autorisert person ansvarlig for minimumstesten.

Kildekontoen kan være nødvendig for en institusjon, og i så fall blir den forespurt av widgeten under autorisasjon. Brukerens nettverksadresse er utledet ved den kontrollerte grensen til API; kunden skal ikke sende den inn. Verken disse dataene eller skyldnerens IBAN eksponeres i hendelser.

Sekvensen med curl forbereder og spør intensjonen, men fullfører ikke bankautentisering. Brukeren må fortsette i banknettleseren eller appen.

Profilaktivering krever tre uavhengige og nøyaktige distribusjonskontroller: WR_PAYMENTS_CRUZ_ROJA_PROFILE_ENABLED=1, WR_PAYMENTS_CRUZ_ROJA_PROFILE_VERSION=2026-09-04 og selskapet til tilgangsnøkkelen som er inkludert i WR_PAYMENTS_CRUZ_ROJA_COMPANY_IDS. Disse verdiene erstatter ikke betalingstillatelsen eller muliggjør en reell institusjon alene.

Den for øyeblikkelig publiserte kontrakten markerer psuIp som ubrukt, men historiske tester av koblingen krevde det. Wealth Reader holder aktiveringen låst til målutrullingen er verifisert, gjennom godkjent ende-til-ende- og opsjonstest, både det eksakte feltet og den betrodde proxy-policyen. Den skal ikke aktiveres ved hjelp av vilkårlige videresendte headere eller anta at den publiserte uttalelsen gjenspeiler historisk oppførsel.

Oppløsning av privat DNS og TLS-avslutning til den interne tjenesten avhenger av hver enkelt distribusjon: denne SDK-en antar ikke at de eksisterer eller er oppnåelige. De må verifiseres fra API kjøretid før utdata aktiveres eller nye intensjoner kan aksepteres.

Hva man ikke bør gjøre

• Send API -nøkkelen, full begunstiget eller interne data til nettleseren.
• Å finne opp en institusjon som ikke ble returnert av forhåndskonsultasjonen.
• Gjenta automatisk en tvetydig start.
• Registrer IBAN, nettverksadresse, callback eller full bankrespons.
• Tolk slutten på interaksjonen som likvidasjon.
• Gjenbruk bankaggregeringsruter, tokens eller callbacks.