Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux,...

50
Secure ePayments Manual de Producto The world’s local bank

Transcript of Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux,...

Page 1: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

Secure ePayments

Manual de Producto

The world’s local bank

Page 2: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

Bienvenido a Secure ePayments Secure ePayments, servicio provisto por HSBC en forma exclusiva en el mercado bancario, es un servicio que permite autorizar en forma On-line operaciones de compra y/o pago con tarjetas de crédito sobre el/los producto/s y/o servicio/s que se ofrezcan a través de un sitio en Internet, en forma totalmente segura y en tiempo real. Este sistema es el equivalente a las terminales que se utilizan en un negocio físico para procesar las tarjetas de crédito, transmitiendo sus datos, para luego realizar la verificación y el pago. En que plataformas puedo Implementar Secure ePayments? Secure ePayments es un servicio orientado a empresas y se adapta perfectamente a cada plataforma en al que operan (Windows, Linux, etc.) brindando información precisa para los niveles gerenciales, administrativos, operativos y sistemas. La interfaz de Secure ePayments es amigable, el orden de la información es lógica, matiene standars intenacionales que favorecen el uso intuitivo del servicio. Es realmente muy fácil implementarlo en su sitio web.

Page 3: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

1. Nuestro sitio www.epayments.hsbc.com.ar El sitio de Secure ePayments cuenta con información institucional y principalmente es el acceso al administrador, para dar de alta el servicio, administrar las ventas y realizar cambios que la empresa adherida necesite.

Como doy de alta el servicio?

Este botón, permite registrarse para conocer el servicio y ser contactado o simplemente para registrarse y empezar a realizar el alta definitiva del servicio.

Una vez que tenga el alta puede realizar todo tipo de operaciones: consultas, reportes, modificaiones, configuraciones, conciliaciones, etc.

Page 4: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

2. Alta del servicio Para dar de alta el servicio, se debe acceder al sitio de Secure ePayments y allí ingresar en la sección “Conozca Secure ePayments On Line” o directamente en la url de ingreso de datos https://www.epayments.hsbc.com.ar/Public/Ssl/RegisterMerchant.aspx, completando el formulario en todos sus campos correspndientes1.

• El Id deberá tener un mínimo de 7 digitos, pudiendo ser alfanumericos. • La Contraseña deberá tener un mínimo de 8 digitos, pudiendo ser alfanumericos,

pero no debe poseer suceciones lógicas (por ejemplo: 111, 1234, AAA, etc.). Una vez completado correctamente el formulario, un ejecutivo de cuentas se contactara con usted a fin de comenzar la implementacion y configuracion del servicio, una vez aprobada su peticion.

1 El registro y alta del usuario es a la vez, el alta de un “grupo de administrador” (ver Grupo de administdor)

Page 5: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

3. Implementacion del servicio La implementación tecnológica es muy sencilla y es soportado por cualquier tipo de plataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de acuerdo al proceso de intercambio de informacion elegido por su empresa y se realiza utilizando el método POST del protocolo http como transporte. Los tipos de intercambio son: a) Formulario con campos Hidden Si lo que desea es implementar un sistema en forma rápida, agíl y muy económico, ésta es la opción correcta. Solo debe “pegar” el código HTML en el lugar que desee, dentro de su pagina web, interconectando ese código, con su carrito de compra, formulario de pedido, etc. Esta interconexión entre su sitio y el formulario Hidden de Secure ePayments, logrará enviar los datos necesarios de la compra para que se pueda efectuar el pago. b) Estructuras de lenguaje XML Este mecanismo basado en el intercambio de mensajes sobre estructuras XML , pero implica un procedimiento mucho más robusto a la hora de implementar el servicio.

Para ello, las estructuras deberán ser encriptadas tanto por el comercio adherido como por Secure ePayments, utilizando un algoritmo de encriptación simétrico.

Cada empresa tendrá asigando un código identificación el cual es asociado a la clave utilizada por el algoritmo de encriptación. Cuando la empresa realiza una transacción con Secure ePayments, envía como parámetros del POST el documento XML encriptado y su shop_id.

A partir del shop_id, Secure ePayments identifica al comercio y obtiene su clave correspondiente para desencriptar el documento XML.

La encriptación se realiza con una API provista por Secure ePayments, y posee como característica que el código encriptado se genera en códigos ASCII representables. Esta API es distribuida en varias versiones, una para plataforma WinNT (en formato COM), para la plataforma Linux y otra para .NET.

Page 6: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

4. Alta del sitio web Ya registrada la empresa y elegido el metodo de intermabio, podemos comenzar a configurar el servicio dentro de Secure ePayments. Debera ingresar a www.epayments.hsbc.com.ar , (aquí de ahora adelante debera ingresar para consultar sus transacciones, realizar modificaciones en la parametria, creacion de nuevos sitios, medios de pago, etc.) para acceder se solicitara el nombre de usuario y contraseña(Ver Fig. siguiente) estos fueron elegidos por usted en el momento de la registracion. Una vez logueado se encuentra en el MENU PRINCIPAL Debemos dar de alta el/los sitios relacionados2 con la empresa o “comercio” adherido. Ingresando desde el menu principal en SITIOS, podra crear el/los sitio que transaccionara, para lo cual debera clickear el boton NUEVO. 2 Dependiendo del esquema contratado una empresa o comercio puede tener uno o más sitios, por ejemplo: esquema Multicomercio (ver Multicomercio)

Page 7: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

Nota: el comercio ya fue dado de alta automaticamente en el proceso de registración de usuario y lleva el nombre descripto en “Nombre del Comercio”. Además será el nombre del Grupo administrador. Una vez ingresado se pedira que complete codigo, descripcion y e e-mail. • El código será el identificador por parte de la empresa y servirá a Secure ePayments

para identificar en todo el procedimiento de intercambio de mensajes.”SHOPCODE” • La descripción es para poder identificar varios sitios del mismo comercio por

ejemplo: en el caso de sucursales SUC001, ALMAGRO, etc. • El email es la casilla de correo en donde Secure ePayments enviará toda clase de

notificaciones. Una vez cargado el SITIO, el personal de Secure ePayments dará el alta a esta petición. Hasta tanto no figure la misma aparecerá el icono “fuera de línea”.

Luego de confirmada la carga, el personal de Secure ePayments pasará a

el nuevo sitio al estado de PRUEBAS. A partir de ahora solo resta dar de alta los correspondientes MEDIOS DE COBRO con los números de comercio o establecimiento y terminal provistas por las tarjetas de credito, con el objetivo de probar el sistema correctamente

Page 8: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

5. Medios de Cobro Definimos Medios de Cobro a las tarjetas que se utilizaran en el/los SITIO/S. correspondiente/s a un COMERCIO.

El alta se realiza desde el MENU PRINCIPAL en la opción COMERCIOS. Luego desde el ícono TARJETAS de credito.

Debera ahora seleccionar el comercio al cual queire aplicar este medio de cobro, para ello, se deplegara un listado de los comercios disponibles (En el caso que huebiese cargado mas de uno). Una vez elegido dicho comercio simplemente puede empezar a cargar los datos del formulario. • El código de comercio, es el número de comercio en el caso de Mastercard y

Amex., y nro. de establecimiento para Visa. Los mismos, son generados por la administradora a través de la adhesión realizada por personal HSBC.

• El código de terminal, número asociado al número de comercio. • Una vez cargado el primer medio de cobro, quedará en “fuera de linea” hasta que

personal de Secure ePayments confirme que los datos ingresados por el comercio sean los correctos.

Page 9: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

Igualemente puede esperar la aceptación, cargar uno nuevo o simplemente modificar lo ingresado. Por cada cargao modificacion debera solicitar, el cambio de estado, para poner operativo el medio de pago. Descripcion de Iconos:

Esperando la aceptación de Secure ePayments.

Confirmado, activo. Modificar los datos del medio de cobro.

Historial de cambios de estado del medio de cobro. Una vez aprobada la petición del medio de cobro, el COMERCIO estará listo para asociarlo al SITIO en donde utilizaremos este medio de pago. Para ello debera volver al MENU PRINCIPAL, seleccionar SITIOS, luego el icono TARJETAS, alli visualizara el icono de las marcas de tarjeta que cargo con un signo de suma sobre ella, si lo oprime y confima esta peticion el SITIO ya tiene dicho medio de cobro asociado.

Ideas y usos 1 El sistema preve el funcionameinto de multiple variantes para la utilizacuión de Secure ePayments Es decir, pueden coexistir en un mismo comercio, varios sitios con iguales medios de cobro, como así tambien un comercio con varios sitios con diferentes medios de cobro para cada sitio y otras combinaciones. Ejemplo 1: Tushop tiene varias sucursales pero la empresa que factura y administra las operaciones es la misma, pero al solo efecto de administrar lo que vende cada sucursal tiene dos sitios diferentes pero administrados en una única cuenta, con sus correspondientes nros. Iguales de comercio:

COMERCIO SITIOS Medios de Cobro N° Comercio TushopSUC1.com TushopSUC2.com Visa 00133333

TushopSUC1.com Tushop S.A.

TushopSUC2.com MasterCard 99001333

Page 10: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

Ejemplo 2: Puede darse que la misma empresa tenga por cada sucursal diferentes nros. de comercio y/o terminal, por lo que el ejemplo quedaría así:

COMERCIO SITIOS Medios de Cobro N° Comercio TushopSUC1.com Visa 00133333 TushopSUC1.com MasterCard 99001333 TushopSUC2.com Visa 00144444 Tushop S.A.

TushopSUC2.com MasterCard 99001444

Page 11: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

6. Grupos de Administración Una vez dado el alta del sitio en Secure ePayments como explica en el punto 2. Alta del servicio, usted habrá creado un grupo de administración. • ¿Qué es un grupo de administración? Se denomina Grupo de Administración, a la/las personas que tienen acceso al a la administracion de Secure ePayments, pudiendo según su perfil, parametrizar técnicamente al comercio, realizar captura, anulación, consultas sobre las transacciones, etc. • ¿Qué perfiles pueden tener los administradores? Según las necesidades de la empresa, puede dar de alta distintos niveles de usuarios según la tarea y/o la responsabilidad que tiene sobre las transacciones y parametria del comercio o sitio. ADMINISTRADOR GENERAL Este perfil es creado por Secure ePayments en el momento que se da el alta al sitio. Es el perfil para el responsable del comercio (Dueño, Gerente Gral., Gerente Comercial, etc.) Permisos: Tiene acceso a todas las funciones del sitio Administrador. Restricciones: No tiene. OPERADOR Este perfil, permite realizar todas las operaciones que requiere el comercio en cuanto a las transacciones. Es el perfil del personal administrativo. Permisos: El operador puede, consultar, capturar, anular transacciones, como así también exportar listados de transacciones, listados de conciliación. Restricciones: Restricciones: El operador no puede, consultar ni modificar la parametria del comercio o sitio, no puede modificar, dar de alta o baja medios de cobro, ni usuarios. CONFIGURADOR Este perfil permite realizar las modificaciones en cuanto a la parametria técnica del comercio. Es el perfil de un webmaster. Permisos: El Configurador puede Restricciones: SOLO CONSULTAS Este perfil permite realizar las consultas de las ordenes y sus estados. Es el perfil para un consultor externo, un controller o un empleado administrativo que realice conciliaciones. Permisos: Solo podrá ver transacciones en sus distintos estados y listados de conciliaciones Restricciones: No podrá realizar ninguna operación de cambios de estado de las transacciones, ni vera parametria del comercio.

