Merge pull request #110 from placetopay-org/3dss-doc

feat: update doc 3dss cases
placetopay-org · Sep 20, 2024 · 835799d · 835799d
2 parents 11d6ddc + a760902
commit 835799d
Show file tree

Hide file tree

Showing 48 changed files with 2,468 additions and 1,704 deletions.
diff --git a/src/assets/apis/three-d-s-server/en.yaml b/src/assets/apis/three-d-s-server/en.yaml
@@ -1,6 +1,6 @@
 openapi: 3.0.0
 info:
-  title: 3DS Server (MPI)
+  title: 3DS Server
   version: '1.0'
   description: 'Este documento presenta el funcionamiento del servicio o la API del 3DS Server. Expone las rutas a consumir (/sessions y /transactions), la url, el método, parámetros y los tipos datos que recibe. Además, contiene ejemplos de respuestas para diferentes tipos de peticiones en el flujo de autenticación de un tarjetahabiente dentro del marco del protocolo 3-D Secure.'
   contact:

diff --git a/src/assets/apis/three-d-s-server/es.yaml b/src/assets/apis/three-d-s-server/es.yaml
@@ -1,6 +1,6 @@
 openapi: 3.0.0
 info:
-  title: 3DS Server (MPI)
+  title: 3DS Server
   version: '1.0'
   description: 'Este documento presenta el funcionamiento del servicio o la API del 3DS Server. Expone las rutas a consumir (/sessions y /transactions), la url, el método, parámetros y los tipos datos que recibe. Además, contiene ejemplos de respuestas para diferentes tipos de peticiones en el flujo de autenticación de un tarjetahabiente dentro del marco del protocolo 3-D Secure.'
   contact:

diff --git a/src/constants/navigations.js b/src/constants/navigations.js
@@ -455,7 +455,7 @@ export const TAB_NAVIGATION = {
                 href: '/three-d-s-server/api/sessions',
               },
               {
-                title: 'Detalle de los campos del api',
+                title: 'Datos adicionales',
                 href: '/three-d-s-server/api/sessions/detail-info',
               },
             ],
@@ -590,7 +590,7 @@ export const TAB_NAVIGATION = {
                 href: '/three-d-s-server/api/sessions'
               },
               {
-                title: 'Detail Info',
+                title: 'Additional data',
                 href: '/three-d-s-server/api/sessions/detail-info',
               },
             ],

diff --git a/src/pages/acs/3-d-s-secure-protocol.mdx b/src/pages/acs/3-d-s-secure-protocol.mdx
@@ -4,8 +4,6 @@ El protocolo 3-D Secure es un documento que describe la infraestructura y los co
 
 El protocolo de autenticación 3-D Secure se basa en un modelo de tres dominios, en el que el Dominio del Adquirente y el Dominio del Emisor están conectados por el Dominio de Interoperabilidad a través de una serie de mensajes, con el fin de autenticar a un tarjetahabiente durante una transacción de comercio electrónico (e-commerce) o para verificar la identidad o la cuenta del tarjetahabiente en autenticaciones de no pago.
 
-El protocolo cuenta actualmente con dos versiones activas, la versión 2.1.0 y la versión 2.2.0. La principal diferencia entre ambas versiones es que en la 2.1.0, la autenticación del tarjetahabiente siempre va a requerir de un reto para comprobar su identidad, el cual consiste en aportar información personal adicional o en la verificación de un código o similares. Mientras que en la versión 2.2.0, además del flujo con reto, se implementó el flujo de autenticación sin reto, esto para los casos en los cuales el tarjetahabiente aporte datos completos y seguros o esté en listas blancas; además se creó para esta versión otro tipo de autenticación nombrada como desacoplada.
-
 De esta forma, el proceso de autenticación puede darse mediante un flujo sin fricción o con fricción, entendiendo la fricción como el reto para autenticarse. Siendo el componente de ACS, quien decide cual de estos flujos es el adecuado para completar una autenticación, dependiendo del nivel de legitimidad evaluado en la información provista por el tarjetabiente y de la versión utilizada del protocolo.
 
 # Dominios y Componentes

diff --git a/src/pages/acs/authentication-status.mdx b/src/pages/acs/authentication-status.mdx
@@ -18,7 +18,7 @@ Estado | Descripción
 
 Los siguientes son las razones de los estados anteriormente presentados, estas razones proporcionan más información del por qué una transacción puede presentar un estado específico. 
 
-### Razones de estados de autenticación para versiones 2.1.0 y 2.2.0 del protocolo 3DS:
+### Razones de estados de autenticación para la version 2.2.0 del protocolo 3DS:
 
 Indicador   | Razón                                                                                                 |  
 ------------|-------------------------------------------------------------------------------------------------------|
