Seguridad de la Conexion
Mecanismos de seguridad implementados para garantizar una comunicacion segura entre Tapi y el Cliente.
Cliente
Quien consumira el servicio de Tapi sea cual fuere la vertical de negocio.
Clave Publica (Public Key)
La clave publica se comparte abiertamente y se utiliza para cifrar datos.
Clave Privada (Private Key)
La clave privada se mantiene en secreto y se utiliza para descifrar datos cifrados con la clave publica correspondiente.
API Key
Un codigo unico pasado en llamadas de API para identificar al Cliente o la aplicacion que realiza la solicitud.
Cuando Tapi envia solicitudes al Cliente, se implementan los siguientes pasos de seguridad:
Filtrado de IPs
Se configura una lista blanca de direcciones IP desde las cuales Tapi puede enviar solicitudes. Esto asegura que solo las solicitudes provenientes de IPs autorizadas sean aceptadas.
Validacion de API Key
Tapi incluye una API key en las solicitudes enviadas al Cliente. Esta clave es unica y se utiliza para identificar y autenticar a Tapi. El Cliente verifica la API key en cada solicitud para asegurarse de que proviene de una fuente autorizada.
Cifrado de Informacion con Clave Asimetrica
La informacion sensible enviada por Tapi es cifrada usando la clave publica del Cliente. Al recibir la informacion, el Cliente la descifra utilizando su clave privada. El algoritmo de cifrado es SHA512.
Cifrado
Tapi cifra los datos con la clave publica del Cliente.
Descifrado
El Cliente descifra los datos usando su clave privada.
Cuando el Cliente envia solicitudes a Tapi, se implementan los siguientes pasos de seguridad:
JWT (JSON Web Token)
El Cliente genera un JWT para cada solicitud o notificacion enviada a Tapi. Este token contiene informacion verificada y es firmado digitalmente por el Cliente.
Inicio de sesion: Se utiliza el servicio POST /login, descripto en la documentacion tecnica provista por Tapi.
Uso del JWT: Una vez autenticado, el JWT se incluye en las cabeceras de las solicitudes utilizando el accessToken. El token tiene una duracion limitada, la cual se puede verificar en el campo exp.
Verificacion del JWT: Tapi recibe el JWT y verifica su validez.
API Key
Ademas del JWT, el Cliente incluye una API key en las solicitudes enviadas a Tapi. Esta clave sirve para autenticar al Cliente. Tapi verifica la API key en cada solicitud para confirmar la identidad del Cliente.
Cuando aplica?
En este caso:
- El emisor gestiona la referencia desde su core bancario.
- No se utiliza el servicio de generacion de referencias (POST /references).
- El usuario final informa o escanea el numero de tarjeta en caja; ese valor circula como reference/account_number en el flujo transaccional.
| Capa | Comportamiento Esperado |
|---|---|
| Comisionista → Tapi | Se recibe el PAN como referencia de la operacion. Transporte siempre sobre HTTPS. |
| Tapi → Emisor | El emisor necesita el PAN completo para autorizar y conciliar. El campo reference se envia en el payload acordado. Al enviar el request tapi deshashea la referencia y viaja en plano, solamente se enmascara el log. |
| Tapi (interno) | Tapi minimiza la exposicion del PAN: no debe persistirse ni loguearse en texto plano mas alla de lo estrictamente necesario para procesar la operacion. Se persiste y se loguea la referencia enmascarada, con los ultimos 3 digitos visibles. Internamente tapi hace un cifrado con KMS reversible con las referencias tipo PAN. |
| Consultas posteriores | Las consultas de estado se realizan preferentemente por operationId o externalPaymentId, no reenviando el PAN. |
Usuario en tienda
│ informa / escanea PAN
▼
Comisionista (POS)
│ HTTPS — reference = PAN
▼
Tapi
│ ├─ Uso transitorio del PAN para autorizar
│ ├─ Protección interna
│ └─ HTTPS + x-api-key + hash de integridad
▼
Emisor (Cliente)
│ POST /payment-intent → autoriza contra su core
│ POST /notifications ← Tapi confirma resultado
▼
Core bancario del emisor| Control | Descripcion |
|---|---|
| No generacion de referencias | En flujo regulado MX, Tapi no emite ni administra el PAN; lo recibe y lo reenvia al emisor para autorizacion. |
| Minimizacion de almacenamiento | El PAN no debe persistirse en texto plano en bases operacionales, logs ni sistemas de observabilidad. |
| Enmascaramiento en trazas | En logs, auditoria y respuestas donde aplique, el PAN se trunca o enmascara (ej. mostrar solo ultimos 4 digitos). |
| Identificadores de operacion | Cada operacion tiene operationId (Tapi) y opcionalmente externalPaymentId (emisor) para trazabilidad sin reutilizar el PAN. |
| Transporte cifrado | Toda comunicacion externa sobre HTTPS/TLS 1.2. |
| Autenticacion mutua | Segun direccion del trafico (ver seccion 'Seguridad de la Conexion'): x-api-key, JWT (x-authorization-token), whitelist de IPs. |
Nota Interna
Cuando el emisor consulta operaciones en APIs de Tapi:
| Mecanismo | Detalle |
|---|---|
| POST /login | Obtencion de accessToken |
| x-authorization-token | JWT con el accessToken |
| x-api-key | Identificacion del cliente |
| Consulta por ID | GET /operation/{operationId} o GET /operation/{externalPaymentId}?type=external-payment-id— evita retransmitir PAN en consultas |
| Actor | Responsabilidad |
|---|---|
| Emisor | Emision y gestion del PAN en su core; exposicion de /payment-intent; validacion de cuenta/saldo/limites/bloqueos; recepcion de notificaciones y aclaraciones. |
| Tapi | Canal de pago; reenvio seguro del PAN al emisor para autorizacion; minimizacion de retencion interna; trazabilidad por operationId. |
| Cadena POS | Captura del PAN en caja; almacenamiento seguro y minimizacion de retencion interna; transmision a Tapi sobre canal seguro. |
| PCI / Cumplimiento | El emisor es titular del dato en su core. Tanto Tapi como la Cadena deben operar bajo politica de no almacenamiento innecesario del PAN, asi como contar con controles de logging/enmascaramiento. |