1. Home
  2. Soluciones de integración
  3. Integraciones
  4. Worldline Fichero de Lote (avanzado)

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:

  • RES: solicitud de autorización
  • SAL: solicitud de venta directa (pago)
  • RFD: reembolso, no vinculado con un pago anterior, por ejemplo, una operación que no sea de mantenimiento en una transacción existente (no se puede utilizar esta operación sin permiso específico de su entidad adquirente).

Opcional:

  • PAU: Solicitud de preautorización
    De acuerdo con la entidad adquiriente puede utilizar este código de operación para reservar de forma temporal el saldo de la tarjeta de un cliente. Se trata de una práctica común en el sector de viajes y alquiler.
    En estos momentos, PAU/preautorización solo se puede utilizar en transacciones de MasterCard y es compatible con entidades adquirientes seleccionadas. Este código de operación no se puede definir como valor predeterminado en su cuenta de Worldline.
    En el caso de que utilice PAU en transacciones a través de entidades adquirientes o con marcas de tarjetas que no admiten preautorización, estas transacciones no se bloquearán, sino que se procesan como autorizaciones (RES) normales.

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.

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:

  • ATR: código para nuevos pedidos (transacciones)
  • MTR: código para operaciones de mantenimiento en transacciones existentes
Cualquier archivo cargado se convierte de forma automática en un archivo ATR hasta que especifique lo contrario en la cabecera del archivo.
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 parcial

Mike 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:

  1. 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.
  2. 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:
  • XML (predeterminado)
  • HTML
La respuesta HTML contiene la misma página que cuando un archivo se carga de forma manual.
PROCESS_MODE

Posibles valores para el modo de procesamiento:

  • SEND: se carga un nuevo archivo pero no se solicita ninguna comprobación de formato
  • CHECK: se solicita una comprobación de formato (corresponde al paso 2 de la carga manual de archivos)
  • PROCESS: se solicita el procesamiento del archivo ya cargado (corresponde al paso 3 de la carga manual de archivos)
  • CANCEL: se solicita la cancelación de un archivo ya comprobado (pero no cargado) (corresponde el botón de cancelación posterior al paso 2 de la carga manual de archivos)
  • Algunos pasos también se pueden combinar (no recomendado):
  • CHECK: puede combinar SEND y CHECK (el archivo de transacción se transmite con PROCESS_MODE=CHECK pero sin el FileID de nuestro sistema, que normalmente se devuelve tras el paso SEND).
  • CHECKANDPROCESS: puede combinar CHECK y PROCESS o SEND, CHECK y PROCESS.
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:

  • SYNC (predeterminado)
  • ASYNC

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:
  • ORDERLEVEL (valor predeterminado)
  • HISTLEVEL (nivel de historial financiero)
  • FILELEVEL
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:
  • STD (estándar)
  • EXT (ampliado)
  • MNG (administración de archivos)
  • DYN (dinámico)
Formato

Formato de archivo Valores posibles:

  • XML
  • FIX (longitud fija)
  • DEL (delimitado)
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:
  • LASTACTION
  • BRAND
  • ORDERDATE
  • PFID (referencia de archivo cargado)
  • PAYMENTMETHOD
  • STATUS
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>
<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=level value=”ORDERLEVEL”>
<input type=text name=ofd value=”01”>
<input type=text name=ofm value=”06”>
<input type=text name=ofy value=”2007”>
<input type=text name=otd value=”15”>
<input type=text name=otm value=”06”>
<input type=text name=oty value=”2007”>
<input type=text name=st2 value=”1”>
</form>

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>
<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.00;EUR;0.00;0.00;CreditCard;VISA;XXXXXXXXXXXX1111;;
1651819;order0002;12/4/2007;5;Authorised;testoff;;;Bill Durand;;56.00;EUR;0.00;0.00;CreditCard;Eurocard;XXXXXXXXXXXX9999;;
<END_TRANSMISSION>


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.
Opcional (la opción "división por lotes implícita" debe estar habilitada para su cuenta) para los archivos que contienen más de 2750 líneas:
  • 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.
Telego: Formato: máx. 35 caracteres AN (conjunto de caracteres: “A-Z a-z 0-9 espacio /-?:().,'+”)
Si no se proporciona, la plataforma utilizará el ORDERID o PAYID
Easycash: Formato: máx. 27 caracteres AN (conjunto de caracteres: “A-Z a-z 0-9 espacio /-?:().,'+”)
Si no se proporciona, Easycash generará un valor.

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:
  • SAL/SAS: dinero de débito de la cuenta bancaria
  • RFD/RFS: dinero de crédito a la cuenta bancaria/reembolso

Obligatorio
38 / BIC

Código identificador de banco. Formato: máx. 11 caracteres AN

Obligatorio
39 / MANDATEID

Referencia de autorización unívoca.
Telego: Formato: máx. 35 caracteres AN (conjunto de caracteres: “A-Z a-z 0-9 espacio /-?:().,'+”)
Si no se proporciona, la plataforma utilizará el ORDERID o PAYID
Easycash: Formato: máx. 27 caracteres AN (conjunto de caracteres: “A-Z a-z 0-9 espacio /-?:().,'+”)
Si no se proporciona, Easycash generará un valor.

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):
  • "FRST": Primer grupo de una serie de instrucciones de Domiciliaciones
  • "RCUR": Instrucciones de Domiciliaciones en las que se utiliza la autorización del deudor para transacciones de Domiciliaciones normales iniciadas por el acreedor
  • "FNAL": Primer grupo de una serie de instrucciones de Domiciliaciones (posteriormente no se puede volver a utilizar el mismo MandateID)
  • "OOFF": Orden de adeudo directo en la que se utiliza la autorización del deudor para iniciar una única transacción de domiciliación

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.