# PCI-vaatimustenmukaisuus sovelluskehittäjille: Lyhyt ja tuskallinen versio

> Published: 2026-07-28
> Updated: 2026-07-28
> Author: Mathias Nielsen
> Category: POS
> Canonical: https://finalpos.com/fi/blog/pci-vaatimustenmukaisuus-sovelluskehittajille-lyhyt-ja-tuskallinen-versio

Jos korttitiedot koskettavat koskaan kirjoittamaasi koodia, saat kontollesi PCI DSS -standardin koko painon. Tässä on eskalaatioasteikko SAQ A:sta SAQ D:hen, miksi lähi- ja korttimaksut vaativat sertifioitua laitteistoa ja miten rakennat sovelluksesi niin, ettei mikään tästä lankea sinulle.

PCI-vaatimustenmukaisuus (maksukorttialan turvallisuussäännöt kaikille korttitietoja käsitteleville) on sanojen ”hyväksyy luottokortteja” hinta. Lyhyt versio: jos korttitiedot koskettavat koskaan kirjoittamaasi koodia tai pyörittämiäsi palvelimia, saat kontollesi tietoturvastandardin satoine vaatimuksineen, vuotuisen vaatimustenmukaisuusvakuutuksen (virallisen allekirjoitetun ilmoituksen siitä, että täytät standardin) sekä seuraukset, jotka kulkevat maksunvälittäjäsi kautta. Tuskallinen versio sovelluskehittäjien PCI-vaatimustenmukaisuudesta: useimmat tajuavat tämän vasta, kun kassa on jo rakennettu.

Yksi huomio ennen yksityiskohtia. Alla olevat versionumerot, päivämäärät ja kyselysäännöt ovat tarkkoja julkaisuhetkellä; standardi muuttuu, joten suhtaudu yksityiskohtiin tilannekatsauksena.

## Mitä PCI-vaatimustenmukaisuus tosiasiassa on?

