MARCO DE REFERENCIA PARA LA PLATAFORMA DE INTEROPERABILIDAD VOLUMEN IV: MANUAL DEL DESARROLLADOR SERVICIO DE PASARELA DE PAGOS

Transcripción

1 Interoperabilidad de los servicios telemáticos de la Administración Pública de la CAC Página 1 de 59 MARCO DE REFERENCIA PARA LA PLATAFORMA DE INTEROPERABILIDAD VOLUMEN IV: MANUAL DEL DESARROLLADOR SERVICIO DE PASARELA DE PAGOS Historial de revisiones en la siguiente página Documento : Ubicación en eroom: PLA-DOC-FIN Vol IV. Preparado por Revisado por Aprobado por D. Gral. de Telecomunicaciones y Nuevas Tecnologías D. Gral. de Telecomunicaciones y Nuevas Tecnologías D. Gral. de Telecomunicaciones y Nuevas Tecnologías Fecha: 28/06/2016 Fecha: 28/06/2016 Fecha: 28/06/2016

2 Página 2 de 59

3 Página 3 de 59 ÍNDICE 1 DESCRIPCIÓN GENERAL VERSIÓN DEL SERVICIO CASOS DE USO CU-PPA-03: Listar entidades Financieras Interfaz Entrada del servicio Salida del servicio Excepciones CU-PPA-04: Verificar NRC Interfaz Entrada del servicio Salida del servicio Excepciones CU-PPA-05: Obtener Versión del Servicio Interfaz Entrada del servicio Salida del servicio CU-PPA-06: Realizar Pago Firmado Interfaz Entrada del servicio...22 Pagos bajo Norma Pagos bajo Norma60 modalidad 1 y Pagos bajo Norma60 modalidad Salida del servicio...36 Respuesta de un pago bajo Norma Respuesta de un pago bajo Norma60 modalidad 1 y Respuesta de un pago bajo Norma60 modalidad Excepciones CU-PPA-07: Realizar Consulta Firmada CU-PPA-08: Obtener Datos Concepto Interfaz Entrada del servicio Salida del servicio Excepciones EXCEPCIONES InvalidParameterValueException MalFormedXmlDatosException...50

4 Página 4 de UnknownRespuestaCasillaNameException UnknownPeticionCasillaNameException ExcepcionPasarelaFirmaInvalida ExcepcionPasarelaErrorFirma INFORMACIÓN ADICIONAL DEL SERVICIO Códigos de respuesta de la Pasarela de Pagos Códigos de retorno de la entidades financieras...54

5 Página 5 de 59 1 DESCRIPCIÓN GENERAL La Pasarela de Pagos de PLATINO es una infraestructura común que permite a la Administración incorporar el pago electrónico en sus tramitaciones. Como tal infraestructura básica, el objetivo principal es abstraer a procedimientos y aplicaciones de tramitación de la complejidad del pago electrónico. Para lograr este objetivo la pasarela se basa en: Estandarizar un formato de intercambio único con todas las Entidades Financieras. Estandarizar un interfaz programático único con las aplicaciones que deseen incorporar pago. Estandarizar una operativa de pago, independientemente de la naturaleza del pago, la tramitación o la Administración concreta. No interferir en los acuerdos entre Entidades Financieras y Administraciones. Estos planteamientos proporcionan una serie de ventajas que se enumeran a continuación: Para las Administraciones una infraestructura única permite: Independizar a las aplicaciones de las de las complejidades técnicas del pago electrónico. La incorporación de una nueva Entidad Financiera es transparente. Cualquier nueva funcionalidad está disponible para todas las Administraciones. Para las Entidades Financieras, hay una Pasarela única, válida para todas las Administraciones en lugar de una por cada una de ellas con los ahorros de desarrollo y mantenimiento que esto conlleva. El establecimiento de un interfaz de usuario único en los procesos de pago con la Administración da confianza a los ciudadanos/as en el pago Electrónico. Cualquier transacción económica que se realice con esta plataforma de pago será notificada a la Dirección General de Tributos, mediante mensajes. Este servicio se apoya en una aplicación desarrollada por la empresa TB-Solutions denominada "Plataforma de Pagos", de forma que actuará como fachada de las funcionalidades que proporciona.

6 Página 6 de 59 2 VERSIÓN DEL SERVICIO Este documento corresponde a la versión 2.1 del servicio para la arquitectura Platino 2.0.

7 Página 7 de 59 3 CASOS DE USO A continuación se muestra el diagrama de casos de uso del servicio de Pasarela de Pago:

8 Página 8 de 59 Estos casos de uso han dado lugar a la siguiente interfaz de servicio: Operaciones

9 Página 9 de CU-PPA-03: Listar entidades Financieras Este caso de uso da la opción a los ciudadanos para obtener un listado de entidades financieras habilitadas en la Plataforma de Pagos para pagar un determinado concepto Interfaz Entrada del servicio La entrada del servicio, es un xml que contiene todos los parámetros por los que se quiere filtrar la búsqueda de entidades financieras. Parámetro consultaentidadesxml Descripción String que contiene los parámetros por los que se filtrará la búsqueda.

10 Página 10 de 59 Dicho xml, se validará contra el siguiente XSD. peticion_listar_entidades.xsd <?xml version="1.0" encoding="utf-8" standalone="yes"?> <xs:schema version="1.0" xmlns:xs=" <xs:element name="peticionlistarentidades"> <xs:complextype > <xs:sequence> <xs:element name="idaplicacion" type="alfanumerico" minoccurs="1" /> <xs:element name="modelo" type="numerico" minoccurs="0"/> <xs:element name="concepto" type="numerico" minoccurs="0"/> <xs:element name="codigoorganismo" type="numerico" minoccurs="0"/> <xs:element name="mediopago" type="numerico" minoccurs="0 /> </xs:sequence> </xs:complextype> </xs:element> <xs:simpletype name="alfanumerico"> <xs:restriction base="xs:string"> <xs:minlength value="1" /> </xs:restriction> </xs:simpletype> <xs:simpletype name="numerico"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]+" /> </xs:restriction> </xs:simpletype> </xs:schema>

