Maksujen turvallisuus ja testaus

Sisäänrakennetut suojaukset

• Korkean entropian pääsyavain vain palvelimelta palvelimelle tehtäviin kutsuihin sekä erillinen maksuoikeus.
• Kestävä aikomus ennen ulkoista alkua.
• Profiili, edunsaaja, käsite, summa ja instituutio on asetettu ja vahvistettu palvelimen toimesta.
• Arkaluontoinen tila on salattu; widgetin token on sidottu yritykseen, maksuaikomukseen, vanhenemisaikaan ja alkuperään, ja se säilytetään vain tiivisteenä.
• Deterministiset aloitusyritysten tunnisteet ja fencing estävät automaattisen uudelleenaloituksen epäselvän tuloksen jälkeen.
• Omistettu takaisinsoitto, kertakäyttö, optimistinen versio ja vuokrasopimuksen hallinta.
• Sensuroitu tarkastus: ei koskaan sisällä pääsyavaimia, täydellistä IBAN , IP-osoitetta, takaisinsoittoja, täydellisiä vastauksia tai sisäistä läpinäkymätöntä tilaa.
• Nimenomaisesti sallitut kohteet ja uudelleenohjaukset, HTTPS, maksimiajat ja rajoitetut vastaukset.
• Widget-viestintä tarkalla alkuperällä, event.source validointi ja versioitu skeema.

Integroi hiekkalaatikko

Kysy Wealth Reader:

1. yksityinen pääsykoodi, joka on valtuutettu maksuihin ja vaadittuun profiiliin;
2. tarkka HTTPS lähde, joka isännöi widgettiä;
3. sovitut määrät ja taajuusrajoitukset;
4. Pääsy hiekkalaatikkotilaan, joka ei siirrä rahaa.

Tee aina kysely päätepisteeseen profile-institutions; hiekkalaatikossa se palauttaa vain simuloidun instituution. Luo aikomus expected_mode: "mock" :llä ja varmista, että vastauksen vahvistus osoittaa myös mock ennen token toimittamista selaimelle.

Kokeile ainakin:

• luomisen toisto samalla avaimella ja ristiriita toisen kappaleen kanssa;
• muutettu pankki tai toimintatila;
• token vanhentunut eikä alkuperä ole sallittu;
• ponnahdusikkuna lukittu ja palaa SCA;
• odottaen välivaiheen statusta, sovittamista ja widgetin sulkemista;
• Vahvistus vasta vastaanoton jälkeen payment_status: settled.

Pyydä oikeaa aktivointia

Ennen käteistestiä varmista Wealth Reader:

• että pankki esiintyy esikonsultaatiossa pääsykoodinsa osalta;
• että profiili ja sen versio hyväksytään;
• että alkuperä, callback ja virtaus on SCA validoitu päästä päähän;
• että määrälle, tiheydelle, sovitukselle ja hätäpoistolle on rajoituksia;
• että on olemassa valtuutettu henkilö, joka vastaa vähimmäistestistä.

Lähdetili voidaan vaatia laitokselle, ja tällöin widget pyytää sitä valtuutuksen yhteydessä. Käyttäjän verkkoosoite johdetaan APIkontrolloidulta rajalta; asiakas ei saa toimittaa sitä. Kyseiset tiedot tai velallisen IBAN eivät paljastu tapahtumissa.

Sekvenssi curl valmistelee ja kysyy aikomuksen, mutta ei suorita pankin tunnistautumista. Käyttäjän on jatkettava pankkiselaimessa tai sovelluksessa.

Profiilin aktivointi edellyttää kolmea toisistaan riippumatonta, täsmällistä käyttöönottoasetusta: WR_PAYMENTS_CRUZ_ROJA_PROFILE_ENABLED=1, WR_PAYMENTS_CRUZ_ROJA_PROFILE_VERSION=2026-09-04 ja sitä, että pääsyavaimeen liitetty yritys sisältyy luetteloon WR_PAYMENTS_CRUZ_ROJA_COMPANY_IDS. Nämä asetukset eivät korvaa maksuoikeutta eivätkä yksin aktivoi todellista pankkia.

Tällä hetkellä julkaistu sopimus merkitsee psuIp käyttämättömäksi, mutta liittimen historialliset testit vaativat sen. Wealth Reader pitää aktivoinnin lukittuna, kunnes kohde-käyttöönotto on vahvistettu hyväksytyn end-to-end- ja option-testin kautta, sekä tarkka kenttä että luotettu proxy-politiikka. Sitä ei tulisi aktivoida mielivaltaisilla välitettyjen otsikoiden avulla tai olettaen, että julkaistu lauseke heijastaa historiallista käyttäytymistä.

Yksityinen DNS-ratkaisu ja TLS-päättäminen sisäiseen palveluun riippuvat jokaisesta käyttöönotosta: tämä SDK ei oleta, että ne ovat olemassa tai saavutettavissa. Ne on tarkistettava API:n suoritusympäristöstä ennen ulospäin suuntautuvien yhteyksien sallimista tai uusien maksuaikomusten hyväksymistä.

Mitä ei kannata tehdä

• Lähetä API -avain, koko edunsaaja tai sisäinen data selaimeen.
• Instituution keksiminen, jota esikonsultaatio ei palauttanut.
• Toista automaattisesti epäselvä aloitus.
• Kirjaa IBAN, verkkoosoite, callback tai koko pankkivastaus.
• Tulkitse vuorovaikutuksen loppu maksun lopulliseksi toteutumiseksi.
• Käytä pankkien aggregointireittejä, tokeneita tai takaisinsoittoja.