PCI DSS (Payment Card Industry Data Security Standard) on sopimuksellinen velvoite, ei laki. Korttiyhtiöt edellyttävät sitä pankeilta ja maksunvälittäjiltä, ja nämä edellyttävät sitä kauppiailta sekä näiden käyttämiltä ohjelmistoilta. Nykyinen versio on 4.0.1, ja sen uusin vaatimusaalto tuli pakolliseksi 31. maaliskuuta 2025[¹](https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a). Standardi kattaa 12 vaatimusluokkaa verkkoturvallisuudesta ja kryptauksesta pääsynhallintaan ja lokitukseen, ja ne jakautuvat satoihin yksittäisiin kontrollikohtiin[²](https://secureframe.com/blog/pci-saq).

Yksikään viranomainen ei tule ovellesi. Seuraukset ovat sen sijaan kaupallisia: sakkoja lunastajapankkisi kautta (pankki, joka tilityttää korttimaksut kauppiaalle), korkeampia välityspalkkioita ja pahimmassa tapauksessa korttimaksujen vastaanotto-oikeuden menettäminen. Tietomurron sattuessa tutkinta- ja korttien uudelleenjulkaisukustannukset kulkevat samaa reittiä.

## Miksi pelkkä ”maksujen lisääminen” tuo koko sovelluksesi PCI-soveltamisalaan?

Soveltamisala (scope) on koko pelin ydin. PCI DSS koskee jokaista järjestelmää, joka tallentaa, käsittelee tai välittää korthaltijan tietoja, sekä kaikkea näihin järjestelmiin kytkettyä. Vaatimustenmukaisuuden osoittaminen toimii kuin tikapuut, ja jokainen puola on huomattavasti edellistä raskaampi[²](https://secureframe.com/blog/pci-saq):

- **SAQ A** (itsearviointikysely A): maksut on ulkoistettu kokonaan vaatimukset täyttävälle palveluntarjoajalle, eikä korttitietoja koskaan päädy järjestelmiisi. Lyhin kyselylomake.
- **SAQ A-EP**: sivustosi ei koskaan käsittele korttitietoja, mutta se hallitsee sitä, miten asiakkaat päätyvät maksulomakkeelle. Suuri osa koko standardista koskee nyt verkkopalvelimiasi.
- **SAQ D**: korttitiedot kulkevat minkä tahansa rakentamasi osan läpi, edes hetkellisesti tai tallentumatta. Käytännössä koko standardi, joka on dokumentoitava ja vahvistettava vuosittain.

![Pino vaatimustenmukaisuusasiakirjoja ja luottokortti päällä kuvaamassa PCI DSS -itsearviointikyselyitä](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/0c4ed4b3d666d99c-pci-saq-paperwork-stack.png)

Alin puolakaan ei ole ”ei mitään”. Tammikuussa 2025 PCI Security Standards Council poisti maksusivun skriptivaatimukset SAQ A:sta, mutta lisäsi kelpoisuusehdon: sinun on vahvistettava, että sivustosi ei ole altis skriptihyökkäyksille, jotka voisivat vaikuttaa verkkokauppajärjestelmääsi[¹](https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a). Jopa täysin ulkoistettu taso edellyttää sinun suojaavan sivun, joka isännöi jonkun muun maksulomaketta.

Kun myymälä ylittää kuusi miljoonaa korttimaksutapahtumaa vuodessa, itsearviointi päättyy kokonaan ja sertifioidun ulkoisen arvioijan (QSA) tekemä paikan päällä tapahtuva auditointi alkaa[²](https://secureframe.com/blog/pci-saq).

## Voitko kiertää lähimaksatuksen ja korttimaksun laitevaatimukset koodaamalla?

Et. Paikan päällä tehtävissä maksuissa tikapuut muuttuvat seinäksi. Korttimaksut edellyttävät sertifioitua laitteistoa: fyysisiä lukijoita, jotka ovat läpäisseet neuvoston [PTS-laboratorio-ohjelman](https://www.pcisecuritystandards.org/standards/pts-point-of-interaction-poi/), ajavat hyväksyttyä laiteohjelmistoa ja jotka on alustettu maksunvälittäjän kautta. Puhelimen muuttaminen lukijaksi pelkällä ohjelmistolla kuuluu erillisen standardin, [Mobile Payments on COTS (MPoC)](https://www.pcisecuritystandards.org/standards/mobile-payments-on-cots-mpoc/), piiriin, ja se sertifioi ratkaisuntarjoajan, ei sinun toteutustasi.

![Brändäämätön sertifioitu maksupääte myymälän tiskillä, laitteistotaso jonka PCI vaatii korttimaksuille](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/0d02d9e5e5229253-certified-payment-terminal-counter.jpg)

Tämä on raja, jota tekoälyn koodinkehitys ei voi ylittää. Malli voi luoda vakuuttavan kassanäkymän iltapäivässä; [Voiko POS-järjestelmän rakentaa Lovablella tai Replitillä?](/blog/build-a-pos-with-lovable-or-replit) ja [Kassan vibe-koodaus](/blog/vibe-coding-a-point-of-sale) näyttävät, mihin nämä toteutukset pysähtyvät. Mikään generoitu koodi ei tuota sertifioitua lukijaa, kauppiaasopimusta tai vaatimustenmukaisuusvakuutusta, riippumatta siitä [kuinka kauan malli koodaa ilman valvontaa](/blog/claude-opus-5-pos-more-than-code). Vaatimustenmukaisuus on myös yleinen syy sille, miksi [vibe-koodatut maksusovellukset hylätään App Storessa](/blog/why-vibe-coded-payment-apps-get-rejected).

## Miten kehittäjät voivat tosiasiassa pienentää PCI-soveltamisalaa?

Et yritä täyttää vaatimuksia entistä ankarammin, vaan suunnittelet arkkitehtuurin niin, että noudatettavaa on vähemmän:

- Älä koskaan päästä PAN-numeroa (ensisijainen tilinumero eli itse korttinumero) koskettamaan koodiasi. Käytä maksunvälittäjän isännöimiä maksukenttiä, jotta korttitiedot siirtyvät asiakkaan selaimesta suoraan maksunvälittäjälle.
- Tallenna tokeneita, älä kortteja. Tokenisointi (korttinumeron korvaaminen viitemerkkijonolla, joka on varastettuna hyödytön) estää tallennettuja kortteja ja palautuksia vetämästä tietokantaasi soveltamisalaan.
- Käytä paikan päällä tapahtuvassa myynnissä maksunvälittäjäsi sertifioimia lukijoita, jotta korttitiedot virtaavat lukijalta maksunvälittäjälle kulkematta sovelluksesi kautta.
- Pidä maksusivu yksinkertaisena. Jokainen kolmannen osapuolen skripti sivulla on asia, joka sinun on otettava huomioon.

![Lasikoteloon suljettu luottokortti symboloimassa korttitietojen pitämistä PCI-soveltamisalan ulkopuolella](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/2630089c92683ed9-card-data-out-of-scope-glass-case.jpg)

Oikein tehtynä sovelluksesi orkestroi myynnin ilman, että sillä on hallussaan korttitietoja, ja kyselylomake pysyy lyhyenä. Väärin tehtynä yksi kätevyystoiminto (”kirjataan vain koko pyyntörunko lokiin”) siirtää sinut huomaamatta SAQ D -tasolle.

## Siispä, kuinka tuskallista PCI-vaatimustenmukaisuus on sovelluskehittäjille?

Tuskallisuus on suhteessa siihen, kuinka paljon korttitietoja koodisi käsittelee, minkä vuoksi voittava siirto on olla käsittelemättä niitä lainkaan. Standardi ei välitä siitä, kirjoittiko sovelluksesi kehitystiimi vai generoiko tekoäly sen iltapäivässä; soveltamisala on soveltamisala. Ennen kuin julkaiset mitään korttimaksuja vastaanottavaa, kysy yksi kysymys: voiko korttinumero koskaan kulkea kirjoittamani koodin läpi? Jos kyllä, varaa budjettia auditointiin. Jos ei, pidä se sellaisena.

Tämä arkkitehtuuri on myös se, miten Final hoitaa asian. Final-alustalle rakennettu kassa, riippumatta siitä onko se luotu kehotteella Build-osiossa vai oman tekoälysi rakentama MCP-rajapinnan kautta, ajaa maksunsa Final Payn läpi: maksunvälittäjä ja sertifioitu maksupäätelaitteisto käsittelevät korttitiedot, joten itse kululla ei ole koskaan korttinumeroa hallussaan. [Missä Final Pay on saatavilla](https://finalpos.com/help/where-final-pay-is-available) käsittelee käytännön puolen, ja [Tap to Pay -lähimaksun yhdistäminen tekoälypohjaiseen POS-kulkuun](/blog/connecting-tap-to-pay-to-an-ai-pos-flow) näyttää, miltä korttien vastaanottaminen näyttää, kun vaatimustenmukaisuustaso on jo valmiina pohjalla.

## FAQ

**Q: Onko PCI-vaatimustenmukaisuus lakisääteinen vaatimus?**
A: Ei. PCI DSS on sopimuksellinen velvoite, jonka korttiyhtiöt asettavat pankkien ja maksunvälittäjien kautta. Seuraukset ovat kaupallisia: sakkoja lunastajapankkisi kautta, korkeampia välityspalkkioita tai korttien vastaanotto-oikeuden menettäminen.

**Q: Poistaako maksujen täydellinen ulkoistaminen PCI-velvoitteet?**
A: Ei. Maksut täysin ulkoistaneet kauppiaat voivat osoittaa vaatimustenmukaisuuden SAQ A -kyselyllä (lyhin kyselylomake), mutta tammikuun 2025 päivityksestä lähtien heidän on myös vahvistettava, ettei heidän sivustonsa ole altis skriptihyökkäyksille, jotka voisivat vaikuttaa verkkokauppajärjestelmään.

**Q: Mitä eroa on SAQ A:lla ja SAQ D:llä?**
A: SAQ A koskee tilannetta, jossa vaatimukset täyttävä kolmas osapuoli käsittelee kaikki korttitiedot, ja se kattaa pienen osan standardista. SAQ D koskee tilannetta, jossa korttitiedot koskettavat omia järjestelmiäsi, ja se kattaa käytännössä koko standardin vuosittain vahvistettuna.

**Q: Voiko tekoälyn generoima sovellus olla PCI-yhteensopiva?**
A: Koodi voi noudattaa turvallisia toimintamalleja, mutta vaatimustenmukaisuus liittyy yritykseen ja sen infrastruktuuriin: sertifioituihin kortinlukijoihin, maksunvälittäjäsopimukseen ja vuotuiseen vaatimustenmukaisuusvakuutukseen. Mikään generoitu koodi ei tarjoa näitä osia.

**Q: Mikä PCI DSS -versio on nykyisin voimassa?**
A: PCI DSS 4.0.1 tämän artikkelin julkaisuhetkellä. Sen viimeiset myöhemmin voimaan tuleviksi määritellyt vaatimukset tulivat pakollisiksi 31. maaliskuuta 2025. Tarkista nykyinen tilanne PCI Security Standards Councilin sivustolta.