11 Página 11 de 59 Breve descripción de lo que se espera en cada elemento del xml. Nombre Tipo Descripción idaplicacion An(10) Código de la aplicación que realiza la invocación al servicio modelo N(3) Modelo admitido por la Pasarela para el Organismo indicado concepto N(4) Concepto correspondiente al Modelo y al Organismo indicado ( ¹ ) codigoorganismo N(5) Organismo admitido en la Pasarela mediopago N(1) Medio de pago. Con cuenta corriente: 1, con tarjeta: 2 ( ² ) N Numérico An AlfaNumérico ( ¹ ) Si se especifica un valor en concepto, se deberá especificar también el modelo. ( ² ) Si el medio de pagos es a través de tarjetas, es necesario especificar el código de organismo. Un ejemplo típico de una invocación a esta operación es la que se muestra a continuación: Ejemplo de Entrada <soapenv:envelope xmlns:soapenv=" xmlns:pas=" <soapenv:header/> <soapenv:body> <pas:listarentidades> <consultaentidadesxml><![cdata[<?xml version="1.0" encoding="utf-8" standalone="yes"?> <peticionlistarentidades> <idaplicacion>appj</idaplicacion> <modelo>123</modelo> <concepto>1234</concepto> <codigoorganismo>62005</codigoorganismo> <mediopago>2</mediopago> </peticionlistarentidades> ]]></consultaentidadesxml> </pas:listarentidades> </soapenv:body> </soapenv:envelope>

12 Página 12 de Salida del servicio A continuación se muestra el modelo de datos que devuelve el Servicio en respuesta a una invocación con éxito de esta operación. Un ejemplo típico de respuesta de esta operación es la que se muestra a continuación: Ejemplo de Salida <soapenv:envelope xmlns:soapenv=" <soapenv:body> <ns2:listarentidadesresponse xmlns:env=" xmlns:ns2=" <return> <entidades> <codigoentidad>6756</codigoentidad> <nombre>entidad Financiera para lanzar Tests</nombre> </entidades> </return> </ns2:listarentidadesresponse> </soapenv:body> </soapenv:envelope> Excepciones Este servicio puede lanzar las siguientes excepciones en caso de encontrar errores MalFormedXmlDatosException InvalidParameterValueException UnknownRespuestaCasillaNameException UnknownPeticionCasillaNameException

13 Página 13 de 59

14 Página 14 de CU-PPA-04: Verificar NRC Esta funcionalidad se permite realizar una solicitud de comprobación de validez de un NRC emitido por una entidad financiera. En caso de éxito en la invocación, devolverá un booleano indicando si el NRC es correcto o no Interfaz Entrada del servicio El parámetro de entrada que espera este método, es un xml con los datos básicos del NRC a verificar. Parámetro verificacionnrcxml Descripción String que contiene los datos necesarios para comprobar la validez del NRC

15 Página 15 de 59 El xml de entrada debe corresponderse con el siguiente esquema. peticion_verificacion.xsd <?xml version="1.0" encoding="utf-8" standalone="yes"?> <xs:schema version="1.0" xmlns:xs=" <xs:element name="peticionverificacion"> <xs:complextype > <xs:sequence> <xs:element name="idaplicacion" type="alfanumerico" minoccurs="1" /> <xs:element name="nrc" type="alfanumerico" minoccurs="1"/> <xs:element name="nif" type="alfanumerico" minoccurs="1"/> <xs:element name="importe" type="alfanumerico" minoccurs="1"/> <xs:element name="fechaoperacion" type="numerico" minoccurs="1"/> <xs:element name="codigoentidad" type="numerico" minoccurs="1"/> <xs:element name="tipooperacion" type="numerico" minoccurs="0" /> </xs:sequence> </xs:complextype> </xs:element> <xs:simpletype name="alfanumerico"> <xs:restriction base="xs:string"> <xs:minlength value="1" /> </xs:restriction> </xs:simpletype> <xs:simpletype name="numerico"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]+" /> </xs:restriction> </xs:simpletype> </xs:schema>

16 Página 16 de 59 Breve descripción de lo que se espera en cada elemento del xml. Nombre Tipo Descripción idaplicacion An(10) Código de la aplicación que realiza la invocación al servicio nrc N(22) NRC que se va a verificar nif AN(8) NIF del contribuyente que realizó el pago importe Número decimal Importe de la operación de pago fechaoperacion N(8) Fecha en la que se realizó la operación de pago, con el formato AAAAMMDD codigoentidad N(4) Código de la entidad financiera dada de alta en la Pasarela tipooperacion N(3) Tipo de operación que indica si la validación corresponde con una autoliquidación (001) o a una liquidación (002). Por defecto se tomará el valor 001. N Numérico An AlfaNumérico

17 Página 17 de 59 Un ejemplo típico de una invocación a esta operación es la que se muestra a continuación: Ejemplo de Entrada <soapenv:envelope xmlns:soapenv=" xmlns:pas=" <soapenv:header/> <soapenv:body> <pas:verificarnrc> <!--Optional:--> <verificacionnrcxml><![cdata[<?xml version="1.0" encoding="utf-8" standalone="yes"?> <peticionverificacion> <idaplicacion>appj</idaplicacion> <nrc> w827f28aa</nrc> <nif> h</nif> <importe>123.54</importe> <fechaoperacion> </fechaoperacion> <codigoentidad>6756</codigoentidad> <tipooperacion>001</tipooperacion> </peticionverificacion> ]]></verificacionnrcxml> </pas:verificarnrc> </soapenv:body> </soapenv:envelope> Salida del servicio A continuación se muestra el modelo de datos que devuelve el Servicio en respuesta a una invocación con éxito de esta operación.

18 Página 18 de 59 Un ejemplo típico de respuesta de esta operación es la que se muestra a continuación: Ejemplo de Salida <soapenv:envelope xmlns:soapenv=" <soapenv:body> <ns2:verificarnrcresponse xmlns:env=" xmlns:ns2=" <return>true</return> </ns2:verificarnrcresponse> </soapenv:body> </soapenv:envelope> Excepciones Este servicio puede lanzar las siguientes excepciones en caso de encontrar errores MalFormedXmlDatosException InvalidParameterValueException

19 Página 19 de CU-PPA-05: Obtener Versión del Servicio Este caso de uso permite averiguar la versión en formato YYYYMMDD del servicio web desplegado Interfaz Entrada del servicio. Este método no tiene parámetros de entrada. Un ejemplo típico de una invocación a esta operación es la que se muestra a continuación. Ejemplo de Entrada <soapenv:envelope xmlns:soapenv=" xmlns:pas=" <soapenv:header/> <soapenv:body> <pas:getversion/> </soapenv:body> </soapenv:envelope>

20 Página 20 de Salida del servicio Ejemplo de salida del servicio. <soapenv:envelope xmlns:soapenv=" <soapenv:body> <ns2:getversionresponse xmlns:env=" xmlns:ns2=" <return> </return> </ns2:getversionresponse> </soapenv:body> </soapenv:envelope>