Page 12: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

• ¿Cómo doy de alta un usuario? (Esta atribución solo la posee el Administrador general del Comercio) En www.epayments.hsbc.com.ar y luego de loguearse y desde el MENU PRINCIPAL deberá clickear el botón usuarios, le permitirá acceder al formulario para la creación de un nuevo usuario dentro del grupo de administración, para lo cual deberá elegir el perfil que le otorgara a dicho usuario deberá colocar un nombre de usuario y una contraseña, esta ultima dos veces para realizar la verificación, a continuación deberá oprimir el botón Aceptar, y ya a creado un nuevo usuario.

• ¿Cómo consulto los usuarios que están vigentes? (Esta atribución solo la posee el Administrador general del Comercio) En www.epayments.hsbc.com.ar y luego de loguearse deberá clickear el botón usuarios, esto le permitirá acceder al formulario para la Consulta de usuarios existentes dentro del grupo de administración, allí podrá visualizar la lista de usuarios y el perfil correspondiente a los mismos.

Page 13: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

• ¿Cómo doy de baja un usuario? (Esta atribución solo la posee el Administrador general del Comercio) En www.epayments.hsbc.com.ar y luego de loguearse debera clickear el botón usuarios, (Fig.1) esto le permitirá acceder al formulario para realizar la baja de un usuario dentro del grupo de administración, (Fig.4) para lo cual deberá seleccionar el nombre del usuario que desea eliminar y oprimir el boton Eliminar (Fig.5) • ¿Cómo blanqueo o reseteo la password de un usuario? (Esta atribución solo la posee el Administrador general del Comercio) Es posible, pero no lo puede realizar desde el administrador, solo podrá pedir por correo a su ejecutivo de cuentas o al Call Centre. • ¿Si tengo mas de un comercio puedo tener el mismo usuario en ambos? Si, es posible, pero no lo puede realizar desde el administrador, solo podrá pedir la vinculación de uno o más usuarios a los distintos grupos de administración que posea por correo a su ejecutivo de cuentas o al Call Centre. • ¿Si tengo mas de un sitio puedo tener el mismo usuario en ambos? Si, es posible, pero no lo puede realizar desde el administrador, solo podrá pedir la vinculación de uno o más usuarios a los distintos sitios que posea por correo a su ejecutivo de cuentas o al Call Centre. Multicomercio El servicio Secure ePayments preve la existencia de diferentes formatos de negocios de las empresas adheridas. Para dar solucion a estas empresas se creo el concepto de “multicomercio”,, este servicio contituye una verdadera herramienta para las emrpesas que tienen la administración total de los sitios de la cadena de distribución de productos/servicios, franquicias o simplemente empresas que de alguna manera se realacionan a la empresa “madre” o mancomunadora. El concepto general es el de “shopping”, donde un administrador o comercio dispone de la cantidad de sitios que desee, propios o tercerizados por otras empresas para su administracion.

Page 14: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

7. Parametria del SITIO Ultimo paso tecnico antes de comernzar a operar, debera parametrizar el comercio ingresando desde el MENU PRINCIPAL a SITIOS y desde alli ingresar en el icono de parametria. (Si, posee mas de un sitio debera ingresar a la parametria del que necesite actualizar, modificar o crear) Una vez elegido dicho SITIO simplemente puede empezar a cargar los datos del formulario.

Campos obligatorios: Version de formato: en este caso se establece la forma de comunicación elegida anteriormente “Formulario con campos Hidden” o XML de compatibilidad con PU 3.0

Clave de encriptacion (solo para version 3.0 XML): consta de 48 caracteres alfabeticos que seran necesarios para la encriptacion en el posteo de datos hacia Secure ePayments y para la recepcion de los mensajes hacia el sitio. En el manual implementacion tecnica con XML se describe la funcion para programadores.

Page 15: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

Respuesta on- line de Éxito / Error: Se deberan cargar dos URLs para las respuestas enviadas desde Secure ePayments una con éxito y otra para cuando la respuesta es

error. Según el formato de comunicación Secure ePayments enviara un mensaje que se describe a continuacion. Campos que se informan en la respuesta online de exito - Formato 'Formulario con campos Hidden' OrderId OrderCode Quotas MessageDescrip TransferMethodType UserDocId UserDocNumber UserFirstName UserLastName Campos que se informan en la respuesta online de error - Formato 'Formulario con campos Hidden' ErrorId ErrorDescrip OrderCode Ademas es la URL que visualizara el cliente cuando desde Secure ePayments retorne a su pagina. Nota: Las URLs deberan estar cargadas con el prefijo http:// o https:// según corresponda. Campos de decisión comercial: Estos campos no son obligatorios pero parametrizarlos lo ayudaran con la administracion y la comunicación con su cliente: ¿Desea enviar un mail al comprador notificando la recepcion del carrito? Este check box si esta tildado realiza el envio via e-mail de un link con la informacion para que el comprador pueda retornar una compra fallida. ¿Desea utilizar Captura Automática? Este check box si esta tildada CAPTURARA todas las transacciones que autoricen las marcas de tarjetas en forma automatica. Para utilizar este también deberá estar parametrizado en el formulario posteado.

Page 16: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

Tiempo para Capt. Automática en minutos (5 a 1440): En el box podra colocar cual es el retardo expresado en minutos para que se realice la CAPTURA automatica. ¿Utiliza Not. Asincrónica? En este caso debera elegir si desea recibir la notificacion de la transaccion a una URL o e-mail, prefijados, en tiempo real cuando se autoriza la transaccion, de esta manera se estaria informando antes que el comprador. Dirección url: Debera ingresar la direccion URL con http//: donde desea recibir la informacion. Versión de formato: Debera elegir el mismo formato que los anterios en envio de la informacion. Notificacion asincronica por e-mail ¿Desea que le enviemos las notificaciones? Se le enviara la notificacion a la casilla que elija. ¿Desea enviar un e-mail al Comprador por cada autorización? Si tilda este check box se le enviara un e-mail al comprador indicando la autorizacion y el importe de la misma. ¿Desea mostrar el ticket de pago en cada autorización? Si tilda este check box el cliente luego de una transaccion exitosa vera el ticket que se adjunta en la imagen a continuacion durante 15 segundos antes de dirigirlo a la Url de respuesta OK.

Page 17: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

Administracion de ordenes de Pago Administrar las ordenes de pago, es de vital importancia para su empresa, por ello este capitulo esta dedicado enteramente a la comprension total de la utilizacion y poder extraer el mejor resultado para su empresa. Desde el MENU PRINCIPAL, luego de loguaerse, debera ingresar por ORDENES, desde alli podra consultar el historial de transacciones o filtrar las ordenes con distintos criterios, utilizando el siguiente menu, clickeando en la opcion que desee. Comercio: Filtro utilizado cuando posee mas de un comercio o sitio. Medio de Pago: Podra listar las ordenes que se realizaron según la marca de tarjeta que se utilizo. Fecha: Es el filtro mas utilizado, lista un periodo entre dos fechas con dia, mes y año. Orden: Da la posibilidad de listar una orden ingresando su numero. Estado: Lista las ordenes según su estado, capturadas, ingresadas, etc. Usuario: Lista las ordenes de un mismo usuario ingresando el numero de su documento. Estado del Medio de Pago: Este criterio generara un listado filtrando por el estado de la segunda validacion de la tarjeta. Filtros convinados: Tiene la posibilidad de establecer varios filtros, para una misma busqueda. Una vez establecido el criterio de busqueda se listaran las ordenes, se visualizara el listados de las ordenes solicitadas, obteniendo la siguiente informacion:. Autorizacion: Fecha dia/mes/año de la transaccion. Orden: Es el codigo que le asigno el comercio a la orden “ordercode”. Importe: Muestra el valor cobrado al cliente. Med. De pago: Marca de la tarjeta que utilizo el cliente.

Page 18: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

Sitio: Nombre del sitio donde se realizo el pago. Comercio: Nombre del comercio donde se realizo el pago. Est. Orden: Con 5 iconos identificatorios muestra el estado que tiene una orden. (Ver estados de la orden). Doc.: Tipo y Numero de documento del cliente. Nombre Apellido: Solicitado por SeP en el momento del pago. Domicilio: Declarado en SeP, como domicilio de recepcion de resumen de tarjeta. Estado Tarjeta: Resultado de la segunda validacion (off-line) de la tarjeta, tiene 4 estados posibles:

Validada: Se corroboraron los datos en forma sactifactoria. Erronea: No se corroboraron los datos en forma sactifactoria. Extranjera: Tarjeta emitida en el exterior, no se realiza validacion alfabetica. Pendiente: Esta en proceso de segunda validacion. Nota: En la segunda validacion se corroboran los datos alfabeticos del cliente, direccion de recepcion del resumen, Nombre y Apellido, este dato no determina la compra sino que es un dato para que el comercio tome la eleccion de seguir adelante con la venta o anular la transaccion. Seleccionar: Elige transacciones para exportarlas. Capturar: Selecciona los pagos que acepta y comienza el proceso de pago. Iconos:

Estados de la orden Las ordenes tienen distintos estados:

Ingresada : Es el estado que recibe una transaccion en cuanto es recibido los datos desde el comercio. Autorizada: Luego de “viajar” los datos a la marca de tarjetas y ser verificada, si es exitosa dicha verificacion recibe este estado, la orden podra tener el estado capturada hasta quince dias, luego el estado sera expirada y no se podra realizar la captura.

Da un resumen de la orden.

Historial de estados por los que paso una orden.

Aviso de las notificaciones asincronicas enviadas.

Da un resumen de la orden

Page 19: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

