Guía Web - Primeros Pasos y Errores Comunes

Uso de la web

El primer paso para la utilización de la web, debe ser proceder con el login. En caso de no habernos registrado, debemos crear una cuenta y registrarnos:

Opciones de login y crear cuenta

Para hacer uso de las operaciones, es necesario registrarse. Para ello, se dispone de una opción de login o crear una cuenta, en la parte superior derecha:

Crear una cuenta de usuario

Para realizar el alta de una cuenta, hacemos click en la opción de Crear una cuenta. El proceso sería de un registro común, con un email y una contraseña:

Operaciones del Sandbox

Una vez nos hemos logeado en la web, es necesario tener aplicaciones disponibles y que éstas se encuentren suscritas a un plan, de cara a utilizar las operaciones disponibles para usarlas.

Alta de una aplicación

Para dar de alta una aplicación, basta con acceder a la pestaña de “Aplicaciones”:

Si no hay aplicaciones disponibles, aparecería un listado vacío, y un botón de “Crear aplicación”. Hacemos click en “Crear aplicación:

Completamos los datos requeridos (Bastaría con poner un título) y pulsamos “Enviar”:

Creamos la aplicación:

Suscripción a un plan

Desde la interfaz de operaciones, pulsamos en el botón de “Suscribirse”:

Y nos lleva a la interfaz de suscripción a un plan. Hacemos click en el plan que nos interese:

Si es la primera vez que elegimos una suscripción a un plan, y no tenemos ninguna aplicación dada de alta, se nos requerirá que registremos una aplicación:

El detalle de cómo generar aplicaciones, se explica la sección de alta de aplicaciones. Si ya tenemos una aplicación dada de alta, nos aparecería en un listado:

Una vez hayamos hecho la suscripción, nos debe llegar un email a la cuenta de registro, indicando que la cuenta ya está suscrita al plan seleccionado. Este email, en principio, llegaría en un tiempo máximo de un día. De no ser así, por favor, dirigir un email a psd2.sandbox.soporte@redsys.es

Operaciones de prueba

En esta sección describimos cómo realizar una invocación de prueba desde la web. Como prerrequisito, tal y como se ha descrito anteriormente, como mínimo, es necesario estar logeado como usario, tener una aplicación creada, y que esta se encuentre suscrita a un plan.

Autenticación con oAuth2

Antes de lanzarse la petición, se debe tener en cuenta que hay que generar un token de oAuth2.
Para generar el token, bastaría con dirigirnos a la pestaña de “oAuth2” (Para usuarios logeados):

A la izquierda de la pantalla, tenemos el menú:

Haciendo click en el botón indicado, nos dirigimos hacia un formulario de login. Este formulario estaría simulando el formulario de autenticación de la entidad financiera en la cual estamos actualmente en sesión.

Se debe tener en cuenta que el entorno de Sandbox es un entorno de simulación. Por lo tanto, los datos de entrada del login también serían parte de la simulación. Las credenciales en estos momentos, son comunes a todas las EF simuladas: “user1” password: “1234”. Estas credenciales se encuentran disponibles en la documentación de la entidad.

Una vez hagamos login en el formulario, nos devolvería un token de autenticación:

Este token habría que informarlo en la cabecera de autenticación correspondiente:
Authorization: Bearer VALORTOKEN

Certificados

Uno de los headers obligatorios en la petición de la query, es el del certificado: TPP-Signature-Certificate. En esta web, en la pestaña de "Certificados", se encuentra disponible un certificado genérico, que puede utilizarse para hacer la invocación.

Este campo es el que se utiliza para la identificación del TPP. Por esto, la utilización del certificado genérico, debe ser temporal. Es necesario disponer de un certificado propio, que identifique al TPP que hace la petición.

Se debe tener en cuenta que el campo 'organizationId', contenido en el certificado, debe ser igual al valor informado en el campo 'client_id', en el flujo de autenticación de oAuth2.

Lanzar petición

Accedemos a la interfaz web, a la consola de operaciones. Navegamos/Hacemos scroll descendente, hasta encontrar la operación que nos interese:

Como vemos, en cada operación, hay tres campos a destacar: El endpoint del entorno de Sandbox, la identificación (Donde informamos el Client-ID) Y el cuerpo de la petición.

Cuando hayamos informado la petición como nos interese, con los campos correspondientes, hacemos click en “Operación de llamada” para ejecutar la invocación y comprobar los resultados.

Errores comunes en la utilización de la consola de operaciones

La consola de operaciones, como se ha comentado, es la parte de la web desde la cual se pueden lanzar operaciones contra el servicio.

Se proporciona una interfaz para utilizar las invocaciones, para cada servicio. En este caso, comentamos los errores más comunes, que se pueden producir utilizando esta consola. De aquí en adelante, nos referiremos a esta consola como “API-ONLINE”, ya que en la web, se hace referencia a la misma con este nombre.

Los errores recopilados en esta sección parten desde la misma casuística: Un usuario pulsa sobre el botón de “Operación” para invocar al servicio, y obtiene los siguientes mensajes:

Unauthorized – Invalid client id or secret

Mensaje de error mostrado en la consola:


"httpCode": "401",

"httpMessage": "Unauthorized",

"moreInformation": "Invalid client id or secret."

El usuario debe estar logeado para utilizar el API-Online. Debe además, haber registrado una aplicación, y la aplicación debe tener una suscripción y estar aprobada, tal y como se explica en apartados anteriores.

FORMAT_ERROR - HEADER: X-Request-ID

Mensaje de error mostrado en la consola:


{

  "tppMessages": [

    {

      "category": "ERROR",

       "code": "FORMAT_ERROR",

      "path": "HEADER: X-Request-ID",

      "text": "Format of certain request fields are not matching the XS2A requirements."

    }

  ],

"transactionStatus": "RJCT"

}

Este mensaje se produce cuando el usuario no informa el campo X-Request-ID. Se trata de un header, y en la documentación se proporciona un ejemplo de este campo. Se trata de un campo obligatorio en todas las invocaciones, y se debe tener en cuenta que se debe modificar en cada petición (Es decir, no se puede reutilizar el mismo X-Request-ID)

TOKEN_UNKNOWN


Mensaje en la consola:

{

  "tppMessages": [

    {

      "category": "ERROR",

      "code": "TOKEN_UNKNOWN",

      "text": "The OAuth2 token cannot be matched by the ASPSP relative to the TPP"

    }

  ]

}

El token de oAuth2, se debe generar desde la pestaña de “oAuth2”, utilizando el botón de “Generar Token”. Después, este token se informa en el campo “Authorization”, con el formato “Bearer ‘token generado’”.

Puede ser un error común que no se informe el campo ASPSP correctamente. Si no se selecciona ninguna entidad al hacer el envío del mensaje, de forma automática, se estaría seleccionando “redsys” en el campo ASPSP, generando el error que comentamos arriba.

Por lo tanto, Si el token está generado para BBVA (por ejemplo) en el campo ASPSP, se debe informar BBVA.

El campo ASPSP forma parte de la url, y está puesto como un combo seleccionable en la consola de operaciones.