21 Página 21 de CU-PPA-06: Realizar Pago Firmado Esta funcionalidad permite a los backoffices que se integren con PLATINO, la realización de un pago telemático. El usuario, a través de un formulario, introducirá y firmará los parámetros referentes al pago, y el sistema devolverá el resultado de la operación. Como novedad en esta versión, además de los pagos correspondiente a la norma 65 según, la especificación de Red.es, se incluyen los pagos que se aplican en el caso de los tributos municipales, en todas sus posibles modalidades: Modalidad 1: Tributos periódicos, liquidaciones y deudas no tributarias con comunicación previa de los conceptos y periodos de pago a las Entidades Colaboradoras. Modalidad 2: Tributos periódicos, liquidaciones y deudas no tributarias sin comunicación de conceptos y periodos de pago a las Entidades Colaboradoras. Modalidad 3: Autoliquidaciones. NOTA: Para la generación de los datos referentes al pago y su firma, consultar el apartado 5.2. Firma de un formulario Interfaz

22 Página 22 de Entrada del servicio A continuación se muestra el modelo de datos que se ha de utilizar cuando queremos invocar a la operación de pago: Parámetro datospagoxml firma norma Descripción String que contiene los datos de la solicitud del pago rellenas por el ciudadano Bytes de la firma en formato XML-Signature o firma CADES realizada por el usuario, del String datospagoxml. Norma en la que se va a realizar el pago, siguiend la especificación de Red.es. Estas pueden ser la norma 65 (NORMA65) o bien norma 60

23 Página 23 de 59 (NORMA60) modalidad En caso de tratarse de un pago bajo la norma 60, además se debe especificar la modalidad, que pueden ser 1, 2 o 3. Si se trata de un pago bajo la norma 65, este campo no se tiene en cuenta, por tanto puede dejarse vacío.

24 Página 24 de 59 Pagos bajo Norma65 Cuando el pago se realiza bajo la norma 65, el xml que llega en el parámetro datospagoxml, debe cumplir el siguiente esquema. peticion_norma65.xsd <?xml version="1.0" encoding="utf-8" standalone="yes"?> <xs:schema version="1.0" xmlns:xs=" <xs:element name="peticionnorma65"> <xs:complextype > <xs:sequence> <xs:element name="idaplicacion" type="alfanumerico" minoccurs="1" /> <xs:element name="codigoorganismo" type="numerico" minoccurs="1"/> <xs:element name="cpr" type="numerico" minoccurs="1"/> <xs:element name="importeoperacion" type="decimal" minoccurs="1"/> <xs:element name="codigoentidad" type="numerico" minoccurs="1"/> <xs:element name="acreditacionterceros" type="numerico" minoccurs="1"/> <xs:element name="mediopago" type="numerico" minoccurs="1"/> <xs:element name="numeromediopago" type="numerico" minoccurs="1"/> <xs:element name="primerrepresentante" type="alfanumerico" minoccurs="0"/> <xs:element name="nifprimerrepresentante" type="alfanumerico" minoccurs="0"/> <xs:element name="segundorepresentante" type="alfanumerico" minoccurs="0"/> <xs:element name="nifsegundorepresentante" type="alfanumerico" minoccurs="0"/> <xs:element name="modelo" type="numerico" minoccurs="1"/> <xs:element name="concepto" type="numerico" minoccurs="1"/> <xs:element name="ejercicio" type="numerico" minoccurs="0"/> <xs:element name="periodo" type="alfanumerico" minoccurs="0"/> <xs:element name="justificante" type="numerico" minoccurs="1"/> <xs:element name="anagrama" type="alfanumerico" minoccurs="1"/> <xs:element name="codigoterritorial" type="alfanumerico" minoccurs="0"/> <xs:element name="fechadevengo" type="numerico" minoccurs="0"/> <xs:element name="contribuyente" type="alfanumerico" minoccurs="1"/> <xs:element name="nifcontribuyente" type="alfanumerico" minoccurs="1"/> <xs:element name="nifsolicitante" type="alfanumerico" minoccurs="0"/> <xs:element name="info" type="alfanumerico" minoccurs="0"/> <xs:element name="datosorganismo" type="alfanumerico" minoccurs="0"/> </xs:sequence> </xs:complextype> </xs:element> <xs:simpletype name="alfanumerico"> <xs:restriction base="xs:string"> <xs:minlength value="1" /> </xs:restriction> </xs:simpletype> <xs:simpletype name="numerico"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]+" /> </xs:restriction> </xs:simpletype> <xs:simpletype name="decimal"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]+(\.[0-9]+)?" /> </xs:restriction>

25 Página 25 de 59 </xs:schema> </xs:simpletype> La descripción de cada uno de los elementos descritos en el XSD es la siguiente: NOMBRE TIPO DESCRIPCIÓN idaplicacion An(10) Código de la aplicación que realiza la invocación al servicio codigoorganismo N(5) Organismo admitido en la Pasarela cpr N(7) Código de procedimiento de recaudación del pago. importeoperacion Número decimal Importe de la operación de pago codigoentidad An(4) Código de la entidad financiera dada de alta en la Pasarela ( ⁴) acreditacionterceros N(1) Indica si el representante está autorizado a realizar el pago en nombre del contribuyente. ( ² ) mediopago N(1) Identificador medio de pago: 1 = Cargo en cuenta 2 = Pago con tarjeta numeromediopago N(20) En el caso de pagos en cuenta corriente, se corresponde con el CCC donde se hará el cargo. El formato a seguir es N(20) En el caso de pagos con tarjeta, se compone del número de la tarjeta, seguida por el mes y año de caducidad. Se debe seguir este formato N(16)MMAA primerrepresentante An(40) Apellidos y nombre del primer representante (titular de la cuenta) nifprimerrepresentante AN(8) NIF/CIF/NIE del primer representante (titular de la cuenta) segundorepresentante An(40) Apellidos y nombre del segundo representante nifsegundorepresentante AN(8) NIF/CIF/NIE del segundo representante modelo N(3) Modelo admitido por la Pasarela para el Organismo