Capturada: Es el estado que recibe una orden luego que recibio el OK desde el comercio a ese OK lo denominamos CAPTURA, una captura genera que comience el proceso de pago, solo se pueden capturar ordenes autorizadas. Nota: Existe la posibilidad de realizar capturas automaticas ( ver parametria del sitio) Anulada: Este estado es el que recibe una orden cuando el comercio realiza la devolucion del dinero a un usuario. Expirada: Es el estado que recibe una orden cuando se excedio el tiempo (15 Dias) de captura o cuando es rechazada por la marca de tarjetas. Exportar un listado de ordenes Para exportar un listado, debera seleccionar las ordenes a exportar tildando el checkbox para tal fin. Luego oprimir el boton exportar, podra elegir el formato ASCII o Excel, se dara la opcion de guardar el archivo que desee. La informacion sera iquivalente a la que esta visualizando en el administrador, salvo los iconos, estos pasaran a tener una leyenda alfabetica y se podra visualizar en este caso tambien el numero de LOTE que integra una orden.

Captura y cierre de Lotes: Ya se describio brevemente este proceso, en parrafo anterior, vale aclarar igualmente porque una orden debe ser capturada y que es un cierre de lote. Cuando un usuario realiza un pago, se genera una reserva del limite de compra o credito de esa tarjeta a favor de una empresa/comercio, la tarea continua cuando el comercio acepta ese dinero comprometiendose a entregar el producto o brindar el servicio. El tiempo para aceptar una transaccion es de 15 dias corridos como se menciono anteriormente. A esta aceptacion por parte del comercio es lo que tecnicamente llamammos captura. Esta la posibilidad que esta captura se realice automaticamente y la posibilidad de retardar el tiempo de la captura automatica. (ver parametria del sitio). Todas las ordenes capturadas en un mismo dia integran un lote, la marca de tarjetas tomara un lote como venta diaria y pagara el total de ese monto previs deducciones. Como veo que ordenes integran un lote? Ingresando desde el MENU PRINCIPAL en el boton Comercios, deben ingresar en el icono identificado como una hoja como se ve en la imagen a continuacion. Luego deberan colocar la/las fechas de los lotes que desean visualizar y la marca de tarjeta y oprimir buscar.

Page 20: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

Encontrara el listado de las ordenes que componen cada lote.

Page 21: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

Implementacion tecnica (Formulario con campos Hidden) Se adjuntan los ejemplos que debera integrar a la programacion del carrito (plataforma de e-commerce) Ejemplo 1: Este formularios es el que contiene la minima cantidad de datos para poder transaccionar. <html> <head> <script language="javascript"> function Submit() {document.form1.submit();} </script> </head> <body onload="Submit();"> <form action="https://www.epayments.hsbc.com.ar/Public/Ssl/Routing.aspx" method="post" id="form1" name="form1"> <input type=hidden id="Hidden2" name="OrderCode" value=" COD0001"> <input type=hidden id="Hidden3" name="ShopCode" value="susitio"> <input type=hidden id="Hidden4" name="OrderAmount" value="40.35"> <input type=hidden id="Hidden5" name="Currency" value="ARS"> <input type=hidden id="Hidden6" name="AutomaticCapture" value="1"> <input type=hidden id="Hidden8" name="UserDocId" value="DNI"> <input type=hidden id="Hidden8" name="UserDocNumber" value="12345678"> <input type=hidden id="Hidden8" name="UserEmail" value="[email protected]"> <input type=hidden id="Hidden8" name="UserFirstName" value="Marcelo"> <input type=hidden id="Hidden8" name="UserLastName" value="Balbuena"> </form> </body> </html> Descripcion de los campos a completar: "OrderCode" Codigo de orden, debera ser un valor alfanumerico de hasta 16 caracteres y nunca se debe repetir. "ShopCode" Nombre que eligio cuando creo el SITIO. "OrderAmount" Precio Total de la orden, decimales separados por punto. "Currency" Tipo de moneda para Pesos valor “ARS” , tener en cuenta que en Argentina desde el año 2001 por ley solo se puede utilizar la moneda Pesos. "AutomaticCapture" “0” para captura manual “1” para automatica "UserDocId" Tipo de documento (ver cuadro de valores en Pag.38) "UserDocNumber" Valor Numero de documento "UserEmail" E-mail del cliente "UserFirstName" Valor Nombre "UserLastName" Valor Apellido

Page 22: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

Ejemplo 2: Este formularios es Full, se debera utilizar en el caso de realizar un pago en cuotas. <html> <head> <script language="javascript"> function Submit() {document.form1.submit();} </script> </head> <body onload="Submit();"> <form action="https://www.epayments.hsbc.com.ar/Public/Ssl/Routing.aspx" method="post" id="form1" name="form1"> <input type=hidden id="Hidden1" name="OrderCode" value="COD0001"> <input type=hidden id="Hidden2" name="ShopCode" value="susitio"> <input type=hidden id="Hidden3" name="OrderAmount" value="10.5"> <input type=hidden id="Hidden4" name="Currency" value="ARS"> <input type=hidden id="Hidden5" name="AutomaticCapture" value="1"> <input type=hidden id="Hidden6" name="ExpirationHours" value="1"> <input type=hidden id="Hidden7" name="PlanQuotas" value="2"> <input type=hidden id="Hidden8" name="PlanPaymentType" value="VISA"> <input type=hidden id="Hidden9" name="UserDocId" value="DNI"> <input type=hidden id="Hidden10" name="UserDocNumber" value="12345678"> <input type=hidden id="Hidden11" name="UserEmail" value="[email protected]"> <input type=hidden id="Hidden12" name="UserFirstName" value="Marcelo"> <input type=hidden id="Hidden13" name="UserLastName" value="Balbuena"> <input type=hidden id="Hidden14" name="UserPhonecountry" value="054"> <input type=hidden id="Hidden15" name="UserPhoneArea" value="011"> <input type=hidden id="Hidden16" name="UserPhoneLocalNumber" value="4309-1111"> <input type=hidden id="Hidden17" name="UserPhoneExtension" value="1111"> <input type=hidden id="Hidden18" name="AddressStreet" value="Calle"> <input type=hidden id="Hidden19" name="AddressNumber" value="Nro23"> <input type=hidden id="Hidden20" name="AddressFloor" value="Piso 1"> <input type=hidden id="Hidden21" name="AddressCity" value="Cap.Fed."> <input type=hidden id="Hidden22" name="AddressPostalCode" value="1234"> <input type=hidden id="Hidden23" name="AddressCountryId" value="AR"> </form> </body> </html>

Page 23: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

Descripcion de cada campo adicional al ejemplo 1. "PlanQuotas" Cantidad de cuotas valores: 2,6,9,12,18,24. "PlanPaymentType" Marca de la tarjeta (ver cuadro de valores en Pag.38) Lineas opcionales: "ExpirationHours" Valor numerico en horas que transcurriran hasta que una transaccion quede caduca. "UserPhonecountry" Valor numerico, codigo de pais. "UserPhoneArea" Valor numerico, codigo de ciudad. "UserPhoneLocalNumber" Valor numerico, telefono local "UserPhoneExtension" Valor numerico, interno o extencion "AddressStreet" nombre de la calle "AddressNumber" Numero de puerta "AddressFloor" Piso "AddressCity" Ciudad "AddressPostalCode" Codigo Postal "AddressCountryId" Codigo de nombre de pais. (ver cuadro de valores en Pag.33)

Page 24: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

Implementacion tecnica (Programacion XML) Circuito de Pagos Simplificados Transacción de pago El circuito simplificado de pagos no requiere la autenticación del usuario comprador en Secure ePayments, esto implica que todo el proceso de pago realizado dentro de Secure ePayments consiste en 1 sólo formulario o pantalla completar por el usuario. El funcionamiento de este circuito de pago es similar al circuito normal de pagos, es decir, el usuario luego de haber llenado los datos propios del carrito de compra en el sitio del comercio elije pagar con Secure ePayments y es redirijido directamente al formulario de pago, en el cual visualizará algunos datos pre-cargados en el caso que el sitio del comecio envíe el nodo User y/o el nodo Addresses a Secure ePayments (de no venir estos nodos en el XML quedarán en blanco en el formulario y los deberá llenar el usuario). Seguidamente el usuario confirmará el pago y será cursada la transacción de compra hacia las marcas. Cabe señalar que un comercio no puede utilizar los dos circuitos de pago (el normal y el simplificado) simultáneamente, sino que previamente a la puesta en producción el comercio tiene que haber informado a Secure ePayments cual de los dos circuitos de pagos utilizará, y para el caso puntual del circuito de pagos simplificado, las ordenes de compra enviadas por el comercio a Secure ePayments deben venir marcadas como “no entregables” (Ver XPU_PayOrder.biz del Anexo 1) Formulario de pago Sobre ésta pantalla el usuario deberá seleccionar el medio de pago a utilizar, cargar los datos necesarios (Ej. Número de tarjeta y código de seguridad), y confirmar la compra; evento que disparará la transacción de pago contra los medios. El resultado de la transacción será informado en un documento XML a devolver por PU cuyos datos se especifican en la siguiente lista cuyo esquema es XPU_RPayOrderResponse.biz (ver anexo 1): datos de la orden de compra ID otorgado por el comercio ID otorgado por PU Medio de pago utilizado datos de los articulos ID otorgado por el comerciante ID otorgado por PU DATOS DE MENSAJES DE LA TRANSACCION Código del mensaje Descripción del mensaje Ensobrado de las transacciones Todo intercambio de mensajes entre Secure ePayments y el comercio adherido, se realizará a traves de lo que se denomina “sobre”. El “Sobre” en si, será otro documento XML con un formato estandar, que incluirá un cabezal para especificar la transacción a procesar y un cuerpo en el cual incluirá a el documento XML perteneciente a dicha transacción. Basicamente se podría decir, que el mismo cumple con una funcionalidad similar a la de un sobre de correo.

Page 25: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