@@ -65,13 +65,6 @@ Indicador   | Razón
  88         | Petición no soportada por ACS.                                           |   
  89         | CAVV incluído en la respuesta.                                           |            
 
-### Razones adicionales de estados de autenticación para versión 2.1.0 del protocolo 3DS:
-
-Indicador   | Razón                                                                                                 |  
-------------|-------------------------------------------------------------------------------------------------------|
- 81         | Acepta la excepción de SCA (Estado válido para Mastercard).                                           |   
-
-
 ### Razones adicionales de estados de autenticación para versión 2.2.0 del protocolo 3DS:
 
 Indicador   | Razón                                                                                                 |  

diff --git a/src/pages/acs/issuer-configuration.mdx b/src/pages/acs/issuer-configuration.mdx
@@ -61,7 +61,7 @@ Se requiere que exista una relación entre emisor, adquiriente y comercio y que
 
 Importante tener en cuenta habilitar todos los campos de configuración del menú *Campos de configuración* de la aplicación, antes de crear el emisor, ya que todos estos campos son requeridos para el funcionamiento básico de un emisor.
 
-En este punto es importante recordar que la aplicación de **MPI** también implementa y pertenece al flujo propuesto por el protocolo 3-D Secure para autenticar un tarjetahabiente. Pertenece al dominio el adquiriente y entre sus funciones principales están:
+En este punto es importante recordar que la aplicación de **3DSS** también implementa y pertenece al flujo propuesto por el protocolo 3-D Secure para autenticar un tarjetahabiente. Pertenece al dominio el adquiriente y entre sus funciones principales están:
   - Recibir y responder la petición de autenticación enviada por el comercio o pasarela de pagos.
   - Solicitar al emisor la autorización del pago.
   - Responder al comercio o pasarela de pagos el estado final de la autenticación.

diff --git a/src/pages/en/acs/3-d-s-secure-protocol.mdx b/src/pages/en/acs/3-d-s-secure-protocol.mdx
@@ -6,8 +6,6 @@ El protocolo 3-D Secure es un documento que describe la infraestructura y los co
 
 El protocolo de autenticación 3-D Secure se basa en un modelo de tres dominios, en el que el Dominio del Adquirente y el Dominio del Emisor están conectados por el Dominio de Interoperabilidad a través de una serie de mensajes, con el fin de autenticar a un tarjetahabiente durante una transacción de comercio electrónico (e-commerce) o para verificar la identidad o la cuenta del tarjetahabiente en autenticaciones de no pago.
 
-El protocolo cuenta actualmente con dos versiones activas, la versión 2.1.0 y la versión 2.2.0. La principal diferencia entre ambas versiones es que en la 2.1.0, la autenticación del tarjetahabiente siempre va a requerir de un reto para comprobar su identidad, el cual consiste en aportar información personal adicional o en la verificación de un código o similares. Mientras que en la versión 2.2.0, además del flujo con reto, se implementó el flujo de autenticación sin reto, esto para los casos en los cuales el tarjetahabiente aporte datos completos y seguros o esté en listas blancas; además se creó para esta versión otro tipo de autenticación nombrada como desacoplada.
-
 De esta forma, el proceso de autenticación puede darse mediante un flujo sin fricción o con fricción, entendiendo la fricción como el reto para autenticarse. Siendo el componente de ACS, quien decide cual de estos flujos es el adecuado para completar una autenticación, dependiendo del nivel de legitimidad evaluado en la información provista por el tarjetabiente y de la versión utilizada del protocolo.
 
 # Dominios y Componentes

diff --git a/src/pages/en/acs/a-c-s-general-configuration.mdx b/src/pages/en/acs/a-c-s-general-configuration.mdx
@@ -41,7 +41,7 @@ En este módulo se encuentran los componentes que permiten configurar ACS y gest
   - Listado y funcionalidades de las configuraciones para los emisores.
   - Listado y funcionalidades de los importes creados en la aplicación.
 
- Estos módulos y sus funcionalidades, se revisan y explican detalladamente en la presente sección de *Configuración*  y en los artículos que la componen.
+ Estos módulos y sus funcionalidades, se revisan y explican detalladamente en la presente sección de *Configuración* y en los artículos que la componen.
 
 #### Seguridad:
 En este módulo se encuentran los componentes que gestionan los accesos, registros de movimientos, permisos y módulos de seguridad para ACS.

diff --git a/src/pages/en/acs/authentication-status.mdx b/src/pages/en/acs/authentication-status.mdx
@@ -4,23 +4,23 @@
 
 Los siguientes son los estados posibles que pueden obtenerse en un proceso de autenticación. Se presenta el indicador del estado y la descripción del mismo.
 