26 Página 26 de 59 indicado concepto N(4) Concepto correspondiente al Modelo y al Organismo indicado ejercicio N(4) Valor del ejercicio fiscal con formato AAAA periodo N(2) Valor del periodo con formato MM (9) justificante N(13) Número de justificante que identifica unívocamente la operación de pago. ( ⁵) anagrama An(4) Anagrama fiscal del contribuyente. (Si no se aporta, la pasarela asigna el valor 0000). codigoterritorial An(6) Valor del código territorial. fechadevengo N(8) Fecha de devengo con formato AAAAMMDD contribuyente An(40) Apellidos y nombres del contribuyente nifcontribuyente AN(8) NIF del contribuyente nifsolicitante AN(8) NIF del solicitante del pago ( ³ ) info An(25) Reservada para información específica datosorganismo An(59) Reservada para el uso del organismo N Numérico An AlfaNumérico ( ¹ ) Los tipos de trama válidos son los siguientes: 1, correspondiente a la TRAMA60 de Red.es. 2, correspondiente a la TRAMA65 de Red.es. En caso de no especificarse ninguna, se utilizará por defecto la trama 2. En caso de especificar otro valor, se devolverá un código de respuesta TT, correspondiente a un tipo de trama desconocida. ( ² ) Los posibles valores para este elemento son: 1 = tercero autorizado. 0 = tercero no autorizado.

27 Página 27 de 59 Si no se aporta ninguno, la pasarela lo asigna automáticamente siguiendo el siguiente patrón: si el NIF del firmante es igual al NIF del Contribuyente, asigna valor 0. Si el NIF del firmante es diferente al NIF del Contribuyente, asigna valor 1. ( ³ ) Si no se indica ningún valor se tomará por defecto el siguiente: Si se especifica el NIF del primer representante, se tomará ese valor. Si no se especifica el NIF del primer representante, entonces se utilizará el NIF del contribuyente. ( ⁴ ) Si no se indica ningún valor se tomará el código de organismo o se determinará a través del número del medio de pago. ( ⁵ ) Este campo tiene la siguiente forma: [MMMYZZZZZZZZD], siendo: "M : modelo Y : indicador de datos a obtener pudiendo tomar los siguientes valores: 0: No se obtienen datos opcionales 1: Expediente 2: Fecha de devengo 3: Expediente y fecha de devengo 4: Datos específicos 5: Expediente y datos específicos 6: Fecha de devengo y datos específicos 7: Fecha de devengo, datos específicos y expediente Z : número secuencial D : dígito de control

28 Página 28 de 59 Pagos bajo Norma60 modalidad 1 y 2 Cuando el pago se realiza bajo la norma 60 y la modalidad 1 o 2, el xml que llega en el parámetro datospagoxml, debe cumplir el siguiente esquema. peticion_norma60_modalidad1y2.xsd <?xml version="1.0" encoding="utf-8" standalone="yes"?> <xs:schema version="1.0" xmlns:xs=" <xs:element name="peticionnorma60modalidad1y2"> <xs:complextype > <xs:sequence> <xs:element name="idaplicacion" type="alfanumerico" minoccurs="1" /> <xs:element name="modelo" type="numerico" minoccurs="1"/> <xs:element name="concepto" type="numerico" minoccurs="1"/> <xs:element name="nifcontribuyente" type="alfanumerico" minoccurs="1"/> <xs:element name="cpr" type="numerico" minoccurs="1"/> <xs:element name="mediopago" type="numerico" minoccurs="1"/> <xs:element name="numeromediopago" type="numerico" minoccurs="1"/> <xs:element name="importeoperacion" type="decimal" minoccurs="1"/> <xs:element name="nifprimerrepresentante" type="alfanumerico" minoccurs="0"/> <xs:element name="primerrepresentante" type="alfanumerico" minoccurs="0"/> <xs:element name="nifsegundorepresentante" type="alfanumerico" minoccurs="0"/> <xs:element name="segundorepresentante" type="alfanumerico" minoccurs="0"/> <xs:element name="codigoorganismo" type="numerico" minoccurs="1"/> <xs:element name="justificante" type="numerico" minoccurs="1"/> <xs:element name="primeraparteidentificacion" type="numerico" minoccurs="1"/> <xs:element name="segundaparteidentificacion" type="numerico" minoccurs="1"/> <xs:element name="domiciliacion" type="numerico" minoccurs="0"/> <xs:element name="cccdomiciliacion" type="numerico" minoccurs="0"/> <xs:element name="reservada" type="alfanumerico" minoccurs="0"/> <xs:element name="codigoentidad" type="numerico" minoccurs="0"/> </xs:sequence> </xs:complextype> </xs:element> <xs:simpletype name="alfanumerico"> <xs:restriction base="xs:string"> <xs:minlength value="1" /> </xs:restriction> </xs:simpletype> <xs:simpletype name="numerico"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]+" /> </xs:restriction> </xs:simpletype> <xs:simpletype name="decimal"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]+(\.[0-9]+)?" /> </xs:restriction> </xs:simpletype> </xs:schema>

29 Página 29 de 59 A continuación vemos una breve descripción de lo que se espera en cada uno de los elementos del xml datospagoxml. NOMBRE TIPO DESCRIPCIÓN idaplicacion An(10) Código de la aplicación que realiza la invocación al servicio modelo N(3) Modelo admitido por la Pasarela para el Organismo indicado concepto N(4) Concepto correspondiente al Modelo y al Organismo indicado nifcontribuyente AN(8) NIF del contribuyente cpr N(7) Código de procedimiento de recaudación del pago. mediopago N(1) Identificador medio de pago: 1 = Cargo en cuenta 2 = Pago con tarjeta numeromediopago N(20) En el caso de pagos en cuenta corriente, se corresponde con el CCC donde se hará el cargo. El formato a seguir es N(20) En el caso de pagos con tarjeta, se compone del número de la tarjeta, seguida por el mes y año de caducidad. Se debe seguir este formato N(16)MMAA importeoperacion Número decimal Importe de la operación de pago primerrepresentante An(40) Apellidos y nombre del primer representante (titular de la cuenta) ( ² ) nifprimerrepresentante AN(8) NIF/CIF/NIE del primer representante (titular de la cuenta) ( ² ) segundorepresentante An(40) Apellidos y nombre del segundo representante ( ³ ) nifsegundorepresentante AN(8) NIF/CIF/NIE del segundo representante ( ³ ) codigoorganismo N(5) Organismo admitido en la Pasarela justificante N(13) Número de justificante que identifica unívocamente la operación de pago ( ⁶)

30 Página 30 de 59 primeraparteidentificacion N(3) Primera parte de la identificación segundaparteidentificacion N(7) Segunda parte de la identificación domiciliacion N(1) Opción de domiciliación. Sí: 1, No: 2 ( ⁴) cccdomiciliacion N(20) Código de Cuenta Cliente de la domiciliación ( ⁴) reservada An(54) Casilla reservada para el uso del organismo codigoentidad An(4) Código de la entidad financiera dada de alta en la Pasarela ( ⁵) N Numérico An AlfaNumérico ( ¹ ) Los tipos de trama válidos son los siguientes: 1, correspondiente a la TRAMA60 de Red.es. 2, correspondiente a la TRAMA65 de Red.es. En caso de no especificarse ninguna, se utilizará por defecto la trama 2. En caso de especificar otro valor, se devolverá un código de respuesta TT, correspondiente a un tipo de trama desconocida. ( ² ) Existe una relación entre el NIF del primer representante y su nombre y apellido, por lo tanto, ambos deben tener valores válidos o en caso contrario, ninguno. Si uno solo de ellos presenta un valor válido, la petición se invalidará. ( ³ ) Con los campos NIF del segundo representante y su nombre y apellido, ocurre lo mismo que en el punto ( ² ) ( ⁴ ) Con los campos domiciliación y CCC domiciliación, ocurre lo mismo que en el punto ( ² ) ( ⁵ ) Si no se indica ningún valor se tomará el código de organismo o se determinará a través del número del medio de pago. ( ⁶ ) Este campo tiene la siguiente forma: [MMMYZZZZZZZZD], siendo: "M : modelo Y : indicador de datos a obtener pudiendo tomar los siguientes valores:

31 Página 31 de 59 0: No se obtienen datos opcionales 1: Expediente 2: Fecha de devengo 3: Expediente y fecha de devengo 4: Datos específicos 5: Expediente y datos específicos 6: Fecha de devengo y datos específicos 7: Fecha de devengo, datos específicos y expediente Z : número secuencial D : dígito de control

32 Página 32 de 59 Pagos bajo Norma60 modalidad 3 Cuando el pago se realiza bajo la norma 60, modalidad 3, el xml que llega en el parámetro datospagoxml, debe cumplir el siguiente esquema. peticion_norma60_modalidad3.xsd <?xml version="1.0" encoding="utf-8" standalone="yes"?> <xs:schema version="1.0" xmlns:xs=" <xs:element name="peticionnorma60modalidad3"> <xs:complextype > <xs:sequence> <xs:element name="idaplicacion" type="alfanumerico" minoccurs="1" /> <xs:element name="modelo" type="numerico" minoccurs="1"/> <xs:element name="concepto" type="numerico" minoccurs="1"/> <xs:element name="nifcontribuyente" type="alfanumerico" minoccurs="1"/> <xs:element name="nifsolicitante" type="alfanumerico" minoccurs="0"/> <xs:element name="cpr" type="numerico" minoccurs="1"/> <xs:element name="mediopago" type="numerico" minoccurs="1"/> <xs:element name="numeromediopago" type="numerico" minoccurs="1"/> <xs:element name="importeoperacion" type="decimal" minoccurs="1"/> <xs:element name="nifprimerrepresentante" type="alfanumerico" minoccurs="1"/> <xs:element name="primerrepresentante" type="alfanumerico" minoccurs="1"/> <xs:element name="nifsegundorepresentante" type="alfanumerico" minoccurs="0"/> <xs:element name="segundorepresentante" type="alfanumerico" minoccurs="0"/> <xs:element name="codigoorganismo" type="numerico" minoccurs="1"/> <xs:element name="numeroexpediente" type="alfanumerico" minoccurs="0"/> <xs:element name="justificante" type="numerico" minoccurs="1"/> <xs:element name="fechadevengo" type="numerico" minoccurs="0"/> <xs:element name="datosespecificos" type="alfanumerico" minoccurs="0"/> <xs:element name="reservada" type="alfanumerico" minoccurs="0"/> <xs:element name="codigoentidad" type="numerico" minoccurs="0"/> </xs:sequence> </xs:complextype> </xs:element> <xs:simpletype name="alfanumerico"> <xs:restriction base="xs:string"> <xs:minlength value="1" /> </xs:restriction> </xs:simpletype> <xs:simpletype name="numerico"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]+" /> </xs:restriction> </xs:simpletype> <xs:simpletype name="decimal"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]+(\.[0-9]+)?" /> </xs:restriction> </xs:simpletype> </xs:schema>

33 Página 33 de 59 A continuación vemos una breve descripción de lo que se espera en cada uno de los elementos del xml datospagoxml. NOMBRE TIPO DESCRIPCIÓN idaplicacion An(10) Código de la aplicación que realiza la invocación al servicio modelo N(3) Modelo admitido por la Pasarela para el Organismo indicado concepto N(4) Concepto correspondiente al Modelo y al Organismo indicado nifcontribuyente AN(8) NIF del contribuyente nifsolicitante AN(8) NIF del solicitante del pago ( ⁶) cpr N(7) Código de procedimiento de recaudación del pago. mediopago N(1) Identificador medio de pago: 1 = Cargo en cuenta 2 = Pago con tarjeta numeromediopago N(20) En el caso de pagos en cuenta corriente, se corresponde con el CCC donde se hará el cargo. El formato a seguir es N(20) En el caso de pagos con tarjeta, se compone del número de la tarjeta, seguida por el mes y año de caducidad. Se debe seguir este formato N(16)MMAA importeoperacion Número decimal Importe de la operación de pago primerrepresentante An(40) Apellidos y nombre del primer representante (titular de la cuenta) ( ² ) nifprimerrepresentante AN(8) NIF/CIF/NIE del primer representante (titular de la cuenta) ( ² ) segundorepresentante An(40) Apellidos y nombre del segundo representante ( ³ ) nifsegundorepresentante AN(8) NIF/CIF/NIE del segundo representante ( ³ ) codigoorganismo N(5) Organismo admitido en la Pasarela

34 Página 34 de 59 numeroexpediente N(12) Número de expediente correspondiente al pago ( ⁵) justificante N(13) Número de justificante que identifica unívocamente la operación de pago. ( ⁴) fechadevengo N(8) Fecha de devengo con formato AAAAMMDD ( ⁵) datosespecificos An(20) Datos específicos sobre el pago ( ⁵) reservada An(55) Casilla reservada para el uso del organismo codigoentidad An(4) Código de la entidad financiera dada de alta en la Pasarela ( ⁷) N Numérico An AlfaNumérico ( ¹ ) Los tipos de trama válidos son los siguientes: 1, correspondiente a la TRAMA60 de Red.es. 2, correspondiente a la TRAMA65 de Red.es. En caso de no especificarse ninguna, se utilizará por defecto la trama 2. En caso de especificar otro valor, se devolverá un código de respuesta TT, correspondiente a un tipo de trama desconocida. ( ² ) Existe una relación entre el NIF del primer representante y su nombre y apellido, por lo tanto, ambos deben tener valores válidos o en caso contrario, ninguno. Si uno solo de ellos presenta un valor válido, la petición se invalidará. ( ³ ) Con los campos NIF del segundo representante y su nombre y apellido, ocurre lo mismo que en el punto ( ² ) ( ⁴ ) Este campo tiene la siguiente forma: [MMMYZZZZZZZZD], siendo: "M : modelo Y : indicador de datos a obtener pudiendo tomar los siguientes valores: 0: No se obtienen datos opcionales 1: Expediente 2: Fecha de devengo 3: Expediente y fecha de devengo 4: Datos específicos

