Seguridade dos pagamentos: que non debes gardar nunca e por que se asinan os webhooks

Aceptar tarxetas obriga a cumprir o estándar PCI DSS. A boa noticia é que a maior parte dese cumprimento pódese delegar: se o teu servidor nunca ve un número de tarxeta, case todo o traballo lévao o teu provedor. A mala é que hai dous xeitos doados de estragalo.

Datos que non podes gardar, nin cifrados

O estándar distingue entre datos que se poden almacenar con protección e datos que non se poden almacenar nunca despois de autorizar o pagamento:

• O código de verificación de tres ou catro díxitos do reverso ou do anverso.
• O contido completo da banda magnética ou do chip.
• O PIN ou o seu bloque cifrado.

Cifralos non o arranxa: a prohibición é sobre o almacenamento, non sobre o formato. O número de tarxeta si se pode almacenar baixo condicións estritas, pero a pregunta correcta case sempre é outra: para que o queres? Se é para cobros recorrentes, o que necesitas é un token, non o número.

SAQ A: o obxectivo razoable para case todos

O cuestionario de autoavaliación máis lixeiro, coñecido como SAQ A, está pensado para comercios que externalizan por completo a captura de datos de tarxeta: o formulario sérveo o provedor de pagamento dentro dun iframe ou mediante redirección, e a túa páxina nunca toca o número.

A diferenza práctica é enorme: pasas de ter que protexer, segmentar e auditar a túa propia infraestrutura a responder un cuestionario curto. A contrapartida é que o formulario deixa de ser teu, coas limitacións de deseño que iso implica, e que calquera atallo —capturar o número «só un momento» para reenvialo— sácate dese réxime sen avisar.

Tokens: dúas cousas distintas co mesmo nome

• Un token do provedor substitúe o número de tarxeta dentro do teu sistema. Serve para volver cobrar sen volver pedir a tarxeta, pero só funciona con ese provedor.
• Un token de rede, o que hai detrás de Apple Pay ou Google Pay, emíteo a propia rede de tarxetas e vén acompañado dun criptograma que cambia en cada operación. Se alguén o intercepta, non lle serve para nada.

Nos dous casos a idea é a mesma: o dato sensible deixa de circular. É a mesma lóxica que fai que un permiso de acceso deba vivir no teu servidor e non no móbil, como se explica en pagos dentro de apps.

Por que se asinan os webhooks

Cando un pagamento se completa, o navegador do cliente volve á túa web cunha URL de retorno. Esa URL non é unha fonte fiable: contrólaa o cliente, e calquera pode visitala. Se o teu sistema marca o pedido como pagado porque o navegador volveu a `/grazas`, tes un problema de seguridade, non un detalle de implementación.

A fonte fiable é o webhook: unha chamada de servidor a servidor desde o teu provedor de pagamentos, asinada. A sinatura habitual é un HMAC-SHA256 do corpo exacto da mensaxe cun segredo compartido, enviado nunha cabeceira. Verificalo ben ten catro regras:

• Asinar e verificar sobre o corpo en cru, antes de parsear o JSON. Un reordenamento de claves cambia a sinatura.
• Comparar en tempo constante, non cunha comparación de cadeas normal.
• Comprobar a antigüidade da mensaxe se vén con marca de tempo, para que unha petición capturada non valla meses despois.
• Ser idempotente: o mesmo evento pode chegar varias veces. Procesalo dúas veces non debe conceder dúas veces o acceso nin emitir dúas facturas.

E unha regra máis: se a sinatura non valida, a resposta correcta é un erro, non un «procésoo igualmente por se acaso».

O importe decídeo o servidor

O último clásico: aceptar o importe que chega desde o cliente. Un formulario, un parámetro na URL ou un campo agochado son editables. O importe a cobrar debe saír sempre do catálogo no servidor; o que envía o cliente é, como moito, a referencia do produto. As tres fases do cobro —e onde encaixa cada validación— están descritas en como funciona un cobro con tarxeta.

Rexistros: menos é máis

Os sistemas de pagamento xeran moitos rexistros, e aí acaban filtrándose datos por descoido: cabeceiras de sinatura completas, corpos de webhook sen recortar, correos e enderezos en texto plano. Rexistra identificadores e estados, non contidos, e define canto tempo se conservan. Un rexistro que ninguén consulta e ninguén borra é só superficie de ataque.

En resumo

A seguridade dun cobro xógase en decisións aburridas: non gardar o que non necesitas, non crer o navegador, verificar sinaturas como se debe e ser idempotente. Nada diso é visible para o cliente, e todo se nota o día que algo vai mal. Podes ver o resto de artigos sobre seguridade e normativa ou como se representan os estados dun pagamento na demo.