-Estado | Descripción                                                                                               |
--------|-----------------------------------------------------------------------------------------------------------|
- Y     | Autenticación satisfactoria.                                                                              |  
- N     | Autenticación fallida. Se rechazó la autenticación sin embargo el comercio puede aprobar la transacción asociada.                                                                                                          |
- U     | Autenticación no realizada. Se presentó un error técnico durante el proceso.                              |
- A     | Se ejecutó un intento de autenticación.                                                                   |
- C     | Se requiere desafío para continuar el proceso de autenticación.                                         |
- R     | Autenticación rechazada. Una transacción cuya autenticación resulte en estado R no debería ser procesada debido al riesgo.                                                                                                  |
- D     | La autenticación requiere un desafío desacoplado, este es responsabilidad del emisor.                     |
- I     | Autenticación de tipo informativa, no soporta pago. Utilizada para verificar cuentas.                     |
+| Estado | Descripción                                                                                                                |
+|--------|----------------------------------------------------------------------------------------------------------------------------|
+| Y      | Autenticación satisfactoria.                                                                                               |
+| N      | Autenticación fallida. Se rechazó la autenticación sin embargo el comercio puede aprobar la transacción asociada.          |
+| U      | Autenticación no realizada. Se presentó un error técnico durante el proceso.                                               |
+| A      | Se ejecutó un intento de autenticación.                                                                                    |
+| C      | Se requiere desafío para continuar el proceso de autenticación.                                                            |
+| R      | Autenticación rechazada. Una transacción cuya autenticación resulte en estado R no debería ser procesada debido al riesgo. |
+| D      | La autenticación requiere un desafío desacoplado, este es responsabilidad del emisor.                                      |
+| I      | Autenticación de tipo informativa, no soporta pago. Utilizada para verificar cuentas.                                      |
 
 
 ## Razones de los estados del proceso de autenticación
 
 Los siguientes son las razones de los estados anteriormente presentados, estas razones proporcionan más información del por qué una transacción puede presentar un estado específico. 
 
-### Razones de estados de autenticación para versiones 2.1.0 y 2.2.0 del protocolo 3DS:
+### Razones de estados de autenticación para la version 2.2.0 del protocolo 3DS:
 
 Indicador   | Razón                                                                                                 |  
 ------------|-------------------------------------------------------------------------------------------------------|
@@ -54,32 +54,26 @@ Indicador   | Razón
 
 ### Razones de estados para VISA:
 
-Indicador   | Razón                                                                                                 |  
-------------|-------------------------------------------------------------------------------------------------------|
- 80         | Error de conexión con ACS.                                           |
- 81         | Agotado tiempo de espera.                                           |   
- 82         | Respuesta inválida dada por el ACS.                                           |   
- 83         | Error del sistema desde ACS.                                           |   
- 84         | Error interno mientras se generaba el CAVV.                                           |   
- 85         | VMID no elegible por la petición solicitada.                                           |   
- 86         | Versión del protocolo no soportada por ACS.                                           |   
- 87         | Transacción excluída por número de intentos de procesamiento.                                           |   
- 88         | Petición no soportada por ACS.                                           |   
- 89         | CAVV incluído en la respuesta.                                           |            
-
-### Razones adicionales de estados de autenticación para versión 2.1.0 del protocolo 3DS:
-
-Indicador   | Razón                                                                                                 |  
-------------|-------------------------------------------------------------------------------------------------------|
- 81         | Acepta la excepción de SCA (Estado válido para Mastercard).                                           |   
+| Indicador | Razón                                                         |
+|-----------|---------------------------------------------------------------|
+| 80        | Error de conexión con ACS.                                    |
+| 81        | Agotado tiempo de espera.                                     |
+| 82        | Respuesta inválida dada por el ACS.                           |
+| 83        | Error del sistema desde ACS.                                  |
+| 84        | Error interno mientras se generaba el CAVV.                   |
+| 85        | VMID no elegible por la petición solicitada.                  |
+| 86        | Versión del protocolo no soportada por ACS.                   |
+| 87        | Transacción excluída por número de intentos de procesamiento. |
+| 88        | Petición no soportada por ACS.                                |
+| 89        | CAVV incluído en la respuesta.                                |
 
 
 ### Razones adicionales de estados de autenticación para versión 2.2.0 del protocolo 3DS:
 