35 Página 35 de 59 5: Expediente y datos específicos 6: Fecha de devengo y datos específicos 7: Fecha de devengo, datos específicos y expediente Z : número secuencial D : dígito de control ( ⁵ ) Dependiendo del carácter indicador de datos a capturar existente en el número del justificante, este campo puede ser obligatorio. ( ⁶ ) Si no se indica ningún valor se tomará por defecto el siguiente: Si se especifica el NIF del primer representante, se tomará ese valor. Si no se especifica el NIF del primer representante, entonces se utilizará el NIF del contribuyente. ( ⁷ ) Si no se indica ningún valor se tomará el código de organismo o se determinará a través del número del medio de pago. Un ejemplo típico de una invocación a esta operación es la que se muestra a continuación. En este caso, vemos la realización de un pago en norma 65. Ejemplo de Entrada <soapenv:envelope xmlns:soapenv=" xmlns:pas=" <soapenv:header/> <soapenv:body> <pas:pagofirmado> <datospagoxml><![cdata[<?xml version="1.0" encoding="utf-8" standalone="yes"?> <peticionnorma65> <idaplicacion>appj</idaplicacion> <codigoorganismo>62005</codigoorganismo> <cpr> </cpr> <importeoperacion>12.45</importeoperacion> <codigoentidad>6756</codigoentidad> <acreditacionterceros>1</acreditacionterceros> <mediopago>2</mediopago> <numeromediopago> </numeromediopago> <primerrepresentante>ramon Perez</primerRepresentante> <nifprimerrepresentante> a</nifprimerrepresentante> <segundorepresentante>carlos Gomez</segundoRepresentante> <nifsegundorepresentante> p</nifsegundorepresentante> <modelo>123</modelo> <concepto>1234</concepto> <ejercicio>2011</ejercicio> <periodo>11</periodo> <justificante> </justificante> <anagrama>anag</anagrama> <codigoterritorial>125000</codigoterritorial> <contribuyente>raul Gonzalez</contribuyente> <nifcontribuyente> h</nifcontribuyente> <nifsolicitante> j</nifsolicitante>

36 Página 36 de 59 <info>info</info> <datosorganismo>datos ORGANISMO</datosOrganismo> </peticionnorma65>]]></datospagoxml> <firma>pd94bwwgdmvyc2lvbj0ims4...</firma> <norma>norma65</norma> </pas:pagofirmado> </soapenv:body> </soapenv:envelope> Salida del servicio El método en cuestión, devolverá un objeto tipo PeticionResponse, con los datos de la respuesta que llega desde la Pasarela de Pagos. Este es el mismo objecto para todas las normas y modalidades posibles. La diferencia se encuentra en los atributos que poseen valores y en aquellos que no.

37 Página 37 de 59 A continuación vemos los valores que podemos esperar en cada uno de los tipos de pago.

38 Página 38 de 59 Respuesta de un pago bajo Norma65 NOMBRE codigorespuesta descripcionrespuesta cpr tipopeticion mediopago numeromediopago importeoperacion nifprimerrepresentante nifsegundorepresentante contribuyente primerrepresentante segundorepresentante codigoorganismo modelo ejercicio periodo nifcontribuyente nifsolicitante anagrama DESCRIPCIÓN Código de respuesta devuelto por la Pasarela de Pagos Descripción de la respuesta devuelta por la Pasarela de Pagos Código de procedimiento de recaudación del pago. Tipo de petición, devuelto por la EEFF (alta de un pago) Identificador medio de pago: 1 = Cargo en cuenta 2 = Pago con tarjeta En el caso de pagos en cuenta corriente, se corresponde con el CCC donde se hará el cargo. El formato a seguir es N(20) En el caso de pagos con tarjeta, se compone del número de la tarjeta, seguida por el mes y año de caducidad. Se debe seguir este formato N(16)MMAA Importe de la operación de pago NIF/CIF/NIE del primer representante (titular de la cuenta) NIF/CIF/NIE del segundo representante Apellidos y nombres del contribuyente Apellidos y nombre del primer representante (titular de la cuenta) Apellidos y nombre del segundo representante Organismo admitido en la Pasarela Modelo admitido por la Pasarela para el Organismo indicado Valor del ejercicio fiscal con formato AAAA Valor del periodo con formato MM NIF del contribuyente NIF del solicitante del pago Anagrama fiscal del contribuyente

39 Página 39 de 59 codigoterritorial fechadevengo justificante info conceptoautoliquidacion datosorganismo acreditacionterceros nrc codigoretorno fechaoperacion Valor del código territorial Fecha de devengo con formato AAAAMMDD Número de justificante que identifica unívocamente la operación de pago. Reservada para información específica Concepto de la autoliquidación Reservada para el uso del organismo Indica si el representante está autorizado a realizar el pago en nombre del contribuyente. 1 = tercero autorizado. 0 = tercero no autorizado. NRC correspondiente a la operación de pago Código de retorno de la entidad financiera Fecha de la operación Respuesta de un pago bajo Norma60 modalidad 1 y 2 NOMBRE codigorespuesta descripcionrespuesta nifcontribuyente cpr tipopeticion mediopago DESCRIPCIÓN Código de respuesta devuelto por la Pasarela de Pagos Descripción de la respuesta devuelta por la Pasarela de Pagos NIF del contribuyente Código de procedimiento de recaudación del pago. Tipo de petición, devuelto por la EEFF (alta de un pago) Identificador medio de pago: 1 = Cargo en cuenta 2 = Pago con tarjeta

40 Página 40 de 59 numeromediopago importeoperacion nifprimerrepresentante nifsegundorepresentante primerrepresentante segundorepresentante codigoorganismo justificante primeraparteidentificacion segundaparteidentificacion En el caso de pagos en cuenta corriente, se corresponde con el CCC donde se hará el cargo. El formato a seguir es N(20) En el caso de pagos con tarjeta, se compone del número de la tarjeta, seguida por el mes y año de caducidad. Se debe seguir este formato N(16)MMAA Importe de la operación de pago NIF/CIF/NIE del primer representante (titular de la cuenta) NIF/CIF/NIE del segundo representante Apellidos y nombre del primer representante (titular de la cuenta) Apellidos y nombre del segundo representante Organismo admitido en la Pasarela Número de justificante que identifica unívocamente la operación de pago. Primera parte de la identificación Segunda parte de la identificación domiciliacion Opción de domiciliación. Sí: 1, No: 2 cccdomiciliacion reservada nrc fechaoperacion codigoretorno Código de Cuenta Cliente de la domiciliación Casilla reservada para el uso del organismo NRC correspondiente a la operación de pago Fecha de la operación Código de retorno de la entidad financiera Respuesta de un pago bajo Norma60 modalidad 3 NOMBRE codigorespuesta DESCRIPCIÓN Código de respuesta devuelto por la Pasarela de Pagos