El uso del sobre es obligatorio, y se rechazarán todas las transacciones que no vengan acompañadas del mismo. En el anexo 7, se especifica el formato de dicho documento. Anexo 1: esquemas XML Requerimientos de los campos en los documentos XML R: Valor requerido O: Valor opcional. Nota: Si en el esquema el campo figura como obligatorio, el mismo debe existir pero con un valor nulo o vacío. C: Valor condicional – Requerido o no de acuerdo al valor de otros campos. XPU_PayOrder.biz <XPU_PayOrder> <Order> <Id>89900594</Id> <CurrencyId>ARS</CurrencyId> <SubTotal>500</SubTotal> <Shipping>0</Shipping> <Discount>0</Discount> <Taxes>0</Taxes> <Total>500</Total> <Deliverable>1</Deliverable> <OneShipment>1</OneShipment> <DeliveryDate/> <ShipToMultAddresses>1</ShipToMultAddresses> <AddressId/> <ReceiverId/> <AvailableDays/> <ExpirationHours>1</ExpirationHours> <AllowAutomaticCapture>1</AllowAutomaticCapture> <Items> <Item Id="PS" Descrip="Discman Sonyo" Units="1" Price="200" UnitPrice="200" DeliveryDate="2001-09-09" AddressId="1" ReceiverId="1" AvailableDays="4444444"/> <Item Id="CBT" Descrip="PleyStation" Units="1" Price="300" UnitPrice="300" DeliveryDate="2001-09-09" AddressId="1" ReceiverId="1" AvailableDays="4444444"/> </Items> <Plans> <Plan PaymentId="VISA" CurrencyId="ARS" BankCode="001" QuotasFrom="6" QuotasTo="6" FinancialRate="4" QuotaValue="" IsDefault="1" PreferentialOrder="1"/> </Plans> </Order> <Addresses> <Address> <AddressId>1</AddressId> <Street>Alberdi</Street> <No>141</No> <Level/> <Division/> <CountryId>AR</CountryId> <StateId>AR_CF</StateId> <StateDescrip/> <City>BsAs</City> <PhoneNo>4444-5555</PhoneNo> <PostalCode>1426</PostalCode>

Page 26: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

<Comment>Nada</Comment> <AddressNick>Mi Casa</AddressNick> </Address> </Addresses> <Receivers> <Receiver> <Id>1</Id> <DocId>DNI</DocId> <DocNo>21477998</DocNo> <FirstName>Ernesto</FirstName> <LastName>García</LastName> <ReferenceTitle>Sr</ReferenceTitle> </Receiver> </Receivers> <User> <FirstName>Aroldo</FirstName> <LastName>Pisanno</LastName> <DocId>PS</DocId> <DocNo>2123514</DocNo> <IvaId/> <Email>[email protected]</Email> <CourtTitleId/> <OccupationId/> <PhoneNo>4555-12345</PhoneNo> <MobileNo>555-6666</MobileNo> <FaxNo/> <BirthDay>1955-11-12</BirthDay> <CountryId>AR</CountryId> <AddToEmailList>0</AddToEmailList> </User> </XPU_PayOrder> Ejemplo para el Circuito de Pagos Simplificado <XPU_PayOrder> <Order> <Id>414349874</Id> <CurrencyId>ARS</CurrencyId> <SubTotal>30</SubTotal> <Shipping>0</Shipping> <Discount>0</Discount> <Taxes>0</Taxes> <Total>30</Total> <Deliverable>0</Deliverable> <OneShipment>1</OneShipment> <DeliveryDate>2003-03-04</DeliveryDate> <ShipToMultAddresses>0</ShipToMultAddresses> <AddressId/> <ReceiverId/> <AvailableDays/> <Items> <Item Id="1" Descrip="Mesa" Units="1" UnitPrice="20" Price="20" AddressId="" ReceiverId="" AvailableDays=""/> <Item Id="2" Descrip="Silla" Units="1" UnitPrice="10" Price="10" AddressId="" ReceiverId="" AvailableDays=""/> </Items> </Order> <Addresses/>

Page 27: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

<Receivers/> <User> <FirstName/> <LastName/> <DocId>PS</DocId> <DocNo>2123514</DocNo> <Email>[email protected]</Email> <CourtTitleId/> <OccupationId/> <PhoneNo>4555-12345</PhoneNo> <MobileNo/> <FaxNo/> <BirthDay/> <CountryId/> <AddToEmailList/> </User> </XPU_PayOrder> Nodo/Elemento-Atributo Descripción Largo Order/Id Código único de identificación de la orden de

compra (asignado por el comercio). 20 R

Order/CurrencyId Código identificatorio del tipo de moneda. (Ver anexo 2).

R

Order/Modify Valor booleano que indica si la orden de compra es una modificación de una anterior.

O

Order/SubTotal Subtotal de la orden de compra (Artículos, sin gastos de envío, impuestos y descuentos).

R

Order/Shipping Importe correspondiente a los gastos de envío.

R

Order/Discount Importe correspondiente a los descuentos. ROrder/Taxes Importe correspondiente a los impuestos. ROrder/Total Total de la orden de compra (Artículos +

gastos de envío + Impuestos - descuentos). R

Order/Deliverable Valor lógico que indica si la orden es entregable o no. Su valor debe ser 0 si el comercio opera con el Circuito Simplificado de Pagos

R

Order/OneShipment Valor lógico que indica si todos los artículos de la orden se enviarán juntos o no.

R

Order/DeliveryDate Fecha estimada de entrega. Su valor debe ser nulo si la entrega a multiple domicilios (ShipToMultAddresses = 1) o la orden no es entregable (Deliverable = 0) . Nota: La fecha de cumplir con la norma ISO 8601. Ej: Fecha válida: 2002-01-01 Fecha inválida: 2002-1-1

O

Order/ShipToMultAddresses

Valor lógico que indica si los artículos serán destinados a varios domicilios o no. Si la orden no es entregable (Deliverable = 0) su valor debe ser 0.

R

Order/AddressId Código identificatorio de domicilio. Su valor debe ser nulo si la orden se entrega en múltiples domicilios (ShipToMultAddress =

C

Page 28: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

1) o la orden no es entregable (Deliverable = 0). Si la orden no se entrega a un unico domicilio (ShipToMultAddresses = 0) , su valor se debe corresponder al domicilio definido en Addresses).

Order/ReceiverId Código identificatorio de receptor. Su valor debe ser nulo si la orden se entrega en múltiples domicilios (ShipToMultAddresses = 1) o la orden nos es entregable (Deliverable = 0). Si la orden se entrega a un único domicilio (ShipToMultAddresses = 0) su valor se debe corresponder al receptor definido en Receivers.

C

Order/AvalableDays Máscara utilizada para identificar los días y horarios disponibles para la entrega por parte del receptor (nulo si la entrega es a múltiples domicilios o la orden no es entregable – ver anexo 3).

C

Order/ExpirationHours Cantidad de horas que la orden permanecerá activa en PU, hasta que el usuario realice el pago de la misma. En caso de que dicho período se cumpla, la orden será cancelada automáticamente. (Nulo si la orden no expira nunca)

C

Order/AllowAutomaticCapture

Valor booleano que indica si Secure ePauments está autorizado a realizar la captura automática de la orden.

O

Order/Items/Item/Id Código único de identificación del artículo (asignado por el comercio).

20 R

Order/Items/Item/Descrip Descripción del artículo. 255 ROrder/Items/Item/Units Cantidad de unidades. ROrder/Items/Item/Price Precio Total (Precio Unitario x Cantidad de

Unidades). R

Order/Items/Item/UnitPrice Precio Unitario. ROrder/Items/Item/DeliveryDate

Fecha estimada de entrega. Se puede omitir su inclusión en el documento si la entrega es a múltiples domicilios (ShipToMultAddresses = 1) o la orden no es entregable (Deliverable = 0) . Nota: La fecha de cumplir con la norma ISO 8601. Ej: Fecha válida: 2002-01-01 Fecha inválida: 2002-1-1

C

Order/Items/Item/AddressId Código identificatorio de domicilio. Su valor debe ser nulo si la orden se entrega a un unico domicilio (ShipToMultAddress = 0) o la orden no es entregable (Deliverable = 0). Si la orden se entrega a multiples domicilios (ShipToMultAddresses = 1) , su valor se debe corresponder al domicilio definido en Addresses).

C

Order/Items/Item/ReceiverId Código identificatorio de receptor. Su valor debe ser nulo si la orden se entrega a un único domicilio (ShipToMultAddresses =

C

Page 29: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

0) o la orden nos es entregable (Deliverable = 0). Si la orden se entrega a multiples domicilios (ShipToMultAddresses = 1) su valor se debe corresponder al receptor definido en Receivers.

Order/Items/Item/AvalaibleDays

Mascara utilizada para identificar los días y horarios disponibles para la entrega por parte del receptor (nulo si la entrega es a un único domicilio o la orden no es entregable – ver anexo 3).

C

Order/Plans/Plan/PaymentId

Código identificatorio de tipo de tarjeta (Nulo, si abarca todos los tipos). (Ver anexo 2).

O

Order/Plans/Plan/CurrencyId

Código identificatorio de moneda (Nulo, si abarca todas los tarjetas). (Ver anexo 2).

O

Order/Plans/Plan/BankCode Código identificatorio de banco (Nulo, si abarca todos los bancos). (Ver anexo 2).

O

Order/Plans/Plan/QuotasFrom

Cuotas desde la que abarca el plan. R

Order/Plans/Plan/QuotasTo Cuotas hasta la que abarca el plan. ROrder/Plans/Plan/FinancialRate

Tasa de financiación del plan. Este valor debe indicarse en caso que QuotasFrom sea diferente a QuotasTo. En el caso que las cuotas sean iguales, este valor podrá indicarse como omitirse. Nota: El comercio deberá optar por enviar este valor o lo que se indique en QuotaValue. (Ver Anexo 6 Código de Error 15281).

C

Order/Plans/Plan/QuotaValue

Valor de la cuota del plan. Este valor solamente podrá venir en caso que QuotasFrom sea igual a QuotasTo. Nota: El comercio deberá optar por enviar este valor o lo que se indique en FinancialRate. (Ver Anexo 6 Código de Error 15281).

C

Order/Plans/Plan/IsDefault Flag que indica si el plan es el que aparecerá seleccionado por default.

R

Order/Plans/Plan/PreferentialOrder

Valor que indica el orden en que se mostrarán las opciones.

R

User/FirstName Nombre del usuario. 50 RUser/LastName Apellido del usuario. 50 RUser/DocId Código de identificatorio del tipo de

documento. (Ver anexo 2). R

User/DocNo Número de documento. 20 RUser/IvaId Código identificatorio del tipo de impuesto a

los valores agregados (Ver anexo 2). O

User/Email Dirección de correo electrónico del usuario. 50 RUser/CourtTitleId Código identificatorio del tipo de cortesía

utilizado por el usuario. (Ver anexo 2). O

User/OccupationId Código identificatorio del tipo de empleo. (Ver anexo 2) .

O

User/PhoneNo Número de teléfono particular. 30 OUser/MobileNo Número de teléfono móvil. 20 OUser/FaxNo Número de fax. 20 OUser/BirthDay Fecha de nacimiento. R

Page 30: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

Nota: La fecha de cumplir con la norma ISO 8601. Ej: Fecha válida: 2002-01-01 Fecha inválida: 2002-1-1

User/CountryId Código identificatorio de país - Nacionalidad del usuario. (Ver anexo 2).

R

User/AddToEmailList Valor lógico que identifica si el usuario desea recibir correo con información relacionada a nuevos beneficios brindados por PU (eventuales ofertas, nuevos comercios adheridos al sistema, etc.).

R

Addresses/Address/AddressId

Código único de identificación del domicilio (asignado por el comercio).

R

Addresses/Address/Street Nombre de la calle. 50 RAddresses/Address/No Número de la calle. 10 RAddresses/Address/Level Número de piso. 10 OAddresses/Address/Division Número de departamento. 10 OAddresses/Address/CountryId

Código identificatorio de país. (Ver anexo 2). R

Addresses/Address/StateId Código identificatorio de provincia. (Nulo, si la provincia no figura en la tabla de provincias). (Ver anexo 2).

O

Addresses/Address/StateDescrip

Nombre de la provincia (En caso de que la misma no figure en la tabla de provincias).

30 O

Addresses/Address/City Nombre de la ciudad. 50 RAddresses/Address/PhoneNo

Número de teléfono perteneciente al domicilio.

30 O

Addresses/Address/PostalCode

Código postal. 10 R

Addresses/Address/Comment

Comentarios o algún dato de interés adicional.

50 O

Addresses/Address/AddressNick

Alias del domicilio, el mismo será visualizado en la selección de domicilios en el momento de realizar una compra.

50 R

Receivers/Receiver/Id Código único de identificación del receptor (asignado por el comercio).

R

Receivers/Receiver/DocId Código identificatorio del tipo de documento (Ver anexo 2).

R

Receivers/Receiver/DocNo Número de documento. 20 RReceivers/Receiver/FirstName

Nombre del receptor. 50 R

Receivers/Receiver/LastName

Apellido del receptor. 50 R

Receivers/Receiver/ReferenceTitle

Descripción del título de cortesía. 50 O

Nodo/Elemento-Atributo Descripción Order/Id Código único de identificación de la orden de compra

(asignado por el comercio). Order/PuId Código único de identificacion de la orden de compra

(asignado por PU).

Page 31: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

Order/PaymentId Código identificatorio de medio de pago. (Ver anexo 2). Order/Quotas Cantidad de cuotas en que se realizó el pago. Order/ReceiverId Código identificatorio de receptor (nulo en caso de que la

orden se entregue en múltiples domicilios o la orden no sea entregable. Si la misma se entregará a un único domicilio, su valor se debe corresponder al receptor definido en Receivers).

Order/AvalaibleDays Mascara utilizada para identificar los días y horarios disponibles para la entrega por parte del receptor (nulo si la entrega es a múltiples domicilios o la orden no es entregable – ver anexo 3).

Order/Items/Item/Id Código único de identificación del artículo (asignado por el comercio).

Order/Items/Item/PUId Código único de identificación del artículo (asignado por PU).

Order/Items/Item/ReceiverId

Código identificatorio de receptor (nulo en caso de que la orden se entregue a un único domicilio o la orden no sea entregable. Si la misma fuera entregable a multiples domicilios su valor se debe corresponder al receptor definido en Receivers).

Order/Items/Item/AvalaibleDays

Máscara utilizada para identificar los días y horarios disponibles para la entrega por parte del receptor (nulo si la entrega es a un único domicilio o la orden no es entregable– ver anexo 3).

Receivers/Receiver/Id Código único de identificacion del receptor (asignado por el comercio).

Receivers/Receiver/DocId Código identificatorio del tipo de documento (Ver anexo 2).

Receivers/Receiver/FirstName

Nombre del receptor.

Receivers/Receiver/LastName

Apellido del receptor.

Receivers/Receiver/ReferenceTitle

Descripción del título de cortesía.

Messages/Messge/Id Código único de identificación de mensaje (Asignado por PU).

Messages/Messge/Descrip Descripción del mensaje. User/FirstName Nombre del Usuario. User/LastName Apellido del Usuario. User/DocId Tipo de Documento del Usuario. User/DocNo Número de Documento del Usuario. XPU_RegisterUser.biz <?xml-stylesheet href="http://schemas.biztalk.org/BizTalk/g9boxjl2.xsl" type="text/xsl"?> <Schema name="Untitled-schema" xmlns="urn:schemas-microsoft-com:xml-data" xmlns:dt="urn:schemas-microsoft-com:datatypes"> <ElementType name="AddToEmailList" model="closed" content="textOnly" dt:type="boolean"/> <ElementType name="Address" model="open" content="eltOnly" order="seq"> <element type="AddressId" minOccurs="1" maxOccurs="1"/> <element type="Street" minOccurs="1" maxOccurs="1"/> <element type="No" minOccurs="1" maxOccurs="1"/> <element type="Level" minOccurs="1" maxOccurs="1"/> <element type="Division" minOccurs="1" maxOccurs="1"/> <element type="PhoneNo" minOccurs="1" maxOccurs="1"/> <element type="CountryId" minOccurs="1" maxOccurs="1"/>

Page 32: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

<element type="StateId" minOccurs="1" maxOccurs="1"/> <element type="StateDescrip" minOccurs="1" maxOccurs="1"/> <element type="City" minOccurs="1" maxOccurs="1"/> <element type="PostalCode" minOccurs="1" maxOccurs="1"/> <element type="Comment" minOccurs="1" maxOccurs="1"/> <element type="AddressNick" minOccurs="1" maxOccurs="1"/> </ElementType> <ElementType name="AddressId" model="closed" content="textOnly" dt:type="i4"/> <ElementType name="AddressNick" model="closed" content="textOnly" dt:type="string"/> <ElementType name="Addresses" model="closed" content="eltOnly" order="seq"> <element type="Address" minOccurs="0" maxOccurs="1"/> </ElementType> <ElementType name="BirthDay" model="closed" content="textOnly" dt:type="date"/> <ElementType name="City" model="closed" content="textOnly" dt:type="string"/> <ElementType name="Comment" model="closed" content="textOnly" dt:type="string"/> <ElementType name="CountryId" model="closed" content="textOnly" dt:type="string"/> <ElementType name="CourtTitleId" model="closed" content="textOnly" dt:type="string"/> <ElementType name="Division" model="closed" content="textOnly" dt:type="string"/> <ElementType name="DocId" model="closed" content="textOnly" dt:type="string"/> <ElementType name="DocNo" model="closed" content="textOnly" dt:type="string"/> <ElementType name="Email" model="closed" content="textOnly" dt:type="string"/> <ElementType name="FaxNo" model="closed" content="textOnly" dt:type="string"/> <ElementType name="FirstName" model="closed" content="textOnly" dt:type="string"/> <ElementType name="IvaId" model="closed" content="textOnly" dt:type="string"/> <ElementType name="LastName" model="closed" content="textOnly" dt:type="string"/> <ElementType name="Level" model="closed" content="textOnly" dt:type="string"/> <ElementType name="MobileNo" model="closed" content="textOnly" dt:type="string"/> <ElementType name="No" model="closed" content="textOnly" dt:type="string"/> <ElementType name="OccupationId" model="closed" content="textOnly" dt:type="string"/> <ElementType name="PhoneNo" model="closed" content="textOnly" dt:type="string"/> <ElementType name="PmtMethodAddressId" model="closed" content="textOnly" dt:type="i4"/> <ElementType name="PmtMethodId" model="closed" content="textOnly" dt:type="string"/> <ElementType name="PostalCode" model="closed" content="textOnly" dt:type="string"/> <ElementType name="StateDescrip" model="closed" content="textOnly" dt:type="string"/>

Page 33: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

<ElementType name="StateId" model="closed" content="textOnly" dt:type="string"/> <ElementType name="Street" model="closed" content="textOnly" dt:type="string"/> <ElementType name="User" model="open" content="eltOnly" order="seq"> <element type="FirstName" minOccurs="1" maxOccurs="1"/> <element type="LastName" minOccurs="1" maxOccurs="1"/> <element type="DocId" minOccurs="1" maxOccurs="1"/> <element type="DocNo" minOccurs="1" maxOccurs="1"/> <element type="IvaId" minOccurs="1" maxOccurs="1"/> <element type="Email" minOccurs="1" maxOccurs="1"/> <element type="CourtTitleId" minOccurs="1" maxOccurs="1"/> <element type="OccupationId" minOccurs="1" maxOccurs="1"/> <element type="PhoneNo" minOccurs="1" maxOccurs="1"/> <element type="MobileNo" minOccurs="1" maxOccurs="1"/> <element type="FaxNo" minOccurs="1" maxOccurs="1"/> <element type="BirthDay" minOccurs="1" maxOccurs="1"/> <element type="CountryId" minOccurs="1" maxOccurs="1"/> <element type="AddToEmailList" minOccurs="1" maxOccurs="1"/> <element type="PmtMethodId" minOccurs="0" maxOccurs="1"/> <element type="PmtMethodAddressId" minOccurs="0" maxOccurs="1"/> </ElementType> <ElementType name="XPU_RegisterUser" model="closed" content="eltOnly" order="seq"> <AttributeType name="xmlns" dt:type="string"/> <attribute type="xmlns"/> <element type="User" minOccurs="1" maxOccurs="1"/> <element type="Addresses" minOccurs="1" maxOccurs="1"/> </ElementType> </Schema> Ejemplo <XPU_RegisterUser> <User> <FirstName>Marcelo</FirstName> <LastName>Gomez</LastName> <DocId>DNI</DocId> <DocNo>24777428</DocNo> <IvaId>AR_F</IvaId> <Email>[email protected]</Email> <CourtTitleId>ESP_SR</CourtTitleId> <OccupationId>ESP_ANSIS</OccupationId> <PhoneNo>4861-7971</PhoneNo> <MobileNo>15-4555-5353</MobileNo> <FaxNo>4323-4800</FaxNo> <BirthDay>1977-04-17</BirthDay> <CountryId>AR</CountryId> <AddToEmailList>1</AddToEmailList> </User> <Addresses> <Address> <AddressId>11134</AddressId> <Street>Santa Fé</Street> <No>2718</No> <Level>11</Level> <Division>D</Division> <PhoneNo>4861-7971</PhoneNo>

Page 34: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

<CountryId>AR</CountryId> <StateId>AR_CF</StateId> <StateDescrip>Capital Federal</StateDescrip> <City>Buenos Aires</City> <PostalCode>1426</PostalCode> <Comment>Nada</Comment> <AddressNick>Mi casa</AddressNick> </Address> </Addresses> </XPU_RegisterUser> Nodo/Elemento-Atributo Descripción User/FirstName Nombre del usuario. R User/LastName Apellido del usuario. R User/DocID Código de identificatorio del tipo de

documento. (Ver anexo 2). R

User/DocNo Número de documento. R User/IvaId Código identificatorio del tipo de impuesto a

los valores agregados (Ver anexo 2). O

User/Email Dirección de correo electrónico del usuario. R User/CourtTitleId Código identificatorio del tipo de cortesía

utilizado por el usuario. (Ver anexo 2). O

User/OccupationId Código identificatorio del tipo de empleo. (Ver anexo 2) .

O

User/PhoneNo Número de teléfono particular. O User/MobileNo Número de teléfono móvil. O User/FaxNo Número de fax. O User/BirthDay Fecha de nacimiento.

Nota: La fecha de cumplir con la norma ISO 8601. Ej: Fecha válida: 2002-01-01 Fecha inválida: 2002-1-1

R

User/CountryId Código identificatorio de país - Nacionalidad del usuario. (Ver anexo 2).

R

User/AddToEmailList Valor lógico que identifica si el usuario desea recibir correo con información relacionada a nuevos beneficios brindados por PU (eventuales ofertas, nuevos comercios adheridos al sistema, etc.).

R

Addresses/Address/AddressId

Código único de identificacion del domicilio (asignado por el comercio).

R

Addresses/Address/Street Nombre de la calle. R Addresses/Address/No Número de la calle. R Addresses/Address/Level Número de piso. O Addresses/Address/Division

Número de departamento. O

Addresses/Address/CountryId

Código identificatorio de país. (Ver anexo 2). O

Addresses/Address/StateId Código identificatorio de provincia. (Nulo, si la provincia no figura en la tabla de provincias). (Ver anexo 2).

O

Addresses/Address/StateDescrip

Nombre de la provincia (En caso de que la misma no figure en la tabla de provincias).

O

Addresses/Address/City Nombre de la ciudad. R

Page 35: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

Addresses/Address/PhoneNo

Número de teléfono perteneciente al domicilio. R

Addresses/Address/PostalCode

Código postal. R

Addresses/Address/Comment

Comentarios o algún dato de interés adicional. O

Addresses/Address/AddressNick

Alias del domicilio, el mismo será visualizado en la selección de domicilios en el momento de realizar una compra.

R

XPU_RRegisterUserResponse.biz <?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet href="http://schemas.biztalk.org/BizTalk/g9boxjl2.xsl" type="text/xsl"?> <Schema name="Untitled-schema" xmlns="urn:schemas-microsoft-com:xml-data" xmlns:dt="urn:schemas-microsoft-com:datatypes"> <ElementType name="AuthInfo" model="closed" content="eltOnly" order="seq"> <element type="UserId" minOccurs="1" maxOccurs="1"/> </ElementType> <ElementType name="UserId" model="closed" content="textOnly" dt:type="string"/> <ElementType name="XPU_RRegisterUserResponse" model="closed" content="eltOnly" order="seq"> <AttributeType name="xmlns" dt:type="string"/> <attribute type="xmlns"/> <element type="AuthInfo" minOccurs="1" maxOccurs="1"/> </ElementType> </Schema> Ejemplo <XPU_RRegisterUserResponse> <AuthInfo> <UserId>mgomez</UserId> </AuthInfo> </XPU_RRegisterUserResponse> Monedas – Currencies Código Descripción ARS Pesos Países – Countrys Código Descripción AD Andorra AE United Arab Emirates AF Afganistán AG Antigua And Barbuda AI Anguilla AL Albania AM Armenia AN Netherlands Antilles AO Angola AQ Antarctica AR República Argentina AS American Samoa AT Austria

Page 36: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

AU Australia AW Aruba AZ Azerbaijan BA Bosnia And Herzegovina BB Barbados BD Bangladesh BE Belgium BF Burkina Faso BG Bulgaria BH Bahrain BI Burundi BJ Benin BM Bermuda BN Brunei Darussalam BO Bolivia BR Brasil BS Bahamas BT Bhutan BV Bouvet Island BW Botswana BY Belarus BZ Belize CA Canada CC Cocos (Keeling) Islands CD The Democratic Republic Of The Congo CF Central African Republic CG Congo CH Switzerland CI Côte D'ivoire CK Cook Islands CL Chile CM Cameroon CN China CO Colombia CR Costa Rica CU Cuba CV Cape Verde CX Christmas Island CY Cyprus CZ Czech Republic DE Germany DJ Djibouti DK Denmark DM Dominica DO Dominican Republic DZ Algeria EC Ecuador EE Estonia EG Egypt EH Western Sahara ER Eritrea ES Spain ET Ethiopia FI Finland

Page 37: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

FJ Fiji FK Falkland Islands (Malvinas) FM Federated States Of Micronesia FO Faroe Islands FR France GA Gabon GB United Kingdom GD Grenada GE Georgia GF French Guiana GH Ghana GI Gibraltar GL Greenland GM Gambia GN Guinea GP Guadeloupe GQ Equatorial Guinea GR Greece GS South Georgia And The South Sandwich Islands GT Guatemala GU Guam GW Guinea-Bissau GY Guyana HK Hong Kong HM Heard Island And Mcdonald Islands HN Honduras HR Croatia HT Haiti HU Hungary ID Indonesia IE Ireland IL Israel IN India IO British Indian Ocean Territory IQ Iraq IR Islamic Republic Of Iran IS Iceland IT Italy JM Jamaica JO Jordan JP Japan KE Kenya KG Kyrgyzstan KH Cambodia KI Kiribati KM Comoros KN Saint Kitts And Nevis KP Democratic People's Republic Of Korea KR Republic Of Korea KW Kuwait KY Cayman Islands KZ Kazakstan LA Lao People's Democratic Republic LB Lebanon

Page 38: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

LC Saint Lucia LI Liechtenstein LK Sri Lanka LR Liberia LS Lesotho LT Lithuania LU Luxembourg LV Latvia LY Libyan Arab Jamahiriya MA Morocco MC Monaco MD Republic Of Moldova MG Madagascar MH Marshall Islands MK The Former Yugoslav Republic Of Macedonia ML Mali MM Myanmar MN Mongolia MO Macau MP Northern Mariana Islands MQ Martinique MR Mauritania MS Montserrat MT Malta MU Mauritius MV Maldives MW Malawi MX Mexico MY Malaysia MZ Mozambique NA Namibia NC New Caledonia NE Niger NF Norfolk Island NG Nigeria NI Nicaragua NL Netherlands NO Norway NP Nepal NR Nauru NU Niue NZ New Zealand OM Oman PA Panama PE Peru PF French Polynesia PG Papua New Guinea PH Philippines PK Pakistan PL Poland PM Saint Pierre And Miquelon PN Pitcairn PR Puerto Rico PS Occupied Palestinian Territory

Page 39: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

PT Portugal PW Palau PY Paraguay QA Qatar RE Réunion RO Romania RU Russian Federation RW Rwanda SA Saudi Arabia SB Solomon Islands SC Seychelles SD Sudan SE Sweden SG Singapore SH Saint Helena SI Slovenia SJ Svalbard And Jan Mayen SK Slovakia SL Sierra Leone SM San Marino SN Senegal SO Somalia SR Suriname ST Sao Tome And Principe SV El Salvador SY Syrian Arab Republic SZ Swaziland TC Turks And Caicos Islands TD Chad TF French Southern Territories TG Togo TH Thailand TJ Tajikistan TK Tokelau TM Turkmenistan TN Tunisia TO Tonga TP East Timor TR Turkey TT Trinidad And Tobago TV Tuvalu TW Taiwan, Province Of China TZ United Republic Of Tanzania UA Ukraine UG Uganda UM United States Minor Outlying Islands US United States UY Uruguay UZ Uzbekistan VA Holy See (Vatican City State) VC Saint Vincent And The Grenadines VE Venezuela VG Virgin Islands, British VI Virgin Islands, U.S.

Page 40: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

VN Viet Nam VU Vanuatu WF Wallis And Futuna WS Samoa YE Yemen YT Mayotte YU Yugoslavia ZA South Africa ZM Zambia ZW Zimbabwe Tipos de documento – Document Types Código Descripción CIPF CI emitida por PF CIPP CI emitida por PP CUIT CUIT DNI DNI LC LC LE LE PS Pasaporte Tipos de medio de pago – Payment Methods Types Código Descripción AMEX American Express MASTERCARD Mastercard VISA Visa En este caso se envía un error al comercio ya que el Valor Cuota solo puede utilizarse cuando CD = CH.

Page 41: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

Anexo 5: Intercambio de Mensajes XML con PU Comercio - PU En la URL: https://www.epayments.hsbc.com.ar/public/ssl/routing.aspx se encontrará publicada una página la cual recibirá un documento xml y el código de comercio que envió el mismo a través de un post de http. Los campos que deberán acompañar dicho mensaje http son los siguientes: XML : Contendrá todo el documento XML en forma encriptada. Dicho documento representará al sobre para envio de transacciones. AppId: Contendrá el código único de aplicación (El mismo será entregado por PU en el momento que el comercio pueda comenzar a transaccionar). PU – Comercio Una vez que la transacción haya finalizado, ya sea bien o mal, PU responderá teniendo en cuenta lo siguiente: Si la transacción fue exitosa, PU pondrá responder según las siguientes condiciones: Si se solicitó una registración o pago de una orden, responderá mediante un mensaje http por post a la url de respuesta definida por el comercio para dicha transacción. Dichas URL se deberán establecer en el momento que el comercio comience a transaccionar contra PU y quedará cargo del comercio definir cuales serán las mismas. Si se solicitó una autenticación, responderá mediante un mensaje http por post a la url definida en el documento XML originante de dicha transacción. Si la transacción no fue exitosa, PU responderá mediante un mensaje http por post a la url de respuesta definida por el comercio para la transacción de error. Dicha URL se deberán establecer en el momento que el comercio comience a transaccionar contra PU y quedará cargo del comercio definir cual será la misma. En ambos casos, los campos que acompañaran dicho mensaje http serán los siguientes: XML : Contendrá todo el documento XML en forma encriptada. Dicho documento representará al sobre para envio de transacciones. AppId: Contendrá el código único de aplicación. Anexo 6: Códigos de Error Transacción de pago de orden Código Descripción 15176 Error al validar el XML contra el esquema. 15179 Error al dar de alta el/los domicilio(s) de la orden de compra.

La operación ha sido abortada. 15180 Ocurrió un error inesperado al dar de alta el/los domicilio(s) de

la orden de compra. La operación ha sido abortada. 15181 Ocurrió un error inesperado al dar de alta la orden de compra.

