Aceptar Cobros
Para empezar a realizar cobros con nuestra solución de presencial deberá tener un dispositivo de PIN Pad, una instalación correcta de DeviceHub con su configuración correspondiente. Programáticamente deberás integrar al menos estos tres mensajes XMLs:
- InitializeDevice: permite inicializar el dispositivo.
- GetNextMessage: iterador de los mensajes en cola del dispositivo y del procesamiento.
- BeginSellTransaction: enviar orden de cobro al PIN Pad.
Debes tener presente que la integración es asíncrona, es decir, al enviar una llamada XML normalmente el DeviceHub nos responderá si ha recibido la llamada correctamente pero no responderá con el resultado de una operación. La única excepción es la llamada GetNextMessage que es precisamente la que está pensada para recorrer los mensajes de la cola asíncrona.
Las llamadas API serán peticiones HTTP POST a un la dirección TCP/IP donde está instalado el DeviceHub. Normalmente esta dirección será:
POST http://localhost:17000
La estructura de los mensajes XML intercambiados tiene datos comunes, tanto en la petición como en la respuesta. A continuación incluimos unos prototipos genéricos de mensajes
Petición genérica
En este caso hemos elegido el nombre ficticio de FunctionCallRequest para prototipar una llamada que nos ayude con la explicación.
- ClientIdValue: identificador numérico proporcionado por Sipay que identifica al cliente
- StoreIdValue: identificador numérico proporcionado por Sipay que identifica el establecimiento
- PosIdValue: identificador alfanumérico del punto de venta y configurable por el Comercio.
- Idioma: código del idioma de la mensajería de integración. 0 es castellano.
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:tem="http://tempuri.org/">
<soap:Header/>
<soap:Body>
<tem:FunctionCallRequest>
<tem:Header>
<tem:ClientId>ClientIdValue</tem:ClientId>
<tem:StoreId>StoreIdValue</tem:StoreId>
<tem:PosId>PosIdValue</tem:PosId>
<tem:Lang>Idioma</tem:Lang>
<tem:ExtraData1></tem:ExtraData1>
</tem:Header>
</tem:FunctionCallRequest>
</soap:Body>
</soap:Envelope>
Respuesta genérica
En los valores de respuesta comunes, nos interesa principalmente:
- Code: un código 0 si la llamada se ha realizado correctamente, cualquier otro valor indicará que ha habido un problema.
- Description: literal descriptivo del resultado de la llamada.
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope"
xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns2="http://tempuri.org/SipayPlusAccess"
xmlns:ns1="http://tempuri.org/">
<SOAP-ENV:Header></SOAP-ENV:Header>
<SOAP-ENV:Body>
<ns1:FunctionCallResponse>
<ns1:Result>
<ns1:Code></ns1:Code>
<ns1:Description></ns1:Description>
</ns1:Result>
</ns1:FunctionCallResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
InitializeDevice - Inicializar dispositivo
Esta función se utiliza para inicializar el dispositivo, configurar sobre el PIN Pad la fecha y hora local, recuperar la versión de claves del dispositivo y registrarlo en la base de datos de Sipay, asociándole un número de cliente, tienda y punto de venta (POS), además de otros parámetros administrativos.
La pasarela solo permite un PIN Pad con un POS. Todos los comercios deben asegurarse que en un mismo establecimiento (StoreID) no repiten el POS entre los diferentes TPVs que tengan. Con la inicialización diaria del PIN Pad con la apertura de las cajas se envía a la pasarela el número de serie vinculado a un client ID, un store ID y un POS ID. Estos datos se guardan en la pasarela de pagos de Sipay y cuando se envían las operaciones a procesar viaja el número de serie del PIN Pad a Redsys como parte de los datos para validar y autorizar la operación. Si se repite el POS la venta se puede enviar con el PIN Pad equivocado y provocar el error de PIN ERRÓNEO.
Para la sincronización de la fecha y la hora, el device hub utiliza la fecha / hora del sistema local, por lo que es muy importante que el reloj del sistema sea correcto. Un descuadre de fecha podría provocar un bloqueo del terminal por motivos de seguridad, de manera que se quedaría inservible de forma permanente.
El PIN Pad debe inicializarse en los siguientes casos:
- Al realizar la apertura del TPV antes de operar.
- Al cambiar de turno.
- En cada reinicio del propio TPV.
- Al reiniciar el DeviceHub.
- Al reiniciar el PIN Pad.
- Al cambiar el PIN Pad.
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:tem="http://tempuri.org/">
<soap:Header/>
<soap:Body>
<tem:InitializeDeviceRequest>
<tem:Header>
<tem:ClientId>ClientIdValue</tem:ClientId>
<tem:StoreId>StoreIdValue</tem:StoreId>
<tem:PosId>PosIdValue</tem:PosId>
<tem:Lang>Idioma</tem:Lang>
<tem:ExtraData1></tem:ExtraData1>
</tem:Header>
</tem:InitializeDeviceRequest>
</soap:Body>
</soap:Envelope>
IMPORTANTE: No se debe hacer la llamada antes de cada operación, ya que puede provocar un retraso importante en la operativa del PIN Pad.
BeginSellTransaction - Solicitar cobro
Esta función, una vez que se ha dado un importe y un número de ticket, lanza la transacción de venta solicitando la autorización financiera. El código de respuesta refleja si la petición ha sido entregada al servicio DeviceHub. Para obtener el resultado de la transacción, es necesario utilizar la función GetNextMessage.
Unicidad de la relación “Operación – Número de ticket”
Es importante que la relación entre un número de ticket y una operación de compra por parte de un usuario sea unívoca. Si la pasarela recibe varios números de ticket diferentes, los interpretará como operaciones distintas.
Así, para una misma operación de venta, independientemente del número de veces que se intente la misma, el número de ticket que se envía desde caja debe ser el mismo. El objetivo de esta regla es evitar duplicidades en las operaciones.
La pasarela considera duplicada una operación en la que coinciden los siguientes parámetros:
- Cliente
- Tienda
- Número de ticket
- POS
- Importe
IMPORTANTE: No se tiene en cuenta el número de la tarjeta, por lo que en caso de una cuenta dividida con el mismo importe, se debe generar un ticket diferente para evitar anulaciones automáticas por detectar duplicidades.
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:tem="http://tempuri.org/">
<soap:Header/>
<soap:Body>
<tem:BeginSellTransactionRequest>
<tem:Header>
<tem:ClientId>ClientIdValue</tem:ClientId>
<tem:StoreId>StoreIdValue</tem:StoreId>
<tem:PosId>ValuePosIdValue</tem:PosId>
<tem:Lang>Idioma</tem:Lang>
<tem:ExtraData1></tem:ExtraData1>
</tem:Header>
<tem:Amount>Importe</tem:Amount>
<tem:TicketNumber>TicketNumber</tem:TicketNumber>
</tem:BeginSellTransactionRequest>
</soap:Body>
</soap:Envelope>
Petición: BeginSellTransactionRequest
| TIPO | NOMBRE | COMENTARIOS |
|---|---|---|
| String | Amount | Importe de venta. Importe de la operación con 10 dígitos numéricos, donde los dos últimos dígitos representan los céntimos. Ej.:1€ -> 0000000100; 2,25€-> 0000000225 |
| String | TicketNumber | Número de recibo de la venta. |
Respuesta: BeginSellTransactionResponse
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns2="http://tempuri.org/SipayPlusAccess" xmlns:ns1="http://tempuri.org/">
<SOAP-ENV:Header></SOAP-ENV:Header>
<SOAP-ENV:Body>
<ns1:GetNextMessageResponse>
<ns1:Result>
<ns1:Code>0</ns1:Code>
<ns1:Description>Ok</ns1:Description>
</ns1:Result>
<ns1:Message>
<ns1:MessageCode>1000</ns1:MessageCode>
<ns1:MessageText>OPERACIÓN ACEPTADA</ns1:MessageText>
<ns1:PrintableData>
<ns1:OperationType>Venta</ns1:OperationType>
<ns1:AuthorizationMode>O</ns1:AuthorizationMode>
<ns1:ACRCode>00</ns1:ACRCode>
<ns1:DataInputType></ns1:DataInputType>
<ns1:DataVerificationType>*</ns1:DataVerificationType>
<ns1:FUCCode></ns1:FUCCode>
<ns1:Terminal></ns1:Terminal>
<ns1:HCP>CAIXABANK, S.A.</ns1:HCP>
<ns1:Store></ns1:Store>
<ns1:City></ns1:City>
<ns1:CardHolder></ns1:CardHolder>
<ns1:AID></ns1:AID>
<ns1:DDFName>A0000000032010</ns1:DDFName>
<ns1:AppLabel>VISA</ns1:AppLabel>
<ns1:ContactlessLiteral>1</ns1:ContactlessLiteral>
<ns1:CardNumber>************9262</ns1:CardNumber>
<ns1:SequenceNumber>192088942</ns1:SequenceNumber>
<ns1:TerminalLabel></ns1:TerminalLabel>
<ns1:DateTime>25/11/2022 - 11:33:50</ns1:DateTime>
<ns1:TerminalSequence>0295</ns1:TerminalSequence>
<ns1:AuthorizationNumber>813039</ns1:AuthorizationNumber>
<ns1:Amount>0.01</ns1:Amount>
<ns1:CurrencySimbol>EUR</ns1:CurrencySimbol>
<ns1:InfoText>REDSYS</ns1:InfoText>
<ns1:Aclaratory></ns1:Aclaratory>
<ns1:ExtraData1><ExtraData1><EXTRA_DATA><DCC><EXCHANGE_RATE/><MARK_UP/><COMMISION/><PERCENT_MARGIN_EXCHANGE_BCE/><EXCHANGE_RATE_BCE/><DCC_CONVERSION_FACTOR/><DCC_MERCHANT/><DCC_AMOUNT/><DCC_CURRENCY_CODE/></DCC><COMMERECE><IDENT>SIPAY PLUS S.L.</IDENT><ADDRESS>AVENIDA EUROÇA 14</ADDRESS><TEL>607067689</TEL><STORE>607067689</STORE><CITY>ALCOBENDAS</CITY><CIF>B78990988</CIF><TICKET>srs_redsys</TICKET></COMMERECE><CASHBACK><COMMISSION_TYPE/><COMMISSION/><CURRENCY/><ADDITIONAL_COMMISSION_TYPE/><ADDITIONAL_COMMISSION/></CASHBACK><CARD_INFO><BIN>404700</BIN><FAMILY_ID>20</FAMILY_ID><FAMILY_NAME>VISA</FAMILY_NAME><EMIT_BANK_CODE>2100</EMIT_BANK_CODE><EMIT_BANK_NAME>CAIXABANK, S.A.</EMIT_BANK_NAME><ADQ_BANK_CODE>2100</ADQ_BANK_CODE><ADQ_BANK_NAME>CAIXABANK, S.A.</ADQ_BANK_NAME><BANK_NETWORK>A101</BANK_NETWORK><FUNCTION_ID>2</FUNCTION_ID><FUNCTION_NAME>DEBIT</FUNCTION_NAME></CARD_INFO><PRIVATE_CARD><INFO_TYPE/><REFERENCE/><DESTINY/><LETTER/><PAYMENT_INFO/></PRIVATE_CARD></EXTRA_DATA></ExtraData1></ns1:ExtraData1>
<ns1:ExtraData2></ns1:ExtraData2>
</ns1:PrintableData>
<ns1:ExtraInfo>
<ns1:TaxFreeEnabled>0</ns1:TaxFreeEnabled>
<ns1:Feature1>0</ns1:Feature1>
<ns1:Feature2>0</ns1:Feature2>
<ns1:Feature3>0</ns1:Feature3>
<ns1:Feature4>0</ns1:Feature4>
<ns1:AuthorizationCode></ns1:AuthorizationCode>
<ns1:FeatureInfo></ns1:FeatureInfo>
</ns1:ExtraInfo>
</ns1:Message>
</ns1:GetNextMessageResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
| TIPO | NOMBRE | COMENTARIOS |
|---|---|---|
| Result | Result | Retorna 0=OK o un código de error y su descripción. |
Result
| TIPO | NOMBRE | COMENTARIOS |
|---|---|---|
| Int | Code | Código de error. |
| String | Descripción | Descripción del error. |
Impresión del ticket
El software de caja deberá incluir una serie de datos para la impresión del ticket. Los campos obligatorios y opcionales son los siguientes:
| CAMPOS OBLIGATORIOS RECIBO DE VENTA |
|---|
| Tipo de operación |
| Código de respuesta a la autorización (ARC)(solo si la operación se ha realizado con tarjeta EMV) |
| Código F.U.C. asignado al establecimiento (identificación del establecimiento) |
| Terminal |
| Nombre del establecimiento |
| Ciudad del establecimiento |
| Identificador de la aplicación AID (solo si la operación se ha realizado con tarjeta EMV) |
| Nº de tarjeta sustituyendo los 12 primeros dígitos por '*' |
| Etiqueta de la aplicación con la siguiente prioridad (solo si la operación se ha realizado con tarjeta EMV 'ApplicationLabel(T50), 'Etiqueta del terminal') |
| Fecha y hora de la operación (DDMMAA hhmm) |
| Nº de autorización |
| Importe de la operación con indicación de moneda |
| Recibo para el comercio: Recuadro de firma, siempre que sea el método aplicado para la autenticación del titular o cuando no siéndolo así este programado en el terminal. |
| Recibo para el comercio: En caso de que la autenticación del titular se realice mediante PIN y no esté programado el terminal para solicitar la firma, se recomienda incluir el texto "OPERACIÓN CON PIN. FIRMA NO NECESARIA" y no se requerirá imprimir el recuadro de firma. |
| Recibo para el comercio: Se indicará que el recibo es para el establecimiento. |
| Recibo para el cliente: Indicar que se trata de una copia y que es para el cliente |
| Resto de copias: Indicar que es copia |
| CAMPOS OPCIONALES |
|---|
| Titular (hay empresas que lo incluyen y otras no) |
| Centro autorizador |
| Pasarela de pagos |
Consideraciones importantes a tener en cuenta en la impresión del ticket
En operaciones Contactless es obligatorio la impresión del Logo. Para determinar si se debe imprimir o no el logo de contactless simplemente hay que fijarse en la variable ContactlessLiteral:
SI ( ContactlessLiteral == 1 OR ContactlessLiteral == 2 ) se debe colocar el logo, en caso contrario no.
Por otro lado, en relación a la forma de autenticación de la operación, los textos siguen la variable DataVerificationType.
SWITCH (DataVerificationType)
BEGIN
CASE 'P':
texto = "OPERACIÓN CON PIN, FIRMA NO NECESARIA"
break;
CASE 'F':
texto = "OPERACIÓN SIN PIN, FIRMA NECESARIA"
break;
~ CASE 'PF':
texto = "OPERACIÓN CON PIN Y FIRMA"
break;
CASE '*'
texto = "OPERACIÓN SIN CONTACTOS, NI FIRMA NI PIN SON NECESARIOS"
END
En función del valor recibido se deben realizar las siguientes acciones:
- En los casos F y PF se debe pintar el recuadro de firma en el ticket.
- En el caso de tarjetas chip es muy importante recordar, que se pueden dar los siguientes escenarios:
- Pedir firma (igual que una contacless).
- No pedir ni firma ni PIN sin ser contactless.
Por lo tanto, es muy importante atender a las reglas anteriores dadas por el DataVerificationType, ya que son la imagen de cómo y bajo qué condiciones la entidad ha autorizado la transacción. De no cumplir las reglas, el ticket pasa a ser inválido ante un repudio bancario.
La impresión del ticket dependerá del modelo de Pin Pad utilizado:
- PIN Pad fijos (integrados): La impresión y los campos del ticket dependen del TPV.
- PIN Pad inalámbricos (standalone): La impresión y los campos del ticket depende de la pasarela de Sipay.
Hay que tener en cuenta que la impresión del ticket representa la finalización de la transacción. En caso de que no se produzca la impresión del ticket (en el TPV o en el mismo PIN Pad), la operación no habrá terminado, siendo necesario el reintento de la operación utilizando el mismo número de ticket e importe.
GetNextMessage - Recorrer mensajes de salida
Una vez iniciada la transacción, ya sea de venta o devolución esta función permite obtener los mensajes del dispositivo para conocer en qué paso del proceso se encuentra la operación.
Es importante controlar el tiempo máximo en el que se recibe un código 10 en el circuito de la función GetNextMessage. Se trata de un intervalo configurable por el cliente, para el que se recomienda que el Timeout sea igual o superior al Timeout de usuario.
Una vez alcanzado este Timeout, se debe parar la llamada, es decir, detener la petición de GetNextMessage, y enviar una Cancelación de la operación con el número de ticket. Esto aplica para las operaciones de venta, devolución y preautorización.
Hay que tener en cuenta que si se excede el tiempo de espera o hay algún error durante la transacción, es muy importante llamar a la función de Cancelación con el número de ticket.
Tras lanzar la llamada de Cancelación se debe seguir el circuito para comprobar con la función GetNextMessage. El obtener un 1000, representa que el device hub ha recibido correctamente la petición de cancelación, pero esto no indica que la misma haya sido procesada en ese momento. El proceso de cancelación es asíncrono y se realizará cuando el device hub tenga conexión con la entidad.
Para comprobar que dicha operación ha sido cancelada, se debe revisar la web de operaciones de Sipay Plus teniendo en cuenta que este proceso puede tardar hasta 24 horas.
En la siguiente tabla se muestra una descripción del código que devuelve la llamada de la función GetNextMessage.
| Código | Comentarios |
|---|---|
| 10 | Significa que la pasarela no tiene respuesta para el paso en el que se encuentra y por lo tanto, se debe seguir preguntando y reiterando en la cola de mensajes (GetNextMessage) para poder continuar con el proceso. |
| 11 | Se mostrará en el TPV o Pin Pad el siguiente paso para continuar con la operación. Por ejemplo, podrá obtener un código 11 cuando se solicite la tarjeta o cuando se solicite el PIN o la firma. Además, siempre que reciba un código 11 debe reiniciar el timeout a 2 minutos para que la operación no se detenga por timeout y dar tiempo suficiente al cliente a completar cada paso de la compra. |
| 1000 | La operación ha sido aceptada y autorizada. En consecuencia, se imprimirá el ticket de la venta y se finaliza el proceso. La impresión del ticket por parte del TPV representa el fin de la operación. |
| 1001 | El cobro no ha sido efectivo, es decir, el cobro no ha finalizado con éxito o bien por motivos técnicos o porque la entidad en su respuesta nos indica que no puede continuar esa operación de forma satisfactoria (por ejemplo, denegada por motivos diversos). En este caso el ticket no se imprimirá y se debería reintentar la operación según considere oportuno para su negocio, utilizando siempre el mismo número de ticket, para asegurar que los controles de consistencia de la pasarela funcionan adecuadamente. |
Respuesta: GetNextMessageRequestResponse
| TIPO | NOMBRE | COMENTARIOS |
|---|---|---|
| Result | Result | Retorna 0=OK o un código de error y su descripción. |
| Message | Message | Contiene el código de respuesta y su mensaje correspondiente, además de guardar la información de impresión y otra información extra para flags. |
Result
| TIPO | NOMBRE | COMENTARIOS |
|---|---|---|
| Int | Code | Código de error. |
| String | Descripción | Descripción del error. |
Message
| TIPO | NOMBRE | COMENTARIOS |
|---|---|---|
| Int | MessageCode | Código de respuesta de la transacción. |
| String | MessageText | Mensaje de respuesta. |
| PrintableData* | PrintableData | Datos para la impresión. |
| Extrainfo* | Extrainfo | Información para flags de transacción. |
| String* | ExpansionData | Datos de expansión en formato XML. |
PrintableData
| TIPO | NOMBRE | COMENTARIOS |
|---|---|---|
| String | OperationType | Tipo de Operación. |
| String | AuthorizationMode | Modo de autorización. |
| String | ACRCodem | Código de ARC en transacciones EMV. |
| String | DataInputType | Tipo de entrada de datos en el PIN Pad: C Chip; B Lectura Banda; M Entrada Manual |
| String | DataVerificationType Tipo de verificación utilizada para autenticar el comprador. | P PIN; F Firma; PF PIN y Firma; (*) Contacless (para importe menor de 50€) |
| String | FUCCode | Código FUC, número de comercio. |
| String | HCP | Entidad/Procesadora autorizadora. |
| String | Store | No Usado. |
| String | City | No Usado. |
| String | CardHolder | Propietario de la tarjeta, solo si viaja en el mensaje. |
| String | AID | Dato EMV. |
| String | DDFName | Dato EMV. |
| String | AppLabel | Aplicación utilizada en el PIN Pad. |
| String | ContactLessLiteral | Indicador de operación sin contacto. |
| String | CardNumber | Número de tarjeta enmascarado. |
| String | SequenceNumber | Número de secuencia de la transacción. Puede localizar una transacción en Sipay Plus. |
| String | TerminalLabel | Número de terminal bancario. |
| String | TerminalSequence | |
| String | DataTime | Fecha y hora. |
| String | AuthorizationNumber | Número de autorización de la transacción. |
| String | Amount | Importe de la operación en la moneda en la que se ha realizado la misma. |
| String | CurrencySimbol | Código ISO, nombre de la moneda en la que se ha realizado la operación. |
| String | InfoText | Información que proviene del centro autorizador. |
| String | Aclaratory | Información que proviene del centro autorizador. |
| String | ExtraData1 | Datos extra para imprimir en formato XML. Véase ExtraData1 en la tabla inferior. |
| String | ExtraData2 | Futura expansión. |
ExtraData1 (XML)
Se envía información complementaria según el tipo de operación: DCC, tarjetas privadas, Tax Free etc. Para conocer con más detalle sobre el ExtraData puedes ponerte en contacto con nuestro equipo de soporte.
En ExtraData1, se encuentran los datos de operaciones multi-divisa (DCC) y los datos del establecimiento donde se ha llevado a cabo la operación. Los datos de multi-divisa son obligatorios en los tickets de operaciones DCC.
En las operaciones DCC, los campos “Amount” y CurrencySymbol de PrintableData, muestran el importe y la moneda seleccionada durante la transacción, por lo que siempre pueden ser utilizados. Del subcampo DCC del XML será necesario extraer como mínimo los datos “EXCHANGE_RATE”, “DCC_MERCHANT”, cuando vengan alimentados (Operaciones DCC).
<EXTRA_DATA>
<DCC>
<EXCHANGE_RATE/><- Tasa de intercambio aplicada
<MARK_UP/>
<COMMISION/><- Comisión del procesador DCC
<DCC_MERCHANT>CAIXABANK, S.A.</DCC_MERCHANT><- Operador DCC
<DCC_AMOUNT/><- Importe de la operación
<DCC_CURRENCY_CODE/><- Nombre de la moneda
</DCC>
<COMMERECE>
<IDENT>SIPAY PLUS S.L.</IDENT>
<ADDRESS>AVDA. EUROPA 14 PLANTA 1o A</ADDRESS>
<TEL>620857910</TEL>
<STORE>TIENDA SIPAY PLUS 1</STORE>
<CITY>Madrid</CITY>
<CIF>B67890980</CIF>
</COMMERECE>
<CARD_INFO>
<BIN>46456</BIN> !- Bin de la tarjeta que ha operado
<FAMILY_ID>20</FAMILY_ID> !- ID de la familia de la tarjeta (máx 3 dígitos)
<FAMILY_NAME>VISA</FAMILY_NAME> !- Nombre de la familia de la tarjeta (máx 45 dígitos)
<EMIT_BANK_CODE>2100</EMIT_BANK_CODE> !- Código ISO de la entidad emisora de la tarjeta ( 4 dígitos ) <EMIT_BANK_NAME>CAIXA BANK S.A</EMIT_BANK_NAME> !- Nombre de la entidad emisora
<ADQ_BANK_CODE>0049</ADQ_BANK_CODE> !- Código ISO de la entidad adquiriente (4 digitos)
<ADQ_BANK_NAME>BANCO SANTANDER S.A.</ADQ_BANK_NAME> !- Nombre de la entidad adquiriente (máx 45 dígitos)
BANK_NETWORK>A101</BANK_NETWORK> !- Nombre de la red en que opera la tarjeta
</CARD_INFO>
<PRIVATE_CARD>
<INFO_TYPE> tipo de información </INFO_TYPE>
<REFERENCE>nº de referencia de la operación</REFERENCE>,
<DESTINY> destino (impresión o pantalla) </DESTINY>,
<LETTER> tipo de letra </LETTER>,
<PAYMENT_INFO> datos enviados por la entidad sobre el pago</PAYMENT_INFO>
</PRIVATE_CARD>
</EXTRA_DATA>