41 Página 41 de 59 descripcionrespuesta nifcontribuyente nifsolicitante cpr tipopeticion mediopago numeromediopago importeoperacion nifprimerrepresentante nifsegundorepresentante primerrepresentante segundorepresentante codigoorganismo numeroexpediente justificante modelo fechadevengo datosespecificos reservada nrc fechaoperacion Descripción de la respuesta devuelta por la Pasarela de Pagos NIF del contribuyente NIF del solicitante del pago Código de procedimiento de recaudación del pago. Tipo de petición, devuelto por la EEFF (alta de un pago) Identificador medio de pago: 1 = Cargo en cuenta 2 = Pago con tarjeta En el caso de pagos en cuenta corriente, se corresponde con el CCC donde se hará el cargo. El formato a seguir es N(20) En el caso de pagos con tarjeta, se compone del número de la tarjeta, seguida por el mes y año de caducidad. Se debe seguir este formato N(16)MMAA Importe de la operación de pago NIF/CIF/NIE del primer representante (titular de la cuenta) NIF/CIF/NIE del segundo representante Apellidos y nombre del primer representante (titular de la cuenta) Apellidos y nombre del segundo representante Organismo admitido en la Pasarela Número de expediente correspondiente al pago Número de justificante que identifica unívocamente la operación de pago. Modelo admitido por la Pasarela para el Organismo indicado Fecha de devengo con formato AAAAMMDD Datos específicos sobre el pago Casilla reservada para el uso del organismo NRC correspondiente a la operación de pago Fecha de la operación

42 Página 42 de 59 codigoretorno Código de retorno de la entidad financiera Un ejemplo típico de respuesta de esta operación es la que se muestra a continuación: Ejemplo de Salida <soapenv:envelope xmlns:soapenv=" <soapenv:body> <ns2:pagofirmadoresponse xmlns:env=" xmlns:ns2=" <return> <acreditacionterceros></acreditacionterceros> <anagrama>anag</anagrama> <codigoorganismo>62005</codigoorganismo> <codigorespuesta>ok</codigorespuesta> <codigoretorno>00</codigoretorno> <codigoterritorial>125000</codigoterritorial> <conceptoautoliquidacion></conceptoautoliquidacion> <cpr> </cpr> <datosorganismo>datos ORGANISMO</datosOrganismo> <descripcionrespuesta>operacion finalizada OK</descripcionRespuesta> <ejercicio>2011</ejercicio> <fechadevengo> </fechadevengo> <fechaoperacion></fechaoperacion> <idpasarela>01</idpasarela> <importeoperacion> </importeoperacion> <info></info> <justificante> </justificante> <mediopago>2</mediopago> <modelo>123</modelo> <nifcontribuyente> h</nifcontribuyente> <nifprimerrepresentante> a</nifprimerrepresentante> <nifsegundorepresentante> p</nifsegundorepresentante> <nifsolicitante> j</nifsolicitante> <nombrecontribuyente>raul Gonzalez</nombreContribuyente> <nrc> w8e8df347</nrc> <numeromediopago> </numeromediopago> <periodo>11</periodo> <primerrepresentante>ramon Perez</primerRepresentante> <segundorepresentante>carlos Gomez</segundoRepresentante> <tipopeticion>01</tipopeticion> </return> </ns2:pagofirmadoresponse> </soapenv:body> </soapenv:envelope>

43 Página 43 de Excepciones Este servicio puede lanzar las siguientes excepciones en caso de encontrar errores MalFormedXmlDatosException InvalidParameterValueException UnknownPeticionCasillaNameException UnknownRespuestaCasillaNameException ExcepcionPasarelaFirmaInvalida ExcepcionPasarelaErrorFirma

44 Página 44 de CU-PPA-07: Realizar Consulta Firmada Esta funcionalidad permite a los backoffices que se integren con PLATINO, la realización de una consulta sobre un determinado pago realizado con anterioridad. El usuario, a través de un formulario, introducirá y firmará los parámetros referentes a la consulta, y el sistema devolverá el resultado de la operación. NOTA: Para la generación de los datos referentes a la consulta y su firma, consultar el apartado 5.2. Firma de un formulario. De cara al cliente, este método se comporta de la misma forma que lo hace pagofirmado. Admite los mismos parámetros de entrada y devuelve los mismos objetos con los mismos valores. Por tanto, para su comprensión detallada, remítase al apartado CU-PPA-06: Realizar Pago Firmado

45 Página 45 de CU-PPA-08: Obtener Datos Concepto Este caso de uso da la opción a los ciudadanos de obtener información sobre la descripción de un concepto asociado a un par modelo/concepto, admitido en la Pasarela de Pagos Interfaz Entrada del servicio La entrada del servicio, es un xml que contiene la información necesaria para acceder a la descripción de un Concepto. Parámetro datosconceptoxml Descripción String que contiene el par modelo/concepto que identifica al Concepto en cuestión.

46 Página 46 de 59 Dicho xml, debe seguir el siguiente esquema. peticion_concepto.xsd <?xml version="1.0" encoding="utf-8" standalone="yes"?> <xs:schema version="1.0" xmlns:xs=" <xs:element name="peticionobtenerconcepto"> <xs:complextype > <xs:sequence> <xs:element name="idaplicacion" type="alfanumerico" minoccurs="1" /> <xs:element name="modelo" type="numerico" minoccurs="1"/> <xs:element name="concepto" type="numerico" minoccurs="1"/> </xs:sequence> </xs:complextype> </xs:element> <xs:simpletype name="alfanumerico"> <xs:restriction base="xs:string"> <xs:minlength value="1" /> </xs:restriction> </xs:simpletype> <xs:simpletype name="numerico"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]+" /> </xs:restriction> </xs:simpletype> </xs:schema>