La operación ha sido abortada. 15182 No hay concordancia entre las direcciones recibidas. 15183 Error al setear los domicilios con la orden de compra. 15185 Error al setear al receptor de la orden de compra. 15186 Error al intentar pasar de estado la orden . 15187 Error al intentar pasar de estado algún ítem de la orden . 15188 Error inesperado al ejecutar el pago de la orden. 15194 Se ha producido un error al crear el documento para dar de

alta la orden de compra. 15195 Se ha producido un error al crear el documento para dar de

alta los domicilios. 15197 Error general, consultar con el ejecutivo de cuentas.

Page 42: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

15205 No hay concordancia entre los receptores recibidos. 15206 Se ha producido un error al crear el documento para dar de

alta los receptores. 15207 Error al dar de alta el/los receptor(es) de la orden de compra.

La operación ha sido abortada. 15208 Ocurrió un error inesperado al dar de alta el/los receptor(es) de

la orden de compra. La operación ha sido abortada. 15210 Error al setear los receptores con la orden de compra. 15212 Faltan la/s direccion/es de entrega. 15213 El método abreviado requiere que el comercio permita enviar a

múltiples direcciones. 15244 Error al procesar sus datos personales 15232 El comercio no opera bajo las condiciones especificadas 15250 El monto de la orden de compra supera al monto máximo

permitido por Secure ePayments para usuarios que aun no validaron su domicilio.

15251 El monto de la orden de compra supera al monto máximo permitido por Secure ePayments.

15254 El error de eG-Pay no existe. 15255 El tipo de transacción de eG-Pay no existe. 15264 Error al dar de alta los planes de cuotas 15265 Los planes de cuota enviados no son válidos 15266 Los planes de pago son requeridos y no fueron enviados 15267 Los datos enviados en alguno de los planes de pago no son

consistentes 15275 Los rangos de las cuotas en alguno de los planes de pago

están vacios. 15276 Los valores de las cuotas deben ser mayores que cero. 15277 El Financial Rate debe ser mayor a -100 y menor que 1000 15278 El Financial Rate y el Quota Value en alguno de los planes de

pago están vacios. 15279 El valor de las Cuotas Desde debe ser menor que el de las

Cuotas Hasta. 15280 Falta especificar el valor del Financial Rate en alguno de los

planes de pago. 15281 No es posible enviar valores para el Financial Rate y el Quota

Value para un mismo plan de pago. 15282 El Quota Value debe ser mayor a cero. 15332 El nodo Total debe contener un valor numérico mayor o igual a

cero. 15333 El nodo Taxes debe contener un valor numérico mayor o igual

a cero. 15334 El nodo Shipping debe contener un valor numérico mayor o

igual a cero. 15335 El nodo Discount debe contener un valor numérico mayor o

igual a cero. Anexo 7: Sobre - Esquema XML <Schema name="Untitled-schema" xmlns="urn:schemas-microsoft-com:xml-data" xmlns:dt="urn:schemas-microsoft-com:datatypes"> <ElementType name="Body" model="open" content="empty"/> <ElementType name="Header" model="closed" content="eltOnly" order="seq"> <element type="TransactionId" minOccurs="1" maxOccurs="1"/>

Page 43: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

</ElementType> <ElementType name="TransactionId" model="closed" content="textOnly" dt:type="string"/> <ElementType name="XPU_ExternalEnvelope" model="closed" content="eltOnly" order="seq"> <AttributeType name="xmlns" dt:type="string"/> <attribute type="xmlns"/> <element type="Header" minOccurs="1" maxOccurs="1"/> <element type="Body" minOccurs="1" maxOccurs="1"/> </ElementType> </Schema> <XPU_ExternalEnvelope> <Header> <TransactionId>XPU_NombreTransaccion</TransactionId> </Header> <Body/> </XPU_ExternalEnvelope> Nodo/Elemento-Atributo

Descripción

Header/TransactionId Código único de identificación de transacción Body Documento XML con la transacción a enviar Axexo 8: Tipos de datos utilizados por los esquemas XML Tipo Descripción I1 Entero de 1 byte. Ej: 1, 128, -127 I2 Entero de 2 bytes. Ej: 1, 703, -32768 I4 Entero de 4 bytes. Ej: 1, 703, -32768, 148343, -1000000000 Boolean Booleano o Logico. Unicos posibles valores: 0 o 1. String Cadena de caracteres Date Fecha. Formato: aaaa-mm-dd (a: Año, m: Mes, d: Día)

Nota: La fecha de cumplir con la norma ISO 8601. Ej: Fecha válida: 2002-01-01 Fecha inválida: 2002-1-1

Fixed 14.4 Número real de 14 digitos y 4 decimales. El separador decimal es el signo “.” (punto). No acepta separador de miles

Number Valor numerico. Acepta decimales, siendo el separador decimal el signo “.” (punto). No acepta separador de miles

Anexo 9: Web Services – Consulta de Ordenes Es posible consultar información básica de las órdenes asociadas al comercio en forma automática, mediante la invocación del web method ExternalDispatcher. El archivo “PU_DispatcherWS Web Service.htm” provisto con el paquete de integración, describe la especificación y adicionalmente incluye un formulario ejemplo apuntando al ambiente de staging. Requerimientos de los campos en los documentos XML R: Valor requerido O: Valor opcional. Nota: Si en el esquema el campo figura como obligatorio, el mismo debe existir pero con un valor nulo o vacío. C: Valor condicional – Requerido o no, de acuerdo al valor de otros campos. WSPU_GetStoreOrders.biz <Schema name="Untitled-schema">

Page 44: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

<ElementType name="AVCStatus" model="closed" content="textOnly" dt:type="string"/> <ElementType name="AchievedStatus" model="closed" content="eltOnly" order="seq"> <element type="Id" minOccurs="1" maxOccurs="1"/> <element type="From" minOccurs="1" maxOccurs="1"/> <element type="To" minOccurs="1" maxOccurs="1"/> </ElementType> <ElementType name="AscendingOrder" model="closed" content="textOnly" dt:type="boolean"/> <ElementType name="CurrentStatus" model="closed" content="eltOnly" order="seq"> <element type="Status" minOccurs="0" maxOccurs="*"/> </ElementType> <ElementType name="Customer" model="closed" content="eltOnly" order="seq"> <element type="FirstName" minOccurs="1" maxOccurs="1"/> <element type="LastName" minOccurs="1" maxOccurs="1"/> </ElementType> <ElementType name="ExpirationTo" model="closed" content="textOnly" dt:type="string"/> <ElementType name="FirstName" model="closed" content="textOnly" dt:type="string"/> <ElementType name="From" model="closed" content="textOnly" dt:type="string"/> <ElementType name="Id" model="closed" content="textOnly" dt:type="string"/> <ElementType name="LastName" model="closed" content="textOnly" dt:type="string"/> <ElementType name="OrderCode" model="closed" content="textOnly" dt:type="string"/> <ElementType name="OrderTotal" model="closed" content="eltOnly" order="seq"> <element type="From" minOccurs="1" maxOccurs="1"/> <element type="To" minOccurs="1" maxOccurs="1"/> </ElementType> <ElementType name="Origin" model="closed" content="textOnly" dt:type="string"/> <ElementType name="PaymentMethod" model="closed" content="eltOnly" order="seq"> <element type="Type" minOccurs="1" maxOccurs="1"/> <element type="Origin" minOccurs="1" maxOccurs="1"/> </ElementType> <ElementType name="Status" model="closed" content="empty"> <AttributeType name="Id" required="yes"/> <attribute type="Id"/> </ElementType> <ElementType name="To" model="closed" content="textOnly" dt:type="string"/> <ElementType name="Type" model="closed" content="textOnly" dt:type="string"/> <ElementType name="WSPU_GetStoreOrders" model="closed" content="eltOnly" order="seq"> <AttributeType name="xmlns" dt:type="string"/> <attribute type="xmlns"/> <element type="OrderCode" minOccurs="1" maxOccurs="1"/> <element type="CurrentStatus" minOccurs="1" maxOccurs="1"/> <element type="AchievedStatus" minOccurs="1" maxOccurs="1"/> <element type="PaymentMethod" minOccurs="1" maxOccurs="1"/> <element type="ExpirationTo" minOccurs="1" maxOccurs="1"/>

Page 45: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

<element type="AVCStatus" minOccurs="1" maxOccurs="1"/> <element type="Customer" minOccurs="1" maxOccurs="1"/> <element type="OrderTotal" minOccurs="1" maxOccurs="1"/> <element type="AscendingOrder" minOccurs="1" maxOccurs="1"/> </ElementType> </Schema> Ejemplo <WSPU_GetStoreOrders> <OrderCode>PP4556232</OrderCode> <CurrentStatus> <Status Id="C"/> <Status Id="A"/> </CurrentStatus> <AchievedStatus> <Id>"C"</Id> <From>2001-12-10</From> <To>2001-12-10</To> </AchievedStatus> <PaymentMethod> <Type>VISA</Type> <Origin>LOC</Origin> </PaymentMethod> <ExpirationTo>2001-10-10</ExpirationTo> <AVCStatus>V</AVCStatus> <Customer> <FirstName>Pedro</FirstName> <LastName>Gonzales</LastName> </Customer> <OrderTotal> <From>100983.32</From> <To>123432.23</To> </OrderTotal> <AscendingOrder>1</AscendingOrder> </WSPU_GetStoreOrders> Nodo/Elemento-Atributo Descripción Largo OrderCode Código único de identificación de la orden de

compra (asignado por el comercio). 20 O

CurrentStatus Nodo para definir el filtro por estado actual RCurrentStatus/Status Elemento para definir los estados por los

cuales se desea filtrar O

AchiedvedStatus Nodo para definir el filtro por estados alcanzados

AchievedStatus/Id Id del estado por el cual deben haber pasado las ordenes filtradas

CurrentStatus/From Fecha a partir de la cual debe considerarse la ocurrencia del status

O

CurrentStatus/To Fecha hasta la cual debe considerarse la ocurrencia del status

O

PaymentMethod Nodo para definir el filtro por método de pago R

Page 46: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

PaymentMethod/Type Tipo de medio de pago, según tabla. Ej, VISA, AMEX

O

PaymentMethod/Origin Origen del medio de pago según tabla OExpirationTo Fecha hasta la cual debe considerarse la

expiración de la orden Ej.: "Todas las ordenes que hayan expirado antes del 17/4/2002"

O

AVCStatus Estado del Address Validation Code del usuario asociado

O

Customer Nodo para definir el filtro por cliente RCustomer/FirstName Nombre del usuario OCustomer/LastName Apellido del usuario OOrderTotal Nodo para definir el filtro por importe total de

la orden R

OrderTotal/From Importe a partir del cual se debe filtrar OOrderTotal/To Importe hasta el cual se debe filtrar OAscendingOrder Especifica si el resultado se desea en orden

ascendente (1) o descendente (0). R

WSPU_GetStoreOrdersResp.biz <Schema name="Untitled-schema"> <ElementType name="Order" model="closed" content="empty"> <AttributeType name="OrderCode" dt:type="string" required="yes"/> <AttributeType name="Id" dt:type="i4" required="yes"/> <AttributeType name="CurrencyId" dt:type="string" required="yes"/> <AttributeType name="Total" dt:type="fixed.14.4" required="yes"/> <AttributeType name="CurrentStatus" dt:type="string" required="yes"/> <AttributeType name="CurrentStatusTimestamp" dt:type="dateTime.tz" required="yes"/> <AttributeType name="BuyDate" dt:type="dateTime.tz" required="yes"/> <AttributeType name="PaymentMethodType" dt:type="string" required="yes"/> <attribute type="OrderCode"/> <attribute type="Id"/> <attribute type="CurrencyId"/> <attribute type="Total"/> <attribute type="CurrentStatus"/> <attribute type="CurrentStatusTimestamp"/> <attribute type="BuyDate"/> <attribute type="PaymentMethodType"/> </ElementType> <ElementType name="Orders" model="closed" content="eltOnly" order="seq"> <element type="Order" minOccurs="1" maxOccurs="1"/> </ElementType> <ElementType name="WSPU_GetStoreOrdersResp" model="closed" content="eltOnly" order="seq"> <AttributeType name="xmlns" dt:type="string"/> <attribute type="xmlns"/> <element type="Orders" minOccurs="1" maxOccurs="1"/> </ElementType> </Schema> Ejemplo <WSPU_GetStoreOrdersResp> <Orders>

Page 47: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

<Order OrderCode="jj66628783" Id="123456789" CurrencyId="ARS" Total="10037.32" CurrentStatus="P" CurrentStatusTimestamp="2000-12-31T00:00:00" BuyDate="2000-12-31T00:00:00" PaymentMethodType="VISA"/> </Orders> </WSPU_GetStoreOrdersResp> Nodo/Elemento-Atributo Descripción Largo Orders Nodo que agrupa los elementos iterativos

"Order" R

Orders/Order Nodo que agrupa los datos de una order de pago.

R

Orders/Order/OrderCode ID de la orden asignado por el comercio. 20 ROrders/Order/Id ID de la orden asignado por PU ROrders/Order/CurrencyId ID de la moneda según tabla ROrders/Order/Total Importe total de la orden ROrders/Order/Taxes Importe de la orden correspondiente a

impuestos. R

Orders/Order/Shipping Importe de la orden correspondiente a gastos de envío.

R

Orders/Order/Discount Importe de la orden correspondiente a descuentos.

R

Orders/Order/Deliverable Especifica si se trata de un bien enviable. ROrders/Order/OneShipment Especifica si la orden debe ser

despachada en un solo envío R

Orders/Order/DeliveryDate Fecha estimada de envio ROrders/Order/DeliveryAgency Empresa de transportes ROrders/Order/DeliveryTracking Especifica si el comercio realizará el

tracking de la orden. R

Orders/Order/ClientIP IP desde la cual se conecto el cliente ROrders/Order/CurrentStatus Estado actual de la orden ROrders/Order/CurrentStatusTimestamp

Fecha y hora en el cual la orden alcanzó el estado actual

R

Orders/Order/BuyDate Fecha de pago. ROrders/Order/PaymentMethodType

Tipo de medio de pago utilizado por el cliente (Ej. VISA, AMEX, etc.)

R

Orders/Order/UserId ID del usuario en Secure ePayments. R Anexo 10: Notificación Asincrónica de Transacción de Pago Exitosa Este servicio optativo permite asegurar la recepción en el site del comercio, de la confirmación del éxito de una transacción de pago en forma on-line. El uso de este servicio es especialmente recomendado en aquellos sites que cuenten con procesos automáticos críticos, desencadenados a partir de una transacción de pago exitosa, es decir, cuando la consulta manual por medio del site Administrador no sea una opción válida. El servicio enviará mediante http POST el documento XML descripto por el esquema ASPU_PostOrderSuccess.biz. El POST será dirigido a una URL informada específicamente para este fin por el site del comercio (ASPU_PostOrderSuccessURL). Los envíos se repetirán a intervalos fijos hasta que Secure ePayments reciba desde el site del comercio la respuesta ASPU_PostOrderSuccessResp. Los XMLs involucrados deberán estar incluidos en el sobre externo (ver Anexo 7), y en ningún caso estarán encriptados. ASPU_PostOrderSuccess.biz

Page 48: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

<Schema name="Untitled-schema"> <ElementType name="DateTimeStatus" model="closed" content="textOnly" dt:type="dateTime"/> <ElementType name="Id" model="closed" content="textOnly" dt:type="string"/> <ElementType name="Order" model="closed" content="eltOnly" order="seq"> <element type="Id" minOccurs="1" maxOccurs="1"/> <element type="PUId" minOccurs="1" maxOccurs="1"/> <element type="Status" minOccurs="1" maxOccurs="1"/> <element type="DateTimeStatus" minOccurs="1" maxOccurs="1"/> <element type="PaymentMethodType" minOccurs="1" maxOccurs="1"/> <element type="PayString" minOccurs="1" maxOccurs="1"/> <element type="PayName" minOccurs="1" maxOccurs="1"/> </ElementType> <ElementType name="PUId" model="closed" content="textOnly" dt:type="i4"/> <ElementType name="PaymentMethodType" model="closed" content="textOnly" dt:type="string"/> <ElementType name="PayString" model="closed" content="textOnly" dt:type="string"/> <ElementType name="PayName" model="closed" content="textOnly" dt:type="string"/> <ElementType name="Status" model="closed" content="textOnly" dt:type="string"/> <ElementType name="ASPU_PostOrderSuccess" model="closed" content="eltOnly" order="seq"> <AttributeType name="xmlns" dt:type="string"/> <attribute type="xmlns"/> <element type="Order" minOccurs="1" maxOccurs="1"/> </ElementType> </Schema> Ejemplo <ASPU_PostOrderSuccess> <Order> <Id>XX33096</Id> <PUId>5456688</PUId> <Status>Autorizada</Status> <DateTimeStatus>2002-01-01T03:30:23</DateTimeStatus> <PaymentMethodType>VISA</PaymentMethodType> <PayString>5678</PayString> <PayName>Jose Perez</PayName> </Order> </ASPU_PostOrderSuccess> Nodo/Elemento-Atributo Descripción Largo Order/Id ID de la orden asignado por el comercio. 20 ROrder/PUId ID de la orden asignado por Secure

ePayments. 20 R

Order/Status Estado de la orden luego del intento de pago

R

Order/DateTimeStatus Fecha y hora ROrder/PaymentMethodType Descripción del medio de pago ROrder/PayString Ultimos 4 digitos de la tarjeta de credito 4 ROrder/PayName Titular de la tarjeta R

Page 49: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

ASPU_PostOrderSuccessResp.biz <ElementType name="Ack" model="closed" content="textOnly" dt:type="boolean"/> <ElementType name="Order" model="closed" content="eltOnly" order="seq"> <element type="Ack" minOccurs="1" maxOccurs="1"/> </ElementType> <ElementType name="ASPU_PostOrderSuccessResp" model="closed" content="eltOnly" order="seq"> <AttributeType name="xmlns" dt:type="string"/> <attribute type="xmlns"/> <element type="Order" minOccurs="1" maxOccurs="1"/> </ElementType> </Schema> Ejemplo: <ASPU_PostOrderSuccessResp> <Order> <Ack>1</Ack> </Order> </ASPU_PostOrderSuccessResp> Nodo/Elemento-Atributo Descripción Largo Order/Ack Indica que la notificación fue recibida por

el site del comercio, interrumpiendo los intentos periódicos de notificación por parte de Secure ePayments.

1 R

Anexo 11: Captura automática Descripción La captura automática de una orden se produce cuando se produce la autorización de una orden. O sea, no hay una ¨captura o confirmación¨ manual por parte del Comercio, sino que se realiza en forma automática. Para que se realice la captura automática deben cumplirse ciertas condiciones: Debe haber transcurrido el tiempo de captura del comercio. El comercio debe informar en la orden que ésta es capturable automáticamente. Deben cumplirse las condiciones de captura definidas para el comercio. Para que un comercio opere con captura automática el campo ¨allowAutomaticCapture¨ debe informarse con el valor 1 en el XML. Además debe informarnos que desea operar con esta modalidad. Una vez que el usuario comprador paga la orden y el sistema autoriza el pago de la misma, para realizar la captura automática, el sistema realiza los siguientes pasos: Verifica que la orden es capturable automáticamente. Verifica que transcurrió tiempo de captura del comercio. Verifica que se cumplen las condiciones de captura. Captura la orden. Verifica que el comercio debe recibir un mail por la captura automática de cada orden. Envía el mail al comercio informando la captura automática.

Page 50: Secure ePayments Manual de Productoplataforma en la que opere su empresa (por ejemplo: Linux, Wndows, etc.). El proceso de Implementacion entre un sitio y Secure ePayments, varia de

Captura automática por validación telefónica Descripción La captura automática de una orden puede producirse cuando Customer Service valida telefónicamente el domicilio de entrega de resumen de una tarjeta de un usuario comprador. Esta sería una condición adicional para validar en forma automática. Como con la validación telefónica se determina si una tarjeta es nacional o extranjera, y estas condiciones forman parte de las reglas de captura de un comercio, puede suceder que órdenes que no fueron capturadas automáticamente en el momento de su autorización, ahora cumplan con todas las condiciones de captura automática y deban ser capturadas. Para realizarse la captura automática deben cumplirse las siguientes condiciones: Debe haber transcurrido el tiempo de captura del comercio. El comercio debe informar en la orden que ésta es capturable automáticamente. Deben cumplirse las condiciones de captura definidas para el comercio. Condiciones previas Las ordenes son capturadas y el comercio recibe un mail por cada orden informando que fue capturada automáticamente. Para que un comercio opere con captura automática el campo ¨allowAutomaticCapture¨ debe informarse con el valor 1 en el XML. Además debe informarnos que desea operar con esta modalidad. 8. Customer Service. Ante cualquier duda o consulta, debera comunicarse a nuestro Call Center al telefono 0800-999-5050 o con su ejecutivo de cuentas, si prefiere hacerlo por e-mail escribanos a [email protected].