-Indicador   | Razón                                                                                                 |  
-------------|-------------------------------------------------------------------------------------------------------|
- 22         | Asunto técnico en ACS.                                                                                |
- 23         | Autenticación desacoplada requerida por ACS pero no solicitada por 3DS Requestor.                     |   
- 24         | Se superó el tiempo máximo de espera del solicitante 3DS desacoplado.                                 |
- 25         | La autenticación desacoplada no tuvo tiempo suficiente para autenticar al tarjetahabiente. ACS no hará más intentos.                                                                                                       |
- 26         | Autenticación intentada pero no realizada por el tarjetahabiente.                                     |
+| Indicador | Razón                                                                                                                |
+|-----------|----------------------------------------------------------------------------------------------------------------------|
+| 22        | Asunto técnico en ACS.                                                                                               |
+| 23        | Autenticación desacoplada requerida por ACS pero no solicitada por 3DS Requestor.                                    |
+| 24        | Se superó el tiempo máximo de espera del solicitante 3DS desacoplado.                                                |
+| 25        | La autenticación desacoplada no tuvo tiempo suficiente para autenticar al tarjetahabiente. ACS no hará más intentos. |
+| 26        | Autenticación intentada pero no realizada por el tarjetahabiente.                                                    |
diff --git a/src/pages/en/acs/issuer-configuration.mdx b/src/pages/en/acs/issuer-configuration.mdx
@@ -63,7 +63,7 @@ Se requiere que exista una relación entre emisor, adquiriente y comercio y que
 
 Importante tener en cuenta habilitar todos los campos de configuración del menú *Campos de configuración* de la aplicación, antes de crear el emisor, ya que todos estos campos son requeridos para el funcionamiento básico de un emisor.
 
-En este punto es importante recordar que la aplicación de **MPI** también implementa y pertenece al flujo propuesto por el protocolo 3-D Secure para autenticar un tarjetahabiente. Pertenece al dominio el adquiriente y entre sus funciones principales están:
+En este punto es importante recordar que la aplicación de **3DSS** también implementa y pertenece al flujo propuesto por el protocolo 3-D Secure para autenticar un tarjetahabiente. Pertenece al dominio el adquiriente y entre sus funciones principales están:
   - Recibir y responder la petición de autenticación enviada por el comercio o pasarela de pagos.
   - Solicitar al emisor la autorización del pago.
   - Responder al comercio o pasarela de pagos el estado final de la autenticación.

diff --git a/src/pages/en/three-d-s-server/api/client-requirements.mdx b/src/pages/en/three-d-s-server/api/client-requirements.mdx
@@ -2,7 +2,7 @@
 
 # Requerimientos para el cliente que va a integrarse
 
-Para integrarse al servicio de 3DS Server o 3DS Secure Merchant Plugin (MPI) de Evertec, el comercio o pasarela deberá cumplir con los siguientes requisitos, necesarios para garantizar la compatibilidad en la conexión:
+Para integrarse al servicio de 3DS Server o 3DS Secure de Evertec, el comercio o pasarela deberá cumplir con los siguientes requisitos, necesarios para garantizar la compatibilidad en la conexión:
 
 - **Encabezados HTTP:** Los encabezados HTTP deben estar parametrizados con los siguientes valores:
 
@@ -15,6 +15,6 @@ Para integrarse al servicio de 3DS Server o 3DS Secure Merchant Plugin (MPI) de
 
       Authorization:"Bearer 1c6b2cda415f40f6f9f82e24d31d3fa6deb3cbcdd1def686fef7ed721a8abf83"
 
-  > Este token se crea en el módulo de **Tokens**, ubicado en el menú **Funcionamiento de MPI** -> **Seguridad**.
+    >  Este token es proporcionado por el administrador de seguridad transaccional.
 
 - **Comunicaciones seguras:** Para establecer los enlaces asegurados por Transport Layer Security (TLS), entre el servicio y los clientes conectados, el número de versión debe ser 1.2 o superior. Las claves RSA deben tener una longitud mínima de 2048 bits.
diff --git a/src/pages/en/three-d-s-server/api/index.mdx b/src/pages/en/three-d-s-server/api/index.mdx
@@ -10,7 +10,7 @@ En el dinámico mundo del comercio electrónico, donde la seguridad y la confian
 
 #### ¿Por qué Integrarse con nuestra API de 3DS?
 
-Nuestra API de **3DS Server** le permite implementar de manera rápida y eficaz las funcionalidades del protocolo **3DS** en sus sistemas. Al integrarse con nuestra API, su empresa podrá aprovechar las últimas características de las últimas versiones activas del protocolo, como **EMV® 3DS 2.1.0, 2.2.0** y **2.3.1**.
+Nuestra API de **3DS Server** le permite implementar de manera rápida y eficaz las funcionalidades del protocolo **3DS** en sus sistemas. Al integrarse con nuestra API, su empresa podrá aprovechar las últimas características de las últimas versiones activas del protocolo, como **EMV® 3DS 2.2.0** y **2.3.1**.
 
 La integración con nuestra API ofrece: