*[Canvis al SAQ A per a comerç electrònic (PCI SSC)](https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a)
*[Role-based access control (Wikipedia)](https://en.wikipedia.org/wiki/Role-based_access_control)
*[Please, stop using local storage](https://www.rdegges.com/2018/please-stop-using-local-storage/)
*[HTTP headers for the responsible developer](https://www.twilio.com/blog/a-http-headers-for-the-responsible-developer)
Changes for src/m9/uf1s/tecnologies.md: 21 added lines, 9 removed lines.
Original line number
Diff line number
Diff line
@@ -233,19 +233,31 @@ La tria anterior és independent d'una segona: **quins mètodes de pagament acce
Un cas a part és el de les **plataformes i marketplaces**, on cobres en nom de venedors tercers. Això no és una integració de pagament normal: cal repartir cada cobrament, identificar cada venedor i complir obligacions que abans no tenies. Els proveïdors hi tenen productes específics, i és una decisió d'arquitectura que s'ha de prendre al principi, no quan ja factures.
### Abast de PCI DSS
### Com integres el pagament
**PCI DSS** (Payment Card Industry Data Security Standard) és l'estàndard que les marques de targetes imposen a qui tracta dades de targeta. La versió vigent és la 4.0.1, i els requisits que durant un temps van tenir data d'aplicació ajornada són obligatoris des del 31 de març de 2025. No és una llei, és una obligació contractual amb el teu proveïdor de pagament, i incomplir-la té conseqüències econòmiques directes.
La decisió tècnica és quina part del cobrament passa pel teu sistema, i té tres respostes:
El que decideixes en triar com integrar el pagament és l'**abast** (scope): quina part del teu sistema queda sotmesa a l'estàndard. Si el número de targeta (PAN) no toca mai ni el teu servidor ni el teu JavaScript, l'abast es redueix al mínim i el qüestionari d'autoavaluació que et correspon és el més curt (SAQ A). En el moment que el PAN passa per una variable del teu codi, tot el sistema que l'envolta hi entra.
| Integració | Control de la interfície | Abast PCI | Qui veu el PAN |
| Integració | Control de la interfície | Qui veu el PAN | Abast PCI |
| --- | --- | --- | --- |
| Redirecció a la pàgina del proveïdor | Cap: la pantalla és seva | Mínim | Només el proveïdor |
| Camps allotjats o iframe del proveïdor | Alt: el formulari sembla teu | Mínim, amb condicions sobre la pàgina que l'allotja | Només el proveïdor |
| API directa des del teu servidor | Total | Màxim, amb auditoria completa | El teu sistema |
| Redirecció a la pàgina del proveïdor | Cap: la pantalla és seva | Només el proveïdor | Mínim |
| Camps allotjats o iframe del proveïdor | Alt: el formulari sembla teu | Només el proveïdor | Mínim, amb condicions sobre la pàgina que l'allotja |
| API directa des del teu servidor | Total | El teu sistema | Màxim, amb auditoria completa |
L'última columna és **PCI DSS** (Payment Card Industry Data Security Standard), l'estàndard que les marques de targetes imposen a qui tracta dades de targeta. No és una llei sinó una obligació contractual amb el teu proveïdor, i el que en decideixes amb la integració és l'**abast** (scope): quina part del teu sistema hi queda sotmesa. Si el número (PAN) no toca mai ni el teu servidor ni el teu JavaScript, l'abast es redueix al mínim; en el moment que passa per una variable del teu codi, hi entra tot el que l'envolta.
Per això la tercera fila només té sentit per a organitzacions que ja viuen dins de PCI DSS. Per a la resta la decisió raonable és una de les dues primeres, i la diferència entre elles és d'experiència d'usuari, no de seguretat.
Amb l'iframe, això sí, la pàgina que l'allotja continua sent responsabilitat teva: un script de tercers compromès pot capturar el que l'usuari escriu abans que arribi al camp del proveïdor, que és el que fan els atacs de tipus **Magecart**. Aquí tornen a valer la CSP, l'[SRI](#subresource-integrity) i l'auditoria dels [scripts de tercers](#third-party-scripts).
De l'estàndard, com a desenvolupador, només te'n caldrà una part petita: saber que la integració fixa l'abast i poder respondre si la targeta toca algun sistema vostre, no desar mai el CVV ni deixar que el PAN acabi en un log, un correu o un tiquet de suport, i mantenir sota control els scripts de la pàgina de pagament. Aquest últim punt és el que et tocarà de prop: des del 31 de març de 2025, els requisits específics de seguretat de la pàgina de pagament van sortir del qüestionari més curt, i al seu lloc hi va entrar la condició de confirmar que el web no és vulnerable a atacs mitjançant scripts. Qui pot respondre això no és qui signa el qüestionari, és qui manté la pàgina.
### L'API te la imposa el proveïdor
Tot això et diu com triar, però no com programar-ho, i convé no confondre les dues coses. **No hi ha cap protocol estàndard de pagament que puguis implementar**: cada banc i cada passarel·la publiquen la seva pròpia API i tu t'hi adaptes.
El que et ve imposat és pràcticament tot el detall: el format de la petició, l'esquema de signatura amb què demostres que la comanda ve de tu, el catàleg de codis de resposta, les URL de retorn i el format de la notificació posterior. El TPV virtual d'un banc espanyol, per exemple, espera un formulari amb els paràmetres de la comanda signats amb la teva clau de comerç, i respon tornant el navegador a les teves URL d'acceptació i de rebuig. Una passarel·la com Stripe espera que creïs un objecte de pagament des del seu SDK i que escoltis els seus esdeveniments. No són el mateix, i cap de les dues et deixa triar com vols que sigui.
La tercera fila només té sentit per a organitzacions que ja viuen dins de PCI DSS. Per a la resta, la decisió raonable és una de les dues primeres, i la diferència entre elles és d'experiència d'usuari, no de seguretat. Si tries l'iframe, la pàgina que l'allotja continua sent responsabilitat teva: un script de tercers compromès en aquella pàgina pot capturar el que l'usuari escriu abans que arribi al camp del proveïdor, que és exactament el que fan els atacs de tipus **Magecart**. Aquí és on tornen a valer la CSP, l'[SRI](#subresource-integrity) i l'auditoria dels [scripts de tercers](#third-party-scripts).
La conseqüència pràctica és que la documentació del proveïdor serà la teva feina real, i que canviar de proveïdor vol dir reescriure la integració. El que sí que viatja d'un a l'altre són els conceptes d'aquesta secció: si saps què és una redirecció, un camp allotjat, un testimoni, una confirmació asíncrona i una operació idempotent, la documentació nova és qüestió d'aprendre com en diuen ells. Si no els saps, cada proveïdor sembla un món.