47 Página 47 de 59 Breve descripción de lo que se espera en cada elemento del xml. Nombre Tipo Descripción idaplicacion An(10) Código de la aplicación que realiza la invocación al servicio modelo N(3) Modelo admitido por la Pasarela para el Organismo indicado concepto N(4) Concepto correspondiente al Modelo y al Organismo indicado Un ejemplo típico de una invocación a esta operación es la que se muestra a continuación: Ejemplo de Entrada <soapenv:envelope xmlns:soapenv=" xmlns:pas=" <soapenv:header/> <soapenv:body> <pas:obtenerdatosconcepto> <datosconceptoxml><![cdata[<?xml version="1.0" encoding="utf-8" standalone="yes"?> <peticionobtenerconcepto> <idaplicacion>appj</idaplicacion> <modelo>123</modelo> <concepto>1234</concepto> </peticionobtenerconcepto> ]]></datosconceptoxml> </pas:obtenerdatosconcepto> </soapenv:body> </soapenv:envelope> Salida del servicio A continuación se muestra el modelo de datos que devuelve el Servicio en respuesta a una invocación con éxito de esta operación.

48 Página 48 de 59 Un ejemplo típico de respuesta de esta operación es la que se muestra a continuación: Ejemplo de Salida <soapenv:envelope xmlns:soapenv=" <soapenv:body> <ns2:obtenerdatosconceptoresponse xmlns:env=" xmlns:ns2=" <return> <codigorespuesta>ok</codigorespuesta> <codigoretorno>ok</codigoretorno> <descripcionconcepto>concepto 1234</descripcionConcepto> <descripcionrespuesta>operacion finalizada OK</descripcionRespuesta> </return> </ns2:obtenerdatosconceptoresponse> </soapenv:body> </soapenv:envelope>

49 Página 49 de Excepciones Este servicio puede lanzar las siguientes excepciones en caso de encontrar errores MalFormedXmlDatosException InvalidParameterValueException UnknownRespuestaCasillaNameException UnknownPeticionCasillaNameException

50 Página 50 de 59 4 EXCEPCIONES Para que los clientes tengan más conocimiento de lo que ocurre cuando se encuentra algún error, se ha planteado un pequeño control de errores basados en excepciones. Cada vez que algo vaya mal en las invocaciones a los distintos métodos, el servicio de Pasarela de Pagos devolverá una excpeción concreta, que ayudará a determinar más fehacientemente el motivo del error. A continuación, vemos explicadas más en detalle todas las excepciones que se pueden encontrar. 4.1 InvalidParameterValueException Esta excepción se lanza cuando alguno de los parámetros de entrada es inválido. Cabe destacar que no se hace una comprobación exhaustiva de todos los parámetros. Por ejemplo, aquellos que vengan dentro de los xml, se delegan a la propia aplicación de Pasarela de Pagos. Si se encontrase un error en este punto, esta devolverá una respuesta con su correspondiente código de error. 4.2 MalFormedXmlDatosException Cada vez que se recibe un parámetro en forma de xml, a este se le aplica una operación de unmarshalling, para obtener un objeto de dominio con el que se pueda trabajar más fácilmente. Es en este proceso donde se realiza la validación con el esquema correspondiente. Si ocurre algún tipo de error, una excepción del tipo MalFormedXmlDatosException es lanzada. 4.3 UnknownRespuestaCasillaNameException

51 Página 51 de 59 Una vez que la aplicación de Pasarela de Pagos devuelve una respuesta, ya sea por un pago o consulta, esta es transformada a un objeto de dominio propio, que posteriormente será devuelto al cliente que realizó la petición. Si en este proceso de traducción se encuentra algún error, una excepción tipo UnknownRespuestaCasillaNameException es lanzada. Cabe mencionar que el consumidor no interviene en este proceso. Quien realmente lo hace es la aplicación de Pasarela de Pagos y la fachada que facilita la comunicación con ella. Por tanto, nunca se debería lanzar una excepción como esta. En tal caso, se deberá comunicar inmediatamente a la OTP. 4.4 UnknownPeticionCasillaNameException Al igual que sucedía con la excepción anterior, esta es lanzada únicamente si se produce un error interno en uno de los procesos de traducción entre objetos de dominio propios y objetos que espera recibir la Pasarela de Pagos. De igual forma, nunca se debería de obtener una excepción de este tipo. De ser así, póngase en contacto con la OTP. 4.5 ExcepcionPasarelaFirmaInvalida Esta excepción será lanzada, cuando la firma del xml que se recibe como parámetro, no sea válida. 4.6 ExcepcionPasarelaErrorFirma Esta excepción será lanzada cuando se encuentre algún error en el proceso de verificación de la firma o en el momento de extraer el NIF del firmante del certificado.

52 Página 52 de 59

53 Página 53 de 59 5 INFORMACIÓN ADICIONAL DEL SERVICIO 5.1 Códigos de respuesta de la Pasarela de Pagos A continuación se presentan todos los valores de código de respuesta, que se contemplan como propios de la aplicación de Pasarela de Pagos. Estos son devueltos en el objeto PeticionResponse, en el atributo codigorespuesta. CÓDIGO RESPUESTA OK ED NA EP EC TR ET EH EM EO DESCRIPCIÓN Operación finalizada OK Error por EEFF desconocida en la PPA Error de acceso no autorizado a la PPA Error desconocido en la PPA Error de conexión con EEFF Error de conexión con EEFF por timeout de espera expirado Error debido a motivos técnicos Error por EEFF en horario de fuera de servicio Error por modelo/concepto desconocido Error por Organismo / Administración desconocido en la Pasarela de Pagos EV Error al validar parámetros de la petición ( ¹ ) EN Error al validar el NRC recibido de una EEFF después de una operación de pago EF Error devuelto y controlado por la EEFF ( ² ) TT AO Error por tipo de trama incorrecto o no especificado Error entre la relación de aplicación y organismo seleccionado

54 Página 54 de Códigos de retorno de la entidades financieras A continuación se presentan aquellos valores de código de retorno devueltos por las entidades financieras para una operación ya sea de consulta o de pago. Su contenido tendrá significado únicamente en los siguientes casos: Cuando para una operación de pago se obtenga de la pasarela un codigorespuesta con valor EF Cuando para una operación de consulta se obtenga de la pasarela un codigorespuesta con valor 00 En ambos casos el significado de los códigos de retorno son los que se muestran a continuación: CÓDIGO RETORNO DESCRIPCIÓN 00 Operación finalizada OK 1 Número de justificante o importe erróneo o ausente Modelo o tipo de operación no soportado Solicitud anulada El certificado firmante no está autorizado para realizar el pago por personas ajenas El representante del certificado firmante no está autorizado para realizar el pago por personas ajenas El certificado firmante no está autorizado para pagar y presentar este modelo El certificado firmante no está autorizado para realizar este pago por convenio La entidad emisora de esta tarjeta no admite este tipo de servicio