Worldline Fichero de Lote (avanzado)
1. Introducción
This document explains the advanced (automatic) integration procedure for Fichero de Lote mode.
Batch mode allows you to group your payments into formatted files that can be used for uploading and downloading payment results. This option is specially suited to large volumes of payments that do not need online processing or recurrent invoicing.
The file format described in this documentation is the standard Worldline file format. For other file formats, go to Other file formats.
For more information on the basic (manual) integration procedure for Batch mode, please refer to the Basic Batch documentation.
2. Formato de archivo: Cargar
La siguiente sección contiene las reglas de formato del archivo de transacción estándar. Si utiliza otro formato específico compatible con nuestro sistema, vaya a Otros formatos de archivo.
2.1 General
Se debe dar formato a un archivo de pago según las siguientes reglas básicas:
- El archivo debe ser un archivo de texto ASCII
- Una línea por pedido. Las líneas se separan mediante los caracteres de retorno de carro o avance de línea (ASCII : 13 10 – HEX : 0xD 0xA)
- Los campos deben separarse mediante un punto y coma (“;”)
- Los campos no pueden contener ningún punto y coma (“;”)
Para nuevas transacciones (ATR), dividimos de forma automática los archivos que tengan más de 2750 líneas/transacciones. Si este no es el caso de su cuenta, solicite a nuestro Servicio de Atención al Cliente que active esta funcionalidad.
Para transacciones de mantenimiento (MTR), no dividimos los archivos, así que la cantidad de líneas deberá limitarse a 30 000. No obstante, para garantizar que sus archivos se procesen con rapidez, le recomendamos que limite cada archivo a 2500 líneas.
2.2 Campos de archivo
2.2.1 Diseño
Un archivo de lote estándar tiene el siguiente diseño de transacción:
Nº. de archivo / Campo | Descripción | Obligatorio/Opcional |
---|---|---|
1 / AMOUNT | Importe a pagar MULTIPLICADO POR 100, ya que el formato del importe no debe contener decimales u otros separadores. |
|
2 / CURRENCY | Código de divisa de pedido alfa ISO, por ejemplo: EUR, USD, GBP, CHF, etc. |
|
3 / BRAND | Marca de la tarjeta (consulte el Apéndice 3 para obtener más información sobre métodos de pago de tarjetas que no sean de crédito). |
|
4 / CARDNO | Número de tarjeta /cuenta . |
|
5 / ED | Fecha de caducidad (MM/AA o MMAA) |
|
6 / ORDERID | Su número de pedido único (referencia del comerciante). |
|
7 / COM | Descripción del pedido. | |
8 / CN | Nombre del cliente. |
|
9 / PAYID | La referencia de transacción única de nuestro sistema. |
|
10 / OPERATION |
El procedimiento de pago que ha configurado en la pestaña "Parámetros de transacción globales", en la sección "Código de operación predeterminado" de la página Información técnica definirá su operación de transacción predeterminada. Cuando envíe un valor de operación en el campo Operación de su lote, este sobrescribirá el valor predeterminado. Valores posibles para pedidos nuevos:
Tenga en cuenta que los reembolsos enviados a través de Lote no se procesan hasta el día siguiente (después de la hora de cierre de la entidad adquirente establecida en su cuenta). Haga clic aquí para ver los posibles valores de las operaciones de mantenimiento. |
|
11 / AUTHORIZATION CODE | Código de autorización, no recibido a través de nuestro sistema. | |
12 / AUTHORIZATION MODE | Forma en que se recibió el código de autorización en el campo 11. Valor posible: ‘TEL’ para teléfono | |
13 / AUTHORIZATION DATE | La fecha/hora en que se recibió el código de autorización en el campo 11. (MM/DD/AA hh:mm:ss) | |
14 / PSPID | Su nombre de afiliación en nuestro sistema. | |
15 / GLOBORDERID | Referencia que agrupa varios pedidos y le permite solicitar más tarde una operación de mantenimiento sobre estas transacciones de forma combinada. | |
Campos vacíos | ... | |
22/ OWNERADDRESS | Número y nombre de la calle del cliente. | |
23 / OWNERZIP | Código postal del cliente. | |
24 / OWNERTOWN | Nombre de la localidad del cliente. | |
25 / OWNERCTY | País del cliente. | |
26 / OWNERTELNO | Número de teléfono del cliente. | |
27 / CVC | Código de verificación de tarjeta (Valor de verificación de tarjeta) |
|
Campos vacíos | ... | |
35 / ECI |
Indicador de comercio electrónico. Puede configurar un valor ECI predeterminado en la pestaña "Parámetros de transacción globales", en la sección "Valor de ECI predeterminado" de la página Información técnica. Cuando envíe un valor de ECI al campo ECI de su lote, este sobrescribirá el valor ECI predeterminado. 0 - Pasada por el lector 1 - Introducción manual (MOTO) (tarjeta no presente) 2 Pagos periódicos, procedentes de MOTO 3 - Pagos a plazos 7 - Comercio electrónico con cifrado SSL 9 Periódico tras primera transacción de comercio electrónico |
|
Campos vacíos | ... |
Los siguientes parámetros entran dentro del ámbito de aplicación de la directiva Credential-on-File (COF) de los esquemas de pago Visa / MasterCard. Se puede encontrar información detallada sobre su uso en el capítulo dedicado Procesamiento de transacciones con credenciales guardadas.
Nº de campo / Campo |
Descripción |
52 / COF_INITIATOR* | Valores posibles: CIT - Transacción iniciada por el titular de la tarjeta MIT - Transacción iniciada por un comerciante |
53 / COF_TRANSACTION* | Valores posibles: FIRST - Primera serie de transacciones SUBSEQ - Siguientes series de transacciones |
54 / COF_SCHEDULE* | Valores posibles: SCHED - Transacción programada UNSCHED - Transacción no programada |
55 / Campo vacío | ... |
56 / COF_RECURRING_EXPIRY* | Fecha de fin: fecha del último pago programado de une serie Valores posibles: YYYYMMDD (por ejemplo: 20190914) |
57 / COF_RECURRING_FREQUENCY* | Días entre pagos de una serie. Valores posibles: numérico entre 2 y 4 digitos (por ejemplo: 31, 031 o 0031) |
* Por favor, envíe los valores de los parámetros de acuerdo con el formato definido en la tabla. De lo contrario, la transacción será bloqueada por nuestro sistema.
De forma opcional, los comerciantes que hayan activado determinadas opciones/funcionalidades en sus cuentas también pueden enviar campos adicionales. Consulte la documentación de la opción respectiva para obtener más información acerca de los campos adicionales vinculados a la opción.
2.2.2 Campos necesarios mínimos para nuevas transacciones
Esta sección solo se aplica a nuevas transacciones. Vaya a Operaciones de mantenimiento si desea más información sobre operaciones de mantenimiento en transacciones existentes.
General: nueva transacción
Para nuevas transacciones que desee especificar en nuestro sistema, los campos mínimos necesarios en el nivel de transacción son los siguientes:
- Importe (campo 1 del diseño de archivo)
- Divisa (campo 2)
- Marca de la tarjeta de crédito (campo 3)
- Número de tarjeta (o cuenta) (campo 4)
- Fecha de caducidad (campo 5)
- CVC (campo 27) (este campo será necesario en función de su entidad adquirente y del valor ECI de sus transacciones)
- Su referencia de pedido (campo 6)
- Operación (campo 10)
Ejemplo General: nueva transacción 10000;EUR;Visa;4111111111111111;11/12;Order0001;;Paul Smith;;SAL;;;;;;;;;;;;;;;;;123; 9500;EUR;MasterCard;5399999999999999;11/10;Order0002;;Jane Doe;;SAL;;;;;;;;;;;;;;;;;485; 2050;EUR;Visa;4444333322221111;11/09;Order0003;;John Doe;;SAL;;;;;;;;;;;;;;;;;875; |
Excepción: autorización recibida a través de un canal alternativo
Cuando una transacción (relacionada) todavía no existe en nuestro sistema, los campos mínimos necesarios en el nivel de transacción para las autorizaciones recibidas a través de un canal alternativo (por ejemplo, autorización recibida por teléfono con su entidad adquirente) son:
- Importe (campo 1 del diseño de archivo).
- Divisa (campo 2),
- Marca de la tarjeta de crédito (campo 3)
- Número de tarjeta (o cuenta) (campo 4).
- Fecha de caducidad (campo 5).
- Su referencia de pedido (campo 6).
- Nombre del titular de la tarjeta (cuenta) (campo 8).
- Operación (campo 10).
- Código de autorización (campo 11).
- Modo de autorización (campo 12).
- Fecha de autorización (campo 13).
Ejemplo Excepción: autorización ya recibida a través de un canal alternativo 1000;EUR;Visa;4111111111111111;11/12;Order0001;;Paul Smith;;IMP;43785;TEL;08/08/07 15:15:52; 9500;EUR;Mastercard;5399999999999999;11/10;Order0002;;Jane Doe;;IMP;83145;TEL;08/08/07 15:21:45; 2050;EUR;Visa;4111111111111111;11/09;Order0003;;John Doe;;IMP;73586;TEL;08/08/07 15:26:12; |
2.2.3 Transacciones de banda magnética
Para transacciones aceptadas en vuelo a través de banda magnética, los datos de "TRACK2" se pueden enviar a la línea 42 de un archivo de lote.
TRACK2 es una pista leída por ATM y verificadores de tarjeta de crédito. Contiene la cuenta del titular de la tarjeta, el PIN cifrado y otra información discrecional.
2.3 Cabeceras y pies de página
Deberá usar las cabeceras y el pie de página si está actualizando sus archivos de forma automática o enviando operaciones de mantenimiento en su archivo.
Hay dos cabeceras: OHL, que contiene información, y OHF, que contiene información general del archivo. Las cabeceras deben especificarse en las primeras líneas del archivo, antes de los datos de pago reales.
Hay un pie de página de archivo general denominado OTF. El pie de página de archivo debe especificarse en la última línea del archivo, después de los datos de pago reales. El diseño de pie de página es “OTF;”.
El siguiente ejemplo muestra un archivo que contiene tanto cabeceras como un pie de página. En las siguientes secciones, examinaremos el diseño de las cabeceras de información de inicio de sesión y de información del archivo.
Ejemplo OHL;FishShop1;MySecret84;;FishAPI; OHF;File53484;ATR;RES;2; 10000;EUR;Visa;4111111111111111;11/12;Order0001;golf balls;Paul Smith;;RES;;;;;;;;;;;;;;;;;;123;9500;EUR;Mastercard;5399999999999999;11/10;Order0002;mobile phone;Jane Doe;;RES;;;;;;;;;;;;;;;;;;485; OTF; |
2.3.1 OHL: Cabecera de información de inicio de sesión
Utilice solo la cabecera de inicio de sesión al cargar sus archivos de forma automática (excepción: carga manual de archivos en un grupo).
Diseño de cabecera de inicio de sesión:
OHL;PSPID;PSWD;USERTYPE;USERID;
Campo |
Descripción |
---|---|
OHL |
Valor fijo, que indica que se trata de una cabecera que contiene información de inicio de sesión |
PSPID |
Su nombre de afiliación en nuestro sistema |
PSWD |
La contraseña que pertenece a su usuario (> USERID) |
USERTYPE |
Solo aplicable para estructuras de grupo, valor: MGID |
USERID |
Su usuario (API) (consulte la documentación del Administrador de usuarios para obtener más información sobre los usuarios de API) |
Los campos que complete dependerán de si utiliza los detalles de inicio de sesión de:
- Su PSPID y un USERID
- Un grupo: cuando tiene una estructura de “Grupo” y desea enviar un archivo que contenga transacciones para más de un PSPID que pertenezca a su grupo, los detalles de inicio de sesión deberán contener un PSPID (predeterminado) que pertenezca a su grupo y un usuario de nivel de “Grupo” (lo contrario sería un usuario que pertenezca a un PSPID específico).
Vamos a ilustrar esto en los siguientes ejemplos:
Ejemplos Cabecera de inicio de sesión de comerciante Mike tiene un PSPID denominado MilkyMike. Desea enviar sus archivos de forma automática desde una aplicación propia. Para ello, ha creado un usuario API denominado MikeAPI en su cuenta, con A78H29U41 como contraseña. Su cabecera de inicio de sesión sería: OHL;MilkyMike;A78H29U41;;MikeAPI; Cabecera de inicio de sesión de grupo John Doe Trading tiene 3 PSPID diferentes: JohnUK, JohnUS y JohnAU. Tiene una estructura de grupo, denominada JohnDGroup, que agrupa los 3 PSPID. En JohnDGroup, han creado un usuario API denominado JohnUser1 con MySecret12 como contraseña. John desea enviar de forma automática un archivo que contiene transacciones para 3 PSPID diferentes. La mayoría de sus transacciones tienen lugar en el Reino Unido. Este sería el aspecto de su cabecera de inicio de sesión: OHL;JohnUK;MySecret12;MGID;JohnUser1; |
2.3.2 OHF: Cabecera de información de archivo
Diseño de cabecera de archivo:
OHF;FILE_REFERENCE;TRANSACTION_CODE;OPERATION;NB_PAYMENTS;
Campo |
Descripción |
---|---|
OHF |
Valor fijo, que indica que se trata de una cabecera que contiene información general del archivo |
FILE_REFERENCE |
Referencia (nombre) obligatoria para el archivo, que puede definirse en función de las preferencias del usuario. Puede usar esta referencia con posterioridad para buscar el archivo. (máx. 50 caracteres) |
TRANSACTION_CODE |
Valores posibles:
|
OPERATION |
Para nuevos pedidos: vacío, RES, SAL, RFD Para operaciones de mantenimiento: REN, DEL, DES, SAL, SAS, RFD, RFS (Vaya a Campos de archivo yEspecificaciones de archivo para obtener explicaciones sobre operaciones) El parámetro OPERATION del nivel de archivo se puede sobrescribir con el parámetro OPERATION en el nivel de transacción. |
NB_PAYMENTS |
Número de pagos del archivo. Numérico. Obligatorio a menos que utilice un pie de página de archivo (en cuyo caso, seguiremos sugiriéndole que utilice este campo). |
Ejemplo Cabecera de información de archivo para nuevos pedidos Jane tiene un archivo llamado Membership0607 que contiene 86 solicitudes de autorización. Su cabecera de información de archivo sería: OHF;Membership0607;ATR;RES;86; Cabecera de información de archivo para transacciones de mantenimiento Mike tiene un archivo denominado RefundsJune, que contiene 9 reembolsos (finales). Su cabecera de información de archivo sería: OHF;RefundsJune;MTR;RFS;9; |
Los detalles de información de archivo y de inicio de sesión se pueden transmitir en cabeceras de archivo, según se ilustra anteriormente, o como parámetros en solicitudes HTTP POST (solo para carga automática de archivos).
3. Operaciones de mantenimiento
Las operaciones de mantenimiento son operaciones realizadas en pedidos ya autorizados o pagados; en otras palabras, en transacciones que ya existen en nuestro sistema.
Para crear determinadas operaciones de mantenimiento, deben estar habilitadas en su cuenta (a veces la disponibilidad depende de su suscripción), su entidad adquirente debe permitir la operación y la operación debe ser posible para el método de pago correspondiente.
3.1 Especificaciones de archivo
3.1.1 Cabecera OHF
El TRANSACTION_CODE para operaciones de mantenimiento es MTR.
El código OPERATION para la operación de mantenimiento se proporciona a nivel de archivo o transacción individual. El código de operación del nivel de transacción sobrescribirá el código de operación del nivel de archivo para operaciones de mantenimiento. Esto significa que podrá enviar un archivo que contenga diferentes operaciones, por ejemplo, capturas de datos parciales y últimos, reembolsos, etc.
Los valores posibles para las operaciones de mantenimiento (campo 10) son:
- DEL: eliminar autorización, dejando la transacción abierta para más operaciones de mantenimiento potenciales.
- DES: eliminar autorización, cerrando la transacción después de esta operación.
- SAL: captura de datos parcial (pago), dejando la transacción abierta para otra captura de datos potencial.
- SAS: captura (final) de datos parcial o completa (pago), cerrando la transacción para capturas de datos adicionales.
- RFD: reembolso parcial (de un pedido pagado), dejando la transacción abierta para otro reembolso potencial.
- RFS: reembolso (final) parcial o completo (para un pedido pagado), cerrando la transacción después de este reembolso.
En general, realizará las operaciones REN, DEL, DES, SAL, SAS en pedidos en estado 5-Autorizado y las operaciones RFD, RFS en pedidos en estado 9-Pago solicitado.
3.1.2 Nivel de transacción
Los campos necesarios en el nivel de transacción para una autorización manual después de que se rechazase la autorización inicial (a través de nuestro sistema, pedido con el estado 2-Autorización denegada) son:
- Importe (campo 1 del diseño de archivo)
- Divisa (campo 2)
- Marca de la tarjeta de crédito (campo 3)
- PAYID de nuestro sistema (campo 9)
- Código de operación (campo 10).
- Código de autorización (campo 11)
- Modo de autorización (campo 12)
- Fecha de autorización (campo 13).
Ejemplo Mike tiene un PSPID denominado MilkyMike. Desea enviar sus archivos de forma automática desde una aplicación propia. Para ello, ha creado un usuario API denominado MikeAPI en su cuenta, con A78H29U41 como contraseña. Su cabecera de inicio de sesión sería: OHL;MilkyMike;A78H29U41;;MikeAPI; 1. Autorización Mike tiene un archivo denominado AutoMay, que contiene 1 transacción: una solicitud de autorización de 75 EUR. Su cabecera de información de archivo sería: OHF;AutoMay;ATR;RES;1; Este es el archivo que envía: OHL;MilkyMike;A78H29U41;;MikeAPI; OHF;AutoMay;ATR;RES;1; 7500;EUR;Mastercard;5399999999999999;11/10;Order0001;;Jane Doe;;RES;;;;;;;;;;;;;;;;;;485; OTF; Después del proceso de carga completo, al archivo se le asigna el FileID 1543 y a la transacción se le asigna la siguiente referencia desde nuestro sistema (PAYID): 1348645 En el área de administración de la cuenta, aparecer ahora un PAYID 1348645 con un registro histórico en estado 5-Autorizado. 2. Captura de datos parcialMike desea capturar datos de una parte del importe autorizado, dejando la transacción abierta para una posterior captura de datos final del resto del importe (código de operación: SAL). Desea capturar un importe de 25 EUR para el PAYID 1348645. Su archivo se llama DataCap1May. Su cabecera de información de archivo sería: OHF;DataCap1May;MTR;SAL;1; Este es el archivo que envía: OHL;MilkyMike;A78H29U41;;MikeAPI; OHF;DataCap1May;MTR;SAL;1; 2500;EUR;;;;;;;1348645;SAL; OTF; Tras el proceso de carga completo, al archivo se le asigna el FileID 1571. En el área de administración de la cuenta, el PAYID 1348645 tiene ahora 2 registros históricos: /0 en estado 5-Autorizado para un importe de 75 EUR y /1 en estado 9-Pago solicitado para un importe de 25 EUR. El estado del pedido sigue siendo 5-Autorizado porque la captura de datos enviada era parcial. 3. Captura de datos final Mike desea realizar una captura de datos FINAL del resto del importe autorizado (código de operación: SAS); por ejemplo, captura de datos de un importe de 50 EUR para el PAYID 1348645. Su archivo se llama DataCap2May. Su cabecera de información de archivo sería: OHF;DataCap2May;MTR;SAS;1; Este es el archivo que envía: OHL;MilkyMike;A78H29U41;;MikeAPI; OHF;DataCap2May;MTR;SAS;1; 5000;EUR;;;;;;;1348645;SAS; OTF; Tras el proceso de carga completo, al archivo se le asigna el FileID 1610. En el área de administración de la cuenta, el PAYID 1348645 tiene ahora 3 registros históricos: /0 en estado 5-Autorizado para un importe de 75 EUR, /1 en estado 9-Pago solicitado para un importe de 25 EUR y /2 en estado 9-Pago solicitado para un importe de 50 EUR. El estado del pedido es ahora 9-Pago solicitado porque la captura de datos enviada fue la FINAL (cerrando la transacción). 4. Reembolso Mike desea reembolsar (código de operación: RFS) al cliente el importe completo; un reembolso por un importe 75 EUR para el PAYID 1348645. Su archivo se llama RefundMay. Su cabecera de información de archivo sería: OHF;RefundMay;MTR;RFS;1; Este es el archivo que envía: OHL;MilkyMike;A78H29U41;;MikeAPI; OHF;RefundMay;MTR;RFS;1; 7500;EUR;;;;;;;1348645;RFS; OTF; Tras el proceso de carga completo, al archivo se le asigna el FileID 1671. En el área de administración de la cuenta, el PAYID 1348645 tiene ahora 4 registros históricos: /0 en estado 5-Autorizado para un importe de 75 EUR, /1 en estado 9-Pago solicitado para un importe de 25 EUR y /2 en estado 9-Pago solicitado para un importe de 50 EUR y 3/ en estado 8-Reembolso para un importe de 75 EUR. El estado del pedido es ahora 8-Reembolso porque el reembolso enviado fue el FINAL (cerrando la transacción). |
4. Proceso de carga automático
Existen 2 formas diferentes de cargar un archivo:
- Carga de archivos manual: Puede cargar los archivos de pago de forma manual desde el área de administración de su cuenta. Vaya a Lote manual para obtener más información.
- Carga automática desde una aplicación del comerciante: la aplicación del comerciante realiza solicitudes de carga y descarga de archivos https en páginas específicas de nuestro sistema. Esto requiere desarrollos en la aplicación del comerciante.
Este capítulo describe el proceso de carga automático desde una aplicación del comerciante.
4.1 URL de solicitud y parámetros específicos
Una carga de archivo automática le permite procesar varios pagos directamente desde su propio sistema (programa, tarea programada, etc.) sin necesidad de un navegador ni de intervención humana. El servidor envía una solicitud HTTPS POST a nuestro servidor. El archivo de transacción y los parámetros adicionales se transmiten en el “contenido” de la solicitud https.
Su aplicación envía una solicitud HTTPS a la siguiente página de nuestro servidor:
- Prueba: https://ogone.test.v-psp.com/ncol/test/AFU_agree.asp (se utilizará en más ejemplos)
- Producción: https://secure.ogone.com/ncol/prod/AFU_agree.asp
El formato de archivo es idéntico para las cargas de archivos manuales y automáticas. No obstante, en caso de carga automática de archivos, los datos de inicio, determinados datos de proceso y los parámetros generales serán obligatorios en la solicitud. Puede enviar estos parámetros como parámetros de cabecera/pie de página incluidos en el archivo, o como parámetros POST separados del archivo.
Los parámetros generales establecidos a continuación se enviarán en cada solicitud de carga automática de archivo. Estos parámetros hacen referencia a la “Disposición de contenido” del protocolo HTTP y solo se pueden especificar como parámetros POST separados del archivo, no en cabeceras.
Campo | Descripción |
---|---|
REPLY_TYPE | Define qué formato de respuesta solicita nuestro sistema. Valores posibles:
|
PROCESS_MODE |
Posibles valores para el modo de procesamiento:
|
MODE |
Se puede usar para especificar si su aplicación está esperando una respuesta de nuestro servidor o si recuperará la respuesta posteriormente. Los modos válidos son:
Actualmente esta opción solo tiene efecto en los pasos PROCESS o CHECKANDPROCESS (consulte PROCESS_MODE más arriba). En el modo SYNC, recibirá el resultado del proceso de validación de pago si permanece conectado (no el resultado de la autorización con las entidades adquirentes, ya que esto siempre ocurre sin conexión para las cargas de archivos). En modo ASYNC, el proceso de validación se realiza sin conexión y solo recibirá el FILE ID como confirmación. Se envía un correo electrónico al comerciante cuando nuestro sistema ha validado el archivo. Si envía archivos de gran tamaño, es recomendable que utilice el modo ASYNC. Independientemente del modo utilizado, también se enviará un correo electrónico una vez que se haya procesado el archivo (enviado a la entidad adquirente). |
Ejemplos Parámetros adicionales especificados como parámetros POST independientes <form action="https://ogone.test.v-psp.com/ncol/test/AFU_agree.asp" method=POST><textarea name=FILE> 10000;EUR;Visa;4111111111111111;11/12;Order0001;golf balls;Paul Smith;;;;;;;;;;;;;;;;;;;123; 9500;EUR;Mastercard;5399999999999999;11/10;Order0002;mobile phone;Jane Doe;;;;;;;;;;;;;;;;;;;485; 2050;EUR;Visa;4444333322221111;11/09;Order0003;cocktails;John Doe;;;;;;;;;;;;;;;;;;;875; </textarea> <input type=text name=FILE_REFERENCE value=”File53484”> <input type=text name=PSPID value=”FishShop1”> <input type=text name=USERID value=”FishAPI”> <input type=text name=PSWD value=”MySecret81”> <input type=text name=TRANSACTION_CODE value=”ATR”> <input type=text name=OPERATION value=”RES”> <input type=text name=NB_PAYMENTS value=”3”> <input type=text name=REPLY_TYPE value=”XML”> <input type=text name=MODE value=”SYNC”> <input type=text name=PROCESS_MODE value=”SEND”> </form> Parámetros adicionales especificados en las cabeceras/pies de página del archivo <form action="https://ogone.test.v-psp.com/ncol/test/AFU_agree.asp" method=POST><textarea name=FILE> OHL;FishShop1;MySecret81;;FishAPI; OHF;File53484;ATR;RES;3; 10000;EUR;Visa;411111111111111;11/12;Order0001;golf balls;Paul Smith;;RES;;;;;;;;;;;;;;;;;123; 9500;EUR;Mastercard;5399999999999999;11/10;Order0002;mobile phone;Jane Doe;;RES;;;;;;;;;;;;;;;;;485; 2050;EUR;Visa;4444333322221111;11/09;Order0003;cocktails;John Doe;;RES;;;;;;;;;;;;;;;;;875; </textarea> <input type=text name=REPLY_TYPE value=”XML”> <input type=text name=MODE value=”SYNC”> <input type=text name=PROCESS_MODE value=”SEND”> </form> |
4.2 Proceso de carga
Le recomendamos dividir el proceso de carga en pasos diferentes: SEND, CHECK y PROCESS (valores de “PROCESS_MODE”). Estos pasos corresponden a los diferentes pasos de la carga manual de archivos.
La división del proceso de carga cuenta con dos ventajas fundamentales:
- La división entre CHECK y PROCESS permite a su aplicación cancelar la carga después de la comprobación de formato de nuestro sistema si hay demasiados errores de formato en el archivo.
- La división entre SEND y el resto del procesamiento impide que procese el mismo archivo más de una vez. Si su aplicación no recibe una respuesta después de un determinado paso por alguna razón, podrá repetir el paso sin riesgo. Si realiza la carga en un solo paso (CHECKANDPROCESS) y se produce un problema de comunicación antes de que su aplicación haya recibido la respuesta, podría pensar que el archivo no se ha cargado e intentar la carga una segunda vez, lo que daría lugar a un procesamiento duplicado del mismo archivo.
La aplicación del comerciante desactiva cada paso, realizando la solicitud HTTPS POST a nuestro servidor. La solicitud HTTPS se puede enviar como solicitud POST HTTPS estándar (con el contenido del archivo en un campo estándar denominado “FILE”) o como solicitud MULTIPART/FORM-DATA POST HTTPS (con el contenido del archivo en un campo tipo “file” denominado “FILE”, <input type="file" name="File1">). Con ambos métodos, necesita un componente capaz de enviar solicitudes HTTP a un servidor seguro.
En el primer paso (SEND), el propio archivo forma parte del contenido de la solicitud. Nuestro sistema devuelve un FileID en la respuesta XML a esta solicitud. Utilizará este FileID en lugar del propio archivo en los pasos de carga posteriores (CHECK y PROCESS).
4.2.1 Enviar
Cuando envíe PROCESS_MODE=SEND, cargará un nuevo archivo de transacción, pero no se realizará ningún procesamiento ni comprobación (esto corresponde al paso 1 de una carga manual de archivos).
Cuando nuestro sistema reciba la solicitud HTTPS, comprobará que los parámetros generales son válidos. Si algo es erróneo, se devolverá un error a su aplicación y el proceso se detendrá sin realizar ninguna operación.
Si los parámetros generales son válidos, nuestro sistema devolverá un FILEID y un GUID. Este FILEID se utilizará en posteriores solicitudes en lugar del propio archivo. El GUID se puede utilizar en posteriores solicitudes para reemplazar el inicio de sesión y la contraseña.
Después de este paso, el estado del archivo se establece en “Cargado” (visible en el área de administración o con la descarga automática de archivo).
Ejemplo Solicitar <form action="https://ogone.test.v-psp.com/ncol/test/AFU_agree.asp" method=POST><textarea name=FILE> 10000;EUR;Visa;411111111111111;11/12;Order0001;golf balls;Paul Smith;;RES;;;;;;;;;;;;;;;;;123; 9500;EUR;Mastercard;5399999999999999;11/10;Order0002;mobile phone;Jane Doe;;RES;;;;;;;;;;;;;;;;;485; 2050;EUR;Visa;4444333322221111;11/09;Order0003;cocktails;John Doe;;RES;;;;;;;;;;;;;;;;;875; </textarea> <input type=text name=FILE_REFERENCE value=”File53484”> <input type=text name=PSPID value=”FishShop1”> <input type=text name=USERID value=”FishAPI”> <input type=text name=PSWD value=”MySecret81”> <input type=text name=TRANSACTION_CODE value=”ATR”> <input type=text name=OPERATION value=”RES”> <input type=text name=NB_PAYMENTS value=”3”> <input type=text name=REPLY_TYPE value=”XML”> <input type=text name=MODE value=”SYNC”> <input type=text name=PROCESS_MODE value=”SEND”> </form> Respuesta XML <?xml version="1.0" ?><AFU_REPLY> <SEND_FILE> <FILEID>2010</FILEID> <GUID>8B1F5D65D5C7C5C80551D2AA955F810A45BD1752</GUID> </SEND_FILE> </AFU_REPLY> |
4.2.2 Comprobar
Al enviar PROCESS_MODE= CHECKHECK, se solicita una comprobación de formato (esto corresponde al paso 2 de la carga manual de archivos),
Utilizará el FILEID de la solicitud en lugar del propio archivo.
Nuestro sistema devuelve errores de formato en el caso de que estos se produzcan.
Después de este paso, el estado del archivo se establece en “Comprobado”.
Ejemplo Solicitar <form action="<%URL_TESTENV%>AFU_agree.asp" method=POST><input type=text name=PSPID value=”FishShop1”> <input type=text name=USERID value=”FishAPI”> <input type=text name=PSWD value=”MySecret81”> <input type=text name=REPLY_TYPE value=”XML”> <input type=text name=MODE value=”SYNC”> <input type=text name=PFID value=”2010”> <input type=text name=PROCESS_MODE value=”SEND”> </form> Respuesta XML <?xml version="1.0" ?><AFU_REPLY> <FORMAT_CHECK> <FORMAT_CHECK_ERROR> <ERROR>|Wrong credit card number format|</ERROR> <LINE>1</LINE> <NCERROR>50001002</NCERROR> <PAYID>0</PAYID> <ORDERID>Order0001</ORDERID> <NCSTATUS>5</NCSTATUS> <STATUS>0</STATUS> </FORMAT_CHECK_ERROR> <FILEID>2012</FILEID> </FORMAT_CHECK> </AFU_REPLY> |
4.2.3 Proceso
Al enviar PROCESS_MODE=PROCESS, se solicita el procesamiento del archivo (esto corresponde al paso 3 de la carga manual de archivos).
Utilizará el FILEID de la solicitud en lugar del propio archivo.
Nuestro sistema devuelve errores de carga en el caso de que estos se produzcan.
OK_PAYMENTS es el número de transacciones cargadas de forma correcta. RANGE_START y RANGE_STOP representan el rango de PAYID para las transacciones cargadas según la forma en la que las ha asignado nuestro sistema (solo cuando transaction_code es ATR).
Después de este paso, el estado del archivo se establece en “En proceso”.
Después de haber enviado la respuesta, las transacciones se procesan con las entidades adquirentes (los bancos) en modo sin conexión. Es posible recuperar los resultados en su área de administración o con la descarga automática de archivos.
Ejemplo: Solicitud en modo SYNC Solicitud en modo SYNC <form action="https://ogone.test.v-psp.com/ncol/test/AFU_agree.asp" method=POST> <input type=text name=PSPID value=”FishShop1”> <input type=text name=USERID value=”FishAPI”> <input type=text name=PSWD value=”MySecret81”> <input type=text name=REPLY_TYPE value=”XML”> <input type=text name=MODE value=”SYNC”> <input type=text name=PFID value=”2010”> <input type=text name=PROCESS_MODE value=”PROCESS”> </form> Respuesta XML <?xml version="1.0" ?> <AFU_REPLY> <PROCESSING> <NC_ERROR> <NCERRORPLUS>||Wrong credit card number format|</NCERRORPLUS> <LINE>1</LINE> <NCERROR>50001002</NCERROR> <PAYID>37267</PAYID> <ORDERID>Order0001</ORDERID> <NCSTATUS>5</NCSTATUS> <STATUS>0</STATUS> </NC_ERROR> <FILEID>2011</FILEID> <SUMMARY> <NB_PAYMENTS>3</NB_PAYMENTS> <OK_PAYMENTS>2</OK_PAYMENTS> <RANGE_START>37267</RANGE_START> <RANGE_STOP>37269</RANGE_STOP> </SUMMARY> </PROCESSING> </AFU_REPLY> Ejemplo: Solicitud en modo ASYNC Solicitud en modo ASYNC <form action="https://ogone.test.v-psp.com/ncol/test/AFU_agree.asp" method=POST> <input type=text name=PSPID value=”FishShop1”> <input type=text name=USERID value=”FishAPI”> <input type=text name=PSWD value=”MySecret81”> <input type=text name=REPLY_TYPE value=”XML”> <input type=text name=MODE value=”ASYNC”> <input type=text name=PFID value=”2010”> <input type=text name=PROCESS_MODE value=”PROCESS”> </form> Respuesta XML <?xml version="1.0" ?> <AFU_REPLY> <PROCESSING> <FILEID>2011</FILEID> <SUMMARY> <NB_PAYMENTS>3</NB_PAYMENTS> </SUMMARY> </PROCESSING> </AFU_REPLY> |
4.3 Etiquetas de respuesta XML
Etiqueta | Descripción |
---|---|
<AFU_REPLY> | Respuesta de carga de archivo automática |
<PARAMS_ERROR> |
Errores de parámetros generales |
<PARAM> |
Nombre de parámetro |
<ERROR> |
Descripción de error |
<FILE_ERROR> |
Error de procesamiento de archivo |
<ERROR> |
Descripción de error |
<FORMAT_CHECK> |
Comprobación de formato de transacción individual |
<FILEID> |
ID de archivo numérico designado por nuestro sistema |
<GUID> |
Identificador de inicio de sesión alfanumérico para el archivo designado por nuestro sistema. Este GUID se designa la primera vez que envía un archivo (solo una vez por FileID). Si desea procesar el archivo o realizar otra operación válida (o descargar en el nivel de archivo, etc.), puede enviar este GUID en lugar de los parámetros de inicio de sesión descritos anteriormente. Sirve como formato de contraseña, otorgando acceso únicamente a este archivo específico. |
<FORMAT_CHECK_ERROR> |
Error de formato de transacción |
<LINE> |
Número de línea correspondiente del archivo |
<ERROR> |
Descripción de error |
<NCERROR> |
Código de error numérico |
<PROCESSING> | Carga de las transacciones individuales |
<NC_ERROR> | Error de carga |
<LINE> | Línea de pago |
<PAYID> | PAYID de nuestro sistema |
<NCSTATUS> | Estado de error (primer dígito de NCERROR) |
<STATUS> | Estado del PAYID después de haber cargado la transacción |
<NCERROR> | Código de error numérico |
<NCERRORPLUS> | Descripción de error |
<SUMMARY> | Resumen del archivo |
<NB_PAYMENTS> |
Número de pagos recibidos |
<OK_PAYMENTS> |
Número de pagos con formato correcto |
<RANGE_START> |
Primer PAYID (solo para nuevos pedidos ATR) |
<RANGE_STOP> |
Último PAYID (solo para nuevos pedidos ATR) |
<NB_ALIAS> |
Número de operaciones de alias |
<NB_SUBSCRIPTION> |
Número de operaciones de suscripción |
4.4 Seguridad
4.4.1 Solicitudes seguras
Las funciones de carga y descarga automática de archivos se crean en un sólido protocolo de comunicación segura.El API de lote es un conjunto de instrucciones enviadas con solicitudes HTTPS Post estándar. Solo permitimos que el comerciante nos contacte en modo https seguro.
No es necesario un certificado SSL de cliente.
4.4.2 Dirección IP
La dirección o las direcciones IP o el rango o los rangos IP de los servidores desde los que nos envía solicitudes se pueden configurar en el campo de dirección IP de la pestaña "Verificación de datos y origen", sección Comprobaciones de lote automático de la página Información técnica de su cuenta. Comprobaremos la dirección IP cuando realice la solicitud de una carga o descarga de archivo automática.
Si la dirección IP desde la que se ha originado la solicitud no se ha definido en el campo de dirección IP de la pestaña "Verificación de datos y origen", sección Comprobaciones de lote automático de la página Información técnica de su cuenta, recibirá el mensaje de error “pedido desconocido/1/i”. La dirección IP desde la que se envió la solicitud también aparecerá en el mensaje de error.
5. Proceso de descarga automático
Puede descargar un archivo de pago (resultados de transacción) de forma manual a través del área de administración o automáticamente (a través de una aplicación).
Este capítulo describe la descarga automática de archivos y la página de elaboración de informes electrónicos. Vaya a Lote básico para obtener más información sobre las descargas de archivos manuales y cómo consultar archivos en el área de administración.
5.1 Parámetros y URL de solicitud
Su aplicación envía una solicitud HTTPS a la siguiente página de nuestro servidor:
- La URL de solicitud en el entorno de PRUEBA es https://ogone.test.v-psp.com/ncol/test/payment_download_ncp.asp (se utilizará en más ejemplos)
- La URL de solicitud en el entorno de PRODUCCIÓN es https://secure.ogone.com/ncol/prod/payment_download_ncp.asp
Los parámetros deben enviarse usando el método POST.
Campo | Descripción / Valor |
---|---|
PSPID | Su nombre de afiliación en nuestro sistema |
USERID | Nombre de su usuario API |
PSWD | Contraseña de su usuario API |
level | Selección del nivel de pago. Posibles valores:
|
ofd | Fecha de pedido ‘desde’ el día (DD) |
ofm | Fecha de pedido ‘desde’ el mes (MM) |
ofy | Fecha de pedido ‘desde’ el año (AAAA) |
otd | Fecha de pedido ‘hasta’ el día (DD) |
otm | Fecha de pedido ‘hasta’ el mes (MM) |
oty | Fecha de pedido ‘hasta’ el año (AAAA) |
afd | Fecha de pago ‘desde’ el día (DD) |
afm | Fecha de pago ‘desde’ el mes (MM) |
afy | Fecha de pago ‘desde’ el año (AAAA) |
atd | Fecha de pago ‘hasta’ el día (DD) |
atm | Fecha de pago ‘hasta’ el mes (MM) |
aty | Fecha de pago ‘hasta’ el año (AAAA) |
arch | Enviar el valor "arch" con este campo si la descarga contendrá transacciones más antiguas de 45 días. |
PM | Método de pago |
BRAND | Marca de la tarjeta |
CARDNO | Número de cuenta/tarjeta |
orderID | Su referencia del pedido |
Company | Empresa del cliente |
facname1 | Nombre del cliente |
PAYID | La referencia de nuestro sistema para el pago |
ID | FileID de un archivo cargado previamente (referencia de nuestro sistema) |
status | Lista de estados específicos (código numérico) separados por “,”. |
OnlyIfProcessed | Indica que solo deben descargarse los archivos con el estado “Procesado”. Si el archivo todavía no se ha procesado, nuestro sistema mostrará el mensaje: “El archivo aún no se ha procesado: inténtelo de nuevo más tarde...” (para seleccionar: OnlyIfProcessed =“1”). |
stok | Solo en combinación con “OnlyIfProcessed”. Seleccionar todas las transacciones aceptadas (estado 5, 6, 7, 74, 85, 8, 84, 85, 9, 94, 95) de un archivo procesado (para seleccionar: stok=“1”). |
sterr | Solo en combinación con “OnlyIfProcessed”. Seleccionar todas las transacciones rechazadas (estado 2, 63, 73, 83, 93) de un archivo procesado (para seleccionar: stok=“1”). |
st1 | Estado 0, 1, 51, 71, 81, 91. (Para seleccionar: st1=“1”) |
st2 | Estado 2. (Para seleccionar: st2=“1”) |
st3 | Estado 5. (Para seleccionar: st3=“1”) |
st4 | Estado 9, 94. (Para seleccionar: st4=“1”) |
st5 | “Otros” estados: todos los estados distintos de los de st1, st2, st3, st4 y st6 (para seleccionar: st5=“1”) |
st6 | Estados 7, 8, 87, 84 (para seleccionar: st6=“1”) |
Especificación de Informes electrónicos (optional): | |
Estructura | Estructura de archivo. Valores posibles:
|
Formato |
Formato de archivo Valores posibles:
|
Sep | Separador en caso de que el formato de archivo sea DEL (delimitado). Separador predeterminado: “;”. |
headers | Cabeceras de descarga de archivos (para seleccionar cabeceras =“1”) |
GR1 | Primer criterio para agrupar pagos. Valores posibles:
|
GR2 | Segundo criterio para agrupar pagos. Posibles valores: consulte GR1. |
GR3 | Tercer criterio para agrupar pagos. Posibles valores: consulte GR1. |
Observaciones importantes:
- Para la fecha, utilice ofd, ofm, ofy, otd, otm, oty, para buscar en el nivel del pedido (fecha de pedido) o afd, afm, afy, atd, atm, aty para buscar en el nivel del historial (fecha de pago). Es obligatorio incluir la fecha al enviar sus solicitudes, a menos que se envíe el FileID o PAYID.
- Para los estados, solo debe usar una de las siguientes opciones:
- estado
- stok, sterr en combinación con OnlyIfProcessed
- st1, st2, st3, st4, st5, st6
Ejemplo El comerciante desea recuperar todos los pedidos cuya autorización se ha rechazado con una fecha de pedido entre el 1 y el 15 de junio de 2007. <form action="https://ogone.test.v-psp.com/ncol/test/payment_download_ncp.asp" method=POST> |
5.2 Formato: Notificación electrónica
En la página Informes electrónicos (enlace “Informes electrónicos” del menú de su área de administración), puede establecer el formato y la estructura que desea usar para informes electrónicos como descargas de archivos (cuando se activan los informes push en su cuenta, el enlace de informes electrónicos le ofrecerá acceso a una lista de sus informes push).
El formato de archivo se puede establecer por usuario. Si desea cambiar la configuración de los informes electrónicos para un usuario API, puede hacerlo a través de la página Administración de usuarios (enlace “Usuarios” del botón > “Editar” en el menú situado junto al enlace > “Formato de archivo>>>” del usuario API).
5.2.1 Estructura de archivo
La estructura define el tipo de información disponible para cada transacción. Los archivos de resultado de pago se pueden descargar en 4 estructuras diferentes: "Estándar", "Ampliada", "Administración de archivos" o “Dinámico”.
La descripción completa de estas estructuras está disponible a través del enlace "Más información" de la página Informes electrónicos. Consulte los enlaces de esta página para los nombres de etiqueta XML, la descripción, el tamaño y el formato de los campos de descarga.
5.2.2 Formato de archivo
Existen tres formatos diferentes para descargas de archivo: delimitado, XML y de longitud fija. A continuación, se indica el diseño y un ejemplo de cada uno de ellos. La estructura de archivo usada en los ejemplos es “Estándar”.
Delimitado
Diseño <DOWNLOAD_REPLY> Principio del archivo<TRANSMISSION Cadena de descripción> Lista secuencial de pagos: cada línea corresponde a un pedido. Cada campo está separado por el separador especificado en la página “Informes electrónicos”. Cada aparición de un separador en un valor de campo se sustituye por un espacio en blanco. <END_TRANSMISSION> Final de la selección de pagos |
Ejemplo <DOWNLOAD_REPLY> |
XML
Diseño <?xml version="1.0"?><DOWNLOAD_REPLY> Principio del archivo En caso de un error: <SYSTEM_ERROR>: Mensaje de error del sistema <PARAMS_ERROR>: Mensaje de error de parámetros <NCERROR>: Código de error numérico o <WARNING>El archivo aún no se ha procesado: inténtelo de nuevo más tarde...</WARNING> <Atributos de TRANSMISSION: LEVEL, DESCRIP> Principio de la transmisión <Atributos de GROUP1: ACTION, BRAND, FILE, METHOD, STATUS, DATE > Principio de Group1, hasta 3 grupos son posibles. Los atributos dependen del grupo seleccionado. <Atributos de PAYMENT: ID, REF, ORDER, STATUS, LIB, ACCEPT, NCID, NCSTER, PAYDATE, CIE, NAME, COUNTRY, TOTAL, CUR, METHOD, BRAND, CARD, UID, STRUCT, FILEID, ACTION, TICKET, PSPID, DESC> Descripción del pago. Los atributos dependen de la estructura de archivo seleccionada. </TRANSMISSION> final de transmisión </DOWNLOAD_REPLY> final de archivo |
Ejemplo <?xml version="1.0"?><DOWNLOAD_REPLY> <TRANSMISSION LEVEL="Order" DESCRIP="- Order date 12/04/2007- Status All except Cancelled by client,Invalid or incomplete-"> <PAYMENT ID="1651818" REF="order0001" ORDER="12/4/2007" STATUS="5" LIB="Authorised" ACCEPT="testoff" PAYDATE="" CIE="" NAME="Paul Smith" COUNTRY="" TOTAL="120.00" CUR="EUR" SHIP="0.00" TAX="0.00" METHOD="CreditCard" BRAND="VISA" CARD="XXXXXXXXXXXX1111" STRUCT=""></PAYMENT> <PAYMENT ID="1651819" REF="order0002" ORDER="12/4/2007" STATUS="5" LIB="Authorised" ACCEPT="testoff" PAYDATE="" CIE="" NAME="Bill Durand" COUNTRY="" TOTAL="56.00" CUR="EUR" SHIP="0.00" TAX="0.00" METHOD="CreditCard" BRAND="Eurocard" CARD="XXXXXXXXXXXX9999" STRUCT=""></PAYMENT> </TRANSMISSION> </DOWNLOAD_REPLY> |
Longitud fija
Diseño <DOWNLOAD_REPLY> Principio del archivo<TRANSMISSION Cadena de descripción> Lista secuencial de pagos: cada línea corresponde a un pedido. La longitud de cada campo se describe en una página que puede comprobar a través del enlace "Más información" de la página Informes electrónicos. <END_TRANSMISSION> Final de la selección de pagos |
Ejemplo <DOWNLOAD_REPLY><TRANSMISSION Order Level: - Order date 12/04/2007- Status All except Cancelled by client,Invalid or incomplete-> 1651818 order0001 12/4/2007 5 Authorised testoff Paul Smith 120.00EUR 0.00 0.00 CreditCard VISA XXXXXXXXXXXX1111 1651819 order0002 12/4/2007 5 Authorised testoff Bill Durand 56.00EUR 0.00 0.00 CreditCard Eurocard XXXXXXXXXXXX9999 <END_TRANSMISSION> |
5.2.3 Características extra
Agrupación de pagos
Puede agrupar los pagos en su descarga, según determinados criterios/valores. Puede establecer estos criterios en las listas desplegables de “Ordenar por” de la “página Informes electrónicos”. Se pueden seleccionar tres valores diferentes, lo que permite al comerciante crear subgrupos. Dentro de un grupo, se pueden ordenar los pagos según el valor del subgrupo. Por ejemplo:
<GROUP1 FILE="1">
<GROUP2 STATUS="5">
<GROUP3 BRAND="EUROCARD">
<END_GROUP3>
<GROUP3 BRAND="VISA">
<END_GROUP3>
<END_GROUP2>
<GROUP2 STATUS="2">
<GROUP3 BRAND="EUROCARD">
<END_GROUP3>
<GROUP3 BRAND="VISA">
<END_GROUP3>
<END_GROUP2>
<END_GROUP1>
El siguiente ejemplo ilustra una descarga Estándar (estructura), Delimitado (formato), Ordenar por (desplegable 1) y Marca (desplegable 2).
Ejemplo <DOWNLOAD_REPLY><TRANSMISSION Order Level: - Order date 12/04/2007- Status All except Cancelled by client,Invalid or incomplete-> <GROUP1 FILE="40555"> <GROUP2 BRAND="EUROCARD"> 1651819;order0002;12/4/2007;5;Authorised;testoff;;;Bill Durand;;56.00;EUR;0.00;0.00;CreditCard;Eurocard;XXXXXXXXXXXX9999;; 1651821;order0004;12/4/2007;5;Authorised;testoff;;;Mark van Steen;;33.00;EUR;0.00;0.00;CreditCard;Eurocard;XXXXXXXXXXXX9999;; <END_GROUP2> <GROUP2 BRAND="VISA"> 1651818;order0001;12/4/2007;5;Authorised;testoff;;;Paul Smith;;120.00;EUR;0.00;0.00;CreditCard;VISA;XXXXXXXXXXXX1111;; 1651820;order0003;12/4/2007;5;Authorised;testoff;;;Jef Geeraerts;;75.10;EUR;0.00;0.00;CreditCard;VISA;XXXXXXXXXXXX1111;; <END_GROUP2> <END_GROUP1> <GROUP1 FILE="40558"> <GROUP2 BRAND="EUROCARD"> 1651834;order5553;12/4/2007;5;Authorised;testoff;;;John Smith;;75.10;EUR;0.00;0.00;CreditCard;Eurocard;XXXXXXXXXXXX9999;; <END_GROUP2> <GROUP2 BRAND="VISA"> 1651835;order5555;12/4/2007;5;Authorised;testoff;;;John Doe;;50.32;EUR;0.00;0.00;CreditCard;VISA;XXXXXXXXXXXX1111;; 1651836;order5558;12/4/2007;5;Authorised;testoff;;;Jane Doe;;86.42;EUR;0.00;0.00;CreditCard;VISA;XXXXXXXXXXXX1111;; <END_GROUP2> <END_GROUP1> <END_TRANSMISSION> |
Cabeceras
Puede indicar si desea que los registros de pago tengan o no cabeceras.
Un archivo sin cabeceras contiene solo las líneas de transacción. Si desea utilizar las etiquetas <DOWNLOAD_REPLY>, <TRANSMISSION> o <GROUP>, deberá habilitar la casilla “Cabeceras”.
6. Prueba de carga y descarga automáticas
Nuestro servidor aloja varias páginas de prueba (URL) que puede ejecutar en su navegador para simular el proceso de carga. Estas URL solo sirven para fines de prueba, para establecer los datos que su sistema debe enviar y los datos que reciba como respuesta:
Acción | URL de prueba en el navegador |
---|---|
Cargar: Enviar y comprobar | https://ogone.test.v-psp.com/ncol/test/AFU_step1.asp |
Cargar: Proceso | https://ogone.test.v-psp.com/ncol/test/AFU_step2.asp |
Descargar: Comprobar estado de archivo | https://ogone.test.v-psp.com/ncol/test/AFU_step3.asp |
Descargar archivo de transacción | https://ogone.test.v-psp.com/ncol/test/AFU_step4.asp |
7. Estados de archivo
Estados de archivo predeterminados:
- Cargado: el archivo se ha recibido pero no se ha validado (paso SEND).
- A comprobar: el archivo está pendiente de validación. (cuando solicita PROCESS en modo ASYNC para un archivo “Cargado”).
- Comprobado: el archivo se ha validado (paso CHECK).
- Cancelado: el archivo se ha cancelado tras el paso ‘Comprobar’.
- A cargar: el archivo espera a cargarse en nuestro módulo de procesos (cuando solicita un PROCESS en modo ASYNC para un archivo “Comprobado”).
- Cargando: el archivo se está cargando en nuestro módulo de proceso.
- Cargado: el archivo se ha cargado en nuestro módulo de proceso, pero (todos) los pagos todavía no se han enviado a las entidades adquirentes o los bancos.
- Procesado: todos los pagos del archivo se han enviado a las entidades adquirentes o los bancos.
- A dividir: el archivo cumple con los criterios genéricos y se enviará para su división.
- En división: el archivo se está dividiendo actualmente.
8. Especificidades del método de pago
Para determinados métodos de pago, los valores de BRAND/CARDNO/ED difieren de los valores de tarjeta de crédito estándar.
8.1 Domiciliaciones
8.1.1 Domiciliaciones AT
Estos son los valores de campo BRAND/CARDNO/ED específicos que habilitan transacciones de Domiciliaciones bancarias AT que deberán transmitirse a través de Fichero de Lote.
Nº. de archivo / Campo | Valor específico |
---|---|
3 / BRAND | “Domiciliaciones AT” |
4 / CARDNO | Número de cuenta bancaria. Formato: XXXXXXXXXXBLZYYYYY XXXXXXXXXXX: número de cuenta, numérico, 11 dígitos. YYYYY: Código de banco (Bankleitzahl), 5 dígitos. |
5 / ED | “99/99” o “9999” |
8.1.2 Domiciliaciones DE (ELV)
Estos son los valores de campo que permiten la transmisión de transacciones ELV a través de Lote:
Nº. de archivo / Campo | Descripción |
---|---|
3 / BRAND |
“Domiciliaciones DE:” Obligtorio |
4 / CARDNO | Número de cuenta bancaria + BLZ. Formato: XXXXXXXXXBLZYYYYYYYY XXXXXXXXXX: número de cuenta, numérico, de 1 a 10 dígitos. YYYYYYYY: Código de banco (Bankleitzahl), 8 dígitos. O Número de cuenta IBAN 22 caracteres alfanuméricos (SEPA) Obligatorio |
5 / ED |
“99/99” o “9999” Obligatorio |
Opcional para transacciones SEPA (*) (no aplicable para Billpay): | |
39 / MANDATEID |
Referencia de autorización unívoca. Optional |
(*SEPA: Single Euro Payments Area o Zona Única de Pagos en Euros)
8.1.3 Domiciliaciones NL
Estos son los valores de campo que habilitan transacciones de Domiciliaciones que se transmitirán a través de Lote:
Nº. de archivo / Campo | Descripción |
---|---|
3 / BRAND | “Domiciliaciones NL” |
4 / CARDNO |
Número de cuenta IBAN: máx. 35 caracteres alfanuméricos O Número de cuenta holandés normal: máx. 10 caracteres (si tiene menos, complete con ceros a la izquierda). Obligatorio |
5 / ED |
“99/99” o “9999” Obligatorio |
Solo relevante para transacciones SEPA (*) : | |
8 / CN |
Nombre del titular de la cuenta bancaria Obligatorio |
10 / OPERATION | Acción que debe realizarse. Valores posibles:
Obligatorio |
38 / BIC |
Código identificador de banco. Formato: máx. 11 caracteres AN Obligatorio |
39 / MANDATEID |
Referencia de autorización unívoca. Obligatorio |
40 / SIGNDATE |
Fecha en la que el comprador firmó la autorización. Formato: AAAAMMDD Si no se proporciona, se utilizará la fecha de la transacción Obligatorio |
41 / SEQUENCETYPE | Posibles valores para indicar el tipo de transacción de Domiciliaciones (máx. 4 dígitos AN):
Si no se proporciona, se utilizará la fecha de la transacción Obligatorio |
(*SEPA: Single Euro Payments Area o Zona Única de Pagos en Euros)
8.2 Métodos de pago con solo mantenimiento a través de Fichero de Lote
Para determinados métodos de pago (tarjeta que no sea de crédito), no puede enviar nuevas transacciones a través de Lote, pero puede enviar determinadas operaciones de mantenimiento a través de Lote.
Es el caso de la tarjeta PostFinance, PostFinance E-finance, compra mediante PayPal Express y TUNZ.
Cuando se envían operaciones de mantenimiento, BRAND/CARDNO/ED no son datos necesarios, así que, para estos métodos de pago, no deben enviarse valores específicos.
8.3 Programa de registro avanzado de Maestro/MasterCard
Activación Debe ponerse en contacto con nuestro equipo de ventas o su administrador de cuentas dedicado para comprobar si cumple los requisitos para usar la característica MARP. Una de las condiciones que debe cumplirse es que su entidad adquirente admita MARP. |
El programa de registro avanzado de Maestro/MasterCard (Maestro/MasterCard Advanced Registration Program, MARP) es un sistema que le permite procesar las transacciones subsecuentes de los clientes existentes, sin tener que realizar cada vez una comprobación de 3-D Secure.
Esta característica es especialmente interesante para comerciantes que tengan muchos clientes existentes o que deseen realizar una facturación normal con permiso del cliente.
El riesgo eventual lo asume el comerciante, ya que es responsable de supervisar la primera transacción confirmada por 3-DS o mediante PIN.
Como es necesaria una comprobación de 3-D Secure para la transacción inicial (a través de Página de pago alojada o DirectLink), solo las transacciones posteriores podrán procesarse a través de Fichero de Lote.
Se prevé la posición 37 de la línea de transacción para el campo "ARP_subsequent", en la que deberá introducir el valor "1" (cualquier otro valor se considerará "0", y como tal, sin valor).
El valor ECI (posición 35) solo puede ser 9 (=Periódico tras primera transacción de comercio electrónico).
Ejemplo 1213;EUR;;5399999999999999;12/25;Order0001;;Paul Smith;;SAL;;;;;;;;;;;;;;;;;123;;;;;;;;9;;1;; (9: ECI, 1: ARP_subsequent) |
En el área de administración de Worldline, cuando se consulta la visión general de una transacción, aparecerá el valor de "ARP_initial" o "ARP_subsequent" (en caso de lote).
9. Otros formatos de archivo
9.1 Tarjetas de compra (e-Supply)
La estructura y el formato de los archivos de pago de e-Supply deben cumplir con algunas reglas básicas:
- El archivo debe ser un archivo de texto ASCII
- Varias líneas por factura/pedido (salvo para transacciones sin Detalles de partida) con las líneas separadas por los caracteres de carro de retorno y avance de línea (ASCII : 13 10 – HEX : 0xD 0xA)
- Cada línea debe contener campos relevantes (correspondientes al TIPO de registro) separadas por un punto y coma (“;”)
- Los propios campos no pueden contener ningún punto y coma (“;”)
- Estructura de archivo:
El archivo puede incluir varios pedidos/facturas. Para cada pedido/factura, debe usar un grupo de varios registros:
- INV: Registro de cabecera de pedido/factura (1 registro por factura/pedido)
- CLI: Registro de detalles de cliente (opcional, 0 o 1 registro por factura/pedido)
- DET : Registros detallados de partida de factura/pedido (obligatorio, 1 a x por factura/pedido)
Cabecera
INV ;….. ;
DET;…..;
DET;…..;
DET;…..;
INV ;….. ;
CLI;……;
DET;…..;
DET;…..;
INV ;….. ;
DET;…..;
DET;…..;
……
Pie de página
Consulte las hojas de cálculo Excel de e-Supply (disponibles a través de Asistencia > Integración y manuales de usuario de su cuenta) para obtener una descripción detallada de los registros INV, CLI y DET.
9.2 Otros
Podemos aceptar otros formatos de archivo como, por ejemplo, CARUS, DMP y PLINK. Consulte las especificaciones de formato correspondientes para estos formatos de archivo.
Para indicar que está usando un formato de archivo diferente del formato predeterminado descrito en este documento, puede usar la siguiente cabecera:
OFM;FILE_FORMAT;
Por ejemplo:
OFM;NCSERVER;
Si envía sus archivos de forma automática, esta información solo podrá enviarse como cabecera y no como parámetro.
Preguntas más frecuentes
En el menú de su cuenta de Worldline, puede fácilmente buscar las transacciones seleccionando "Operaciones" y haciendo clic en "Ver transacciones" o "Historial financiero", dependiendo del tipo de resultados de transacción que busque.
Vaya a Consulte sus transacciones para obtener más información.
De forma predeterminada, puede enviar bienes o entregar su servicio después de que una transacción haya alcanzado el estado "5 - Autorizado" o "9 - Pago solicitado". No obstante, aunque el estado 5 es un estado satisfactorio, es únicamente una reserva temporal de un importe de dinero en la tarjeta del cliente. Una transacción en estado 5 sigue necesitando ser confirmada (manual o automáticamente), para pasar el estado 9, que es el estado satisfactorio final de la mayoría de los métodos de pago.
Vaya a Estados de transacciones para obtener más información.
Puede reembolsar un pago fácilmente con el botón "Reembolso" en la descripción del pedido de una transacción (mediante Ver transacciones). Si su cuenta lo admite, también puede realizar reembolsos con una solicitud de DirectLink o con una carga de archivo de Fichero de Lote (para varias transacciones).
Tenga en cuenta que la opción Reembolsos debe estar activada en su cuenta.
Vaya a Mantenimiento de transacciones para obtener más información.
Si desea comprobar los detalles específicos de un pedido o una transacción, o realizar el mantenimiento en las transacciones, debe utilizar "Ver transacciones".
El "historial financiero" es lo más cómodo para comprobar periódicamente los fondos entrantes y salientes por (lotes de) transacciones, y realizar la conciliación.
Si desea obtener más información, vaya a Ver transacciones frente a Historial financiero
Solo puede realizar reembolsos en transacciones cuyo estado es "9 - Pago solicitado". Se puede realizar una cancelación o eliminación tras aproximadamente 24 horas de haber recibido un estado definitivo ( 5-Autorizado o 9 – Pago solicitado ) .
Para conocer la hora límite de la entidad adquirente, le recomendamos que consulte con el departamento de atención al cliente.