Pasarela de Pagos Online Autopay - DocumentaciónPobierz

Autopay Pagos en línea es una solución integral para aceptar pagos de los clientes de la tienda en línea, el apoyo a numerosos métodos de pago disponibles en el mercado, tales como transferencias bancarias, Pay by link, BLIK, Google Pay, Apple Pay. En esta documentación encontrará todo lo necesario para implementar rápidamente una pasarela de pago en su tienda online. La documentación de Autopay Online Payments incluye secciones como. Procesamiento de transacciones y liquidaciones, Registro y gestión de los puntos de liquidación entre AP y la plataforma del mercado de socios, Registro y explotación de Servicios basados en el Formulario Integrador, Ampliaciones adicionales.

Definiciones

Aplicación - Aplicación móvil Partner, que se comunica con el SDK del sistema de pago en línea Autopay. para registrar las transacciones.

AP - Autopay Spółka Akcyjna con domicilio social en Sopot en ul. Powstańców Warszawy 6, inscrita en el registro de empresarios llevado
por el Tribunal de Distrito Gdańsk-Północ en Gdańsk, VIII División de Negocios del Registro Nacional de Tribunales con el número KRS 0000320590, NIP 585-13-51-185, Regon 191781561, con un capital social de 2.205 PLN 500 (totalmente desembolsado), supervisado por la Comisión de Supervisión Financiera e inscrito en el registro de entidades de pago nacionales con número IP17/2013, propietario del Sistema.

BalancePoint - objeto en el Sistema de Pagos que representa la Tienda integrada con la Plataforma Marketplace y registrada en el Sistema de Pagos utilizando el formulario puesto a disposición del Socio por AP.

ClientHash - en los mensajes; permite asignar el instrumento de pago (por ejemplo, tarjeta) al cliente de forma anónima. Sobre la base de esto, el socio puede desencadenar débitos posteriores en el modelo de pago automático.

CommissionModel - El modelo de comisión acordado con el Integrador. Describe los
valores de las comisiones para las transacciones pasadas al PA y al Integrador.

Día laborable - Entre semana, de lunes a viernes, salvo días festivos.

Formulario integrador - sitio web en el que se coloca un formulario que permite al Cliente registrarse, editar o añadir otro Servicio.

Instrumento de pago (Canal de pago) - un
conjunto acordado de procedimientos o un
dispositivo individualizado, utilizado por el cliente para presentar una
orden de pago, por ejemplo, Tarjeta, PBL.

Herramienta de transferencia electrónica - Un conjunto de procedimientos o un dispositivo personalizado acordado entre el Socio y AP, utilizado por el Socio para colocar una orden de pago que permita la ejecución de una retirada de fondos del saldo a la cuenta bancaria del Socio o Cliente y otro instrumento de pago perteneciente al Socio o Cliente. La prestación de
funcionalidad está sujeta a acuerdos individuales entre el Socio
y AP.

Integrador - Integradores se llaman los socios que han implementado Autopay Pagos en Línea en sus sistemas y permitir su activación de desde dentro de sus propias soluciones. Integradores incluyen tales entidades como Shoper, Sky-Shop, Gymsteer, Selly verificaciones, FaniMani, AtomStore, Ebexo, Selly Azymut, PayNow, Comarch.

IPN (Notificación instantánea del producto) - Una notificación inmediata
enviada desde el Sistema de Pago en Línea al Servicio Asociado
que transmite un cambio en el estado del producto. La estructura de la IPN es similar a la ITN (ampliado sólo por el nodo producto).

ITN (Notificación instantánea de transacciones) - notificación
inmediata enviada desde el Sistema de Pago en Línea al Servicio Asociado
transmitiendo un cambio en el estado de la transacción.

ISTN (Notificación Instantánea de Transacciones de Liquidación) - notificaciones inmediatas de un cambio en el estado de una operación de liquidación. El sistema
transmitirá inmediatamente notificaciones del hecho de que se ha ordenado una
operación de liquidación (retiradas/devoluciones, en su caso) y de un cambio en su estado.

ICN (Notificación instantánea de configuración) - Notificación
inmediata de la configuración de una tienda recién registrada, comunicando
información sobre un cambio en el estado de la tarjeta de la tienda (por ejemplo, en caso de
activación de la tarjeta). Los mensajes ICN también pueden enviarse en caso de un cambio
en la configuración de la tienda, un cambio en sus datos AML, la habilitación/deshabilitación de un canal de pago. La provisión de funcionalidad está sujeta a acuerdos individuales entre el Socio y AP.

Tarjeta - una tarjeta de pago emitida bajo los esquemas VISA y Mastercard, autorizada
por la normativa de dichos esquemas para ejecutar Transacciones sin su presencia
física.

Cliente (pagador) - una persona que realice un pago en el Sitio Web por servicios
data-deepl-translation/> o productos del Socio utilizando el Sistema.

Cesta de productos - es la información sobre los componentes del pago, transmitida (en el enlace de pago) al Sistema para su posterior procesamiento. Cada producto de la cesta de la compra se describe mediante dos campos obligatorios: el importe componente y un campo que permite pasar parámetros específicos para el producto.

Enlace de pago - solicitud que permite el inicio de la transacción de entrada
(descrita en parte Inicio de la transacción). Se puede utilizar directamente en páginas web (método POST), mientras que en los correos electrónicos a clientes se debe utilizar el método Antes de la transacción para obtener un enlace corto al pago (método GET).

Enlace de verificación - URL que dirige a la transferencia de verificación.

Mercado - Una solución de pago que se ejecuta dentro de la Autopay Online Payment System. Permite al socio operar una plataforma de ventas donde los productos o servicios son ofrecidos a los clientes por los contratistas del socio. Los modelos de Liquidación Avanzada de Transacciones y Transacción de Liquidación permiten que los pagos se realicen directamente del Cliente a la Contraparte del Socio, teniendo en cuenta la Cesta de Productos. La provisión de la funcionalidad está sujeta a acuerdos individuales entre el Socio y AP.

Modelo de pagador - modelo en el que la comisión por la transacción realizada la paga el cliente a AP (coste añadido al importe de la transacción). En este caso, el cliente también acepta los términos y condiciones de AP durante el pago.

Modelo de comerciante - modelo, en el que la comisión se liquida entre Autopay y el socio y no se añade al importe de la transacción pagado por el cliente.

Socio - la entidad receptora de fondos procedentes de la venta de
productos o servicios distribuidos por el Afiliado en el Sitio Web.
Un socio, en el caso del modelo Marketplace, es una entidad, que no es un consumidor, interesada en gestionar la aceptación por parte de AP de pagos debidos al socio por productos o servicios distribuidos por el socio.

Pago por enlace (PBL) - herramienta que permite la ejecución de pagos a través de una transferencia intrabancaria desde la cuenta del Cliente a la cuenta del PA. Después de iniciar sesión en la banca en línea - los datos necesarios para ejecución de la transferencia (datos de información del destinatario, el número de su cuenta bancaria, la cantidad y la fecha de ejecución de la transferencia) se rellenan automáticamente gracias al sistema de intercambio de datos entre el banco y AP.

Agente técnico - la entidad con derecho a acceder a la Cuenta de Pago del Socio,
que autoriza este acceso (consentimiento o acuerdo). En el sistema, el apoderamiento está representado por la configuración de la función PlenipotenciarioIDuna entidad puede tener varios proxies para diferentes Socios.

Plataforma de mercado - plataforma en la que está disponible la opción
para registrar Puntos de Liquidación.

Pago automático - pago realizado sin necesidad de
introducir cada vez los datos de la Tarjeta o los datos de autorización de la
transferencia de datos.

Pago con un clic - es un pago automático ordenado
por el cliente.

Pago cíclico - es un pago automático ordenado sin
data-deeplanslation/> participación del Cliente (por el Servicio Asociado).

Antes de la transacción - ordenación específica (realizada en segundo plano) del enlace de pago
.

Transferencia de verificación - La parte del proceso relacionada con el registro y
edición del Servicio o Servicios del Socio en el Sistema. Implica que el
Socio realice una transferencia de fondos para verificar los datos y la cuenta bancaria para el desembolso de fondos al
Socio. Verificación de los datos es una obligación de la PA en virtud, entre otras cosas, la Ley de 16.11.2000 sobre la prevención del blanqueo de capitales y financiación del terrorismo. Cada transferencia de verificación debe recibir estado de verificación final (positivo o negativo) dentro de los 30 días de el pago de la transacción. Si el estado de verificación final no se da en el plazo especificado anteriormente, el sistema le dará automáticamente un estado negativo. Este proceso se aplica a las verificaciones en las que Autopay dirige una solicitud para completar los datos al cliente y no recibe de vuelta la información necesaria para completar la verificación.

Cuenta de pago (saldo) - Una cuenta de pago mantenida por AP para el Socio en la que se recogen los fondos depositados de los Clientes. La prestación de la funcionalidad está sujeta a acuerdos individuales entre el Socio y AP.

RPAN (Notificación de activación de pago periódico) - mensaje sobre
la activación del servicio de pago automático.

RPDN (Notificación de desactivación de pagos periódicos) - mensaje sobre
la desactivación del servicio de pago automático.

Servicio - el sitio web del Socio o los sitios web integrados con el
Sistema en los que el Cliente puede adquirir productos o servicios del Socio (o del Contratista
Socio en el caso del Mercado).
En el caso de un Mercado, un objeto en el Sistema de Pago que representa el
Mercado del Socio. Todas las
transacciones iniciadas por dicho Mercado se adjuntan a él.

Especificación - documentación que describe la comunicación entre el Servicio y el Sistema.

Sistema de pago en línea AP (Sistema) - una
solución informática y funcional por la que AP proporciona al Socio una
aplicación que permite el procesamiento de los pagos de los Clientes realizados mediante
Instrumentos de Pago, así como la verificación del estado de
los pagos y la recepción de los mismos.

Transferencia rápida - La ejecución de pagos mediante transferencia intrabancaria de la cuenta del Cliente a la cuenta del PA. El pago difiere de los pagos realizados a través de PBL en que el Cliente debe rellenar él mismo todos los datos necesarios para realizar la transferencia.

Transacción - una operación de pago en el sentido de la Ley de 19 de agosto de 2011 sobre servicios de pago.

Transacción de entrada - la parte del proceso de gestión de pagos relativa al
pago efectuado por el cliente a AP.

Operación de liquidación - parte del proceso de procesamiento de pagos, relativa a la transferencia realizada por el PA a la cuenta del Socio. Para que se cree una Transacción de Liquidación, la Transacción de Entrada debe ser pagada por el Cliente. Una Transacción de Liquidación puede referirse a una única Transacción de Entrada (pago), o agregar múltiples de ellas.

Ley - Ley de 19 de agosto de 2011 sobre servicios de pago.

Validez del enlace - parámetro que especifica el punto en el tiempo más allá de en el que el Enlace de Pago deja de estar activo. Debe establecerse mediante el parámetro LinkValidityTime del Enlace de Pago.

Validez de las transacciones - parámetro que especifica el momento a partir del cual el Sistema de Pago en Línea se bloquea y devuelve automáticamente los pagos del Cliente. El valor predeterminado se calcula añadiendo 6 días a la fecha en que el Cliente ha seleccionado el Canal de Pago. También se puede establecer mediante el parámetro ValidityTime en el Enlace de Pago. En este caso, una vez transcurrido el tiempo indicado, el enlace deja de estar activo y los pagos se devuelven al Cliente. La validez máxima de la transacción es de 31 días.

Widget de pago automático - un mecanismo que permite el pago con tarjeta de los productos/servicios ofrecidos por el socio, en el que los datos de la tarjeta son introducidos por el cliente en un mecanismo integrado directamente en el sitio web del socio.
La invocación del formato de widget de Tarjeta requiere la implementación de
código JavaScript utilizando una biblioteca AP dedicada.

Widget de incorporación - una solución que permite al Integrador incrustar el Formulario de Integrador (preparado por Autopay) directamente en el sitio web del Integrador, de modo que el Socio no es redirigido al dominio de Autopay al registrar su tienda - todo el proceso se lleva a cabo en el sitio web del Socio.

Marca blanca - modelo de integración, en el que el cliente ya en el Servicio selecciona el canal de pago y acepta las regulaciones (siempre que la necesidad de aceptarlas resulte de acuerdos individuales entre el Socio y el PA), y el inicio de la transacción contenga un campo GatewayID completado (y en ciertos casos DefaultRegulationAcceptanceID o RecurringAcceptanceID).

Inicio de una orden de pago - el punto en el que el usuario de la pasarela de pago selecciona un canal de pago y es redirigido a una página acorde con el canal de pago seleccionado o (para pagos automáticos, monederos electrónicos o BLIK) se realiza un intento de adeudo en la tarjeta o cuenta en el proveedor del canal de pago.

Direcciones de las comunidades

PRUEBA

• host_gates: https://testpay.autopay.eu

• host_card_gates: https://testcards.autopay.eu

PRODUCCIÓN

• host_gates: https://pay.autopay.eu

• host_card_gates: https://cards.autopay.eu

Procesamiento de transacciones y liquidaciones

Organigrama del servicio de transacciones y compensación

En el Sitio Asociado, una vez completado el pedido, se presenta al cliente la opción de poder realizar un pago utilizando el Sistema. Al hacer clic en el enlace correspondiente se inicia la transacción y se abre en una nueva ventana:

a) una página dedicada del Sistema preparada por AP, en la que se presenta al Cliente
una lista de los Canales de Pago disponibles y un resumen de la operación registrada (ver Modelo de muro de pago) o

b) directamente desde un Canal de Pago (Banco, BLIK o para pago con Tarjeta) - (ver Modelo de marca blanca).

En el lado del Sistema, se validan los parámetros transmitidos y se guarda la transacción con un periodo de validez fijo. Si, en el momento de la validación, el período de validez del enlace ya se ha superado, el cliente recibirá un mensaje correspondiente (la verificación de la validez de la transacción también tiene lugar cuando se cambia el estado del pago). Tras la verificación positiva de los parámetros de la transacción (y tras la selección del
Canal de Pago), el Cliente autoriza la transacción. En su título, además de los
identificadores asignados por el Sistema, también puede haber una
descripción fija, previamente acordada entre el PA y el Socio, o un
valor dinámico transmitido por el Socio al inicio de la transacción.

Modelo de integración recomendado consiste en transmitir un mensaje para iniciar una transacción de
en segundo plano, es decir, sin redirigir al usuario al Sistema (véase Antes de la transacción). En este modelo, es posible utilizar formas avanzadas de autorización de transacciones (WhiteLabel, pagos automáticos, SDK móvil), diagnósticos de la corrección de los parámetros transmitidos y muchas otras extensiones.

Una vez autorizada la transacción (en la página del Canal de Pago) el cliente vuelve de ella al Sistema, donde el cliente es automáticamente redirigido al Servicio Asociado.

TIP: Encontrará una descripción detallada de la estructura del enlace de retorno en la sección
de la ficha Redirección al sitio asociado.

El estado de autorización (pago) recibido del Canal de Pagos se transmite desde el Sistema al Servicio Asociado mediante un mensaje ITN. El Sistema
repetirá el envío de mensajes hasta que el Servicio Asociado
acuse recibo o expire la notificación. Transacciones, que se pagan después de la expiración del período de validez de la transacción - serán devueltos al Cliente (remitente de la transferencia).

Opcionalmente, el Sistema puede notificar el hecho de que se ha emitido una operación de liquidación
. Para ello se utiliza un mensaje ISTN convenientemente modificado.

Pasos para integrar la gestión de transacciones y liquidaciones

Datos necesarios para la integración del procesamiento de transacciones y liquidaciones

Los datos necesarios intercambiados durante la integración difieren para los entornos de prueba y de producción. A continuación se muestra una lista de los parámetros que se pasan del
AP al Partner y en sentido inverso.

También se proporciona información general, es decir, canales de pago activos junto con gráficos (como resultado de la consulta de la lista de canales de pago disponibles).

Opcionalmente, puede haber datos adicionales transmitidos por el Socio al PA, por ejemplo: información sobre el contenido requerido de la cesta de la compra y la forma en que se procesa (en informes, facturación, panel de administración), requisitos adicionales (para saldos de prepago). Para pagos automáticos BLIK también el tiempo de vida por defecto de pagos automáticos activados y la etiqueta por defecto de pagos automáticos activados.

Datos intercambiados en el entorno de prueba

Datos facilitados por el socio a AP:

• Dirección para los mensajes ITN
• Dirección para los mensajes RPAN (puede ser la misma que para los mensajes ITN) [para pagos automáticos].
• Dirección para los mensajes RPDN (puede ser la misma que para los mensajes ITN) [para pagos automáticos].
• Dirección del remitente del pago (sin parámetros)

Datos transferidos de AP a Partner:

• Dirección del sistema de pago en línea
• ServiceID
• AcceptorID [para carteras en el modelo WhiteLabel].
• Llave compartida
• Mecanismo de funciones rápidas
• Dirección del formulario de prueba
• Dirección IP desde la que se envían los ITN
• Dirección del panel de administración
• Inicio de sesión
• Contraseña

Datos transferidos en un entorno de producción

Por Socio a AP:

• Dirección para los mensajes ITN
• Dirección para los mensajes RPAN (puede ser la misma que para los mensajes ITN) [para pagos automáticos].
• Dirección para los mensajes RPDN (puede ser la misma que para los mensajes ITN) [para pagos automáticos].
• Dirección del remitente del pago (sin parámetros)
• Direcciones de correo electrónico para los informes de transacciones
• Direcciones de correo electrónico para facturas e informes de facturación
• Direcciones de correo electrónico para reclamaciones (enviadas en mensajes a los pagadores)

Vía AP a Socio:

• Dirección del sistema de pago en línea
• ServiceID
• AcceptorID [para carteras en el modelo WhiteLabel].
• Llave compartida
• Mecanismo de funciones rápidas
• Dirección IP desde la que se envían los ITN
• Dirección del panel de administración
• Inicio de sesión
• Contraseña

Implantación de interfaces y procesos por parte del socio

En la versión mínima de la integración, debe implementarse el soporte para
iniciar una transacción, volver de ella y el soporte para la comunicación ITN.

TIP: Se recomienda familiarizarse con el esquema de funcionamiento. Si es necesario, también merece la pena familiarizarse con parámetros adicionales o servicios.

Pruebas de integración y migración al entorno de producción

Durante las pruebas, complete los campos en blanco de la hoja y envíela de nuevo a AP para confirmar la correcta integración de antes de migrar al entorno de producción.

TIP: Antes de la implantación en producción, se recomienda realizar pruebas de de acuerdo con la norma escenarios de prueba en la versión básica y, para integraciones más avanzadas, también según escenarios adicionales.

Inicio de la transacción

Descripción del inicio de la transacción

Al iniciar una transacción, el Servicio asociado transmite al sistema de pago en línea los parámetros necesarios para su ejecución y la posterior transmisión del estado del pago.

Todos los parámetros se pasan a través del método POST (Content-Type: application/x-www-form-urlencoded).

El protocolo distingue entre mayúsculas y minúsculas tanto en los nombres como en los valores de los parámetros
. Los valores de los parámetros transmitidos deben codificarse en UTF-8 (y transport-protocol-encode antes de enviar, a menos que la herramienta utilizada para enviar el mensaje lo haga por sí misma, ejemplo de codificación: URLEncode).

Lista de parámetros de inicio de transacción

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

Método de inicio de la transacción

La transacción se inicia mediante el envío de una llamada HTTPS una combinación de los parámetros anteriores a la dirección del sistema de pago en línea determinado durante el registro del servicio.

NOTAS: El número de transacciones iniciadas por el Socio en un minuto puede ser de un máximo de 100, a menos que el Socio y AP acuerden un límite superior como parte del acuerdo celebrado.

Ejemplo de inicio de una transacción:

Dirección:

• https://{host_gates}/pathway

Parámetros:

• ServicioID=2

• OrderID=100

• Importe=1,50

    Hash=2ab52e6918c6ad3b69a8228a2ab815f11ad58533eeed963dd990df8d8c3709d1
  

Enviar un mensaje sin todos obligatorio parámetros (ServiceID, OrderID, Importe y Hash) o que contengan valores erróneos de su
, harán que el proceso de pago se detenga con un código de error de transacción y un breve mensaje de error (sin retorno a la página del Servicio de socios).

IMPORTANTE "Par de parámetros ServiceID i OrderID identifica de forma única
la transacción. No se permite la repetición del valor del parámetro
. OrderID durante toda la duración de la prestación de servicios por el Sistema a
un Servicio Asociado (ServiceID)."

Parámetro opcional GatewayID se utiliza para especificar el Canal de Pago, mediante el cual se va a realizar el pago. Esto le permite transferir la pantalla de selección de Canales de Pago al Servicio. La lista actual de identificadores de Canales de Pago, junto con los logotipos, está disponible a través del método gatewayList.

El mensaje de inicio de la transacción puede transmitirse en segundo plano, es decir, sin
redirigir al usuario al Sistema de Pago Online. En este modelo, la selección del propio Canal de Pago también la realiza el Cliente en el Servicio del Socio.

Redirección al sitio asociado

Descripción de la redirección al sitio asociado

Inmediatamente después de que el Cliente complete la autorización de la transacción, es redirigido desde el sitio web del Canal de Pago al sitio web en línea del Sistema de Pago, donde el Cliente es redirigido automáticamente al Servicio
del Socio.

La redirección se implementa mediante el envío de una solicitud HTTPS (utilizando el método
GET) a una dirección de retorno predeterminada en el Servicio asociado. El protocolo distingue entre mayúsculas y minúsculas tanto en los nombres como en los valores de los parámetros.

Lista de parámetros de redirección para el sitio asociado

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

Ejemplo de mensaje que redirige al Cliente desde el sistema de pago en línea al Sitio Asociado

https://sklep_nazwa/strona_powrotu?ServiceID=123458&OrderID=123402816&Hash=5432d69a66d721b2f5f785432bf5a1fc1b913bdb3bba465856a5c228fe95c1f8

Notificaciones instantáneas (ITN)

Descripción de las notificaciones instantáneas

El Sistema transmite notificaciones de cambios en el estado de las transacciones tan pronto como recibe dicha información del Canal de Pago, y el mensaje siempre se aplica a una única transacción. Las confirmaciones de
son enviadas por el Sistema de Pago en Línea a la dirección del servidor del Servicio
del Socio, según lo establecido al añadir la configuración del Servicio del Socio.

NOTAS: El dominio debe ser público y accesible a través del Sistema. El dominio debe estar protegido por un certificado válido, emitido por una autoridad de certificación pública (Certificate authority) El servidor debe presentarse con una cadena de certificados completa (Chain of Trust) La comunicación debe basarse en TLS proxy versión 1.2 o 1.3 *Otras formas de seguridad de la conexión, por ejemplo VPN, mTLS deben acordarse individualmente con la persona responsable de la implementación.

Ejemplo:

https://sklep_nazwa/odbior_statusu

La notificación de un cambio en el estado de una transacción de entrada consiste en el envío de un
por parte del Sistema de un documento XML que contiene los nuevos estados de la transacción.

El documento se envía a través de HTTPS (puerto 443 por defecto) - método POST, como un parámetro HTTP con el nombre transacciones. Este parámetro se almacena utilizando el mecanismo de codificación de transporte Base64.

Formato de documento (XML)

	<?xml version="1.0" encoding="UTF-8"?>
	<transactionList>
		<serviceID>ServiceID</serviceID>
		<transactions>
			<transaction>
				<orderID>OrderID</orderID>
				<remoteID>RemoteID</remoteID>
				<amount>999999.99</amount>
				<currency>PLN</currency>
				<gatewayID>GatewayID</gatewayID>
				<paymentDate>YYYYMMDDhhmmss</paymentDate>
				<paymentStatus>PaymentStatus</paymentStatus>
				<paymentStatusDetails>PaymentStatusDetails</paymentStatusDetails>
			</transaction>
		</transactions>
		<hash>Hash</hash>
	</transactionList>

NOTAS: Nodo transacciones sólo puede contener un nodo transacción (y por lo que la notificación es siempre para una transacción). Valores de los elementos orderID i importe relativos a cada una de las transacciones son idénticos a los valores de los campos correspondientes proporcionados por el Servicio asociado al inicio de la transacción respectiva. Las excepciones aquí son los modelos en los que la comisión se añade al importe de la transacción. En tales casos, el valor de la cantidad en el ITN se incrementa en esta comisión. La validación del importe puede entonces realizarse sobre la base del campo opcional ITN startAmount. No obstante, este campo debe solicitarse durante la integración.

Lista de parámetros devueltos para las notificaciones instantáneas

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

TIP: Elemento hash (mensaje) se utiliza para autenticar el documento. Para obtener una descripción de cómo se calcula el hash, consulte la sección Seguridad de las transacciones.

Respuesta a la notificación instantánea

La respuesta de notificación espera un estado HTTP de 200 (OK) y
texto en formato XML (no codificado en Base64), devuelto por el
Partner Service en la misma sesión HTTP, que contenga la confirmación de la recepción del
estado de la transacción.

Estructura de confirmación (XML)

	<?xml version="1.0" encoding="UTF-8"?>
	<confirmationList>
		<serviceID>ServiceID</serviceID>
		<transactionsConfirmations>
			<transactionConfirmed>
				<orderID>OrderID</orderID>
				<confirmation>Confirmation</confirmation>
			</transactionConfirmed>
		</transactionsConfirmations>
		<hash>Hash</hash>
	</confirmationList>

Descripción de los campos de confirmación para notificaciones inmediatas

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

Si no hay una respuesta correcta a las notificaciones enviadas, el Sistema realizará nuevos intentos de comunicar el último estado de la transacción una vez transcurrido un tiempo especificado. El Servicio asociado debe realizar su propia
lógica empresarial (por ejemplo, correo electrónico de confirmación), solo después del primer
mensaje de un estado de pago determinado.

TIP: Merece la pena echar un vistazo a Esquema de renovación de mensajes
ITN/ISTN/IPN/RPAN/RPDN.

Descripción detallada del comportamiento y cambio de los estados de pago (paymentStatus)

El método de pago elegido por el cliente enviará cada vez un estado
. PENDIENTE. En otra comunicación ITN, el sistema proporcionará el estado de ÉXITO o FALLO.

NOTA Estado PENDIENTE no se enviará si:

• el cliente abandona o vuelve de la pantalla de la lista de métodos de pago sin seleccionar un método concreto. En este caso, el estado se enviará inmediatamente FALLO. El estado PENDIENTE no aparecerá porque el cliente no ha iniciado el proceso de pago.
• estado final (ÉXITO o FALLO) se entregará antes de que se envíe el ITN con un estado de PENDIENTE.

Para una transacción única (con parámetros únicos OrderID y RemoteID) no puede haber cambio de estatuto ÉXITO en PENDIENTE o ÉXITO en FALLO.

En cualquier caso, puede haber un cambio en el estado detallado - paymentStatusDetails (Los posteriores
mensajes de cambio de estado de detalle son meramente informativos y no deben dar lugar a
una nueva entrega del servicio/producto pagado, etc.).

En casos especiales de uso, puede haber un cambio de estado:

a) FALLO en ÉXITO (por ejemplo, después de que un consultor AP haya aprobado una transacción pagada con un importe incorrecto. Este comportamiento requiere acuerdos comerciales especiales y no está habilitado por defecto),

b) ÉXITO en FALLO (por ejemplo, después de activar varias transacciones con el mismo OrderIDpero diferente RemoteID). Tal caso se produce cuando el Cliente inicia múltiples pagos con el mismo OrderID (por ejemplo, el Cliente cambia su decisión sobre qué Canal de Pago desea pagar por la transacción). Cada uno de los pagos que inicia genera ITNs y el Socio debe distinguir entre las transacciones individuales en base al parámetro RemoteID. Como el momento de la recepción del estado FALLO puede ser muy diferente, puede ocurrir que reciba dicho estado después de recibir un ÉXITO (con un RemoteID). En tal caso, deberá acusarse recibo del mensaje ITN, pero no deberá implicar la cancelación del estado de la transacción en el sistema del Socio.

Gestión de los estados de las transacciones desde ITN - Modelo simplificado

En un modelo en el que no es necesario notificar al cliente por correo electrónico/sms
de los estados de no ÉXITO, es posible limitar la cantidad de
información guardada en la base de datos del Servicio y el seguimiento de los cambios de RemoteID.

Ya está bien:

• para estados distintos de ÉXITOconfirmar cada vez el ITN con la estructura de respuesta correcta, estado CONFIRMADO y el valor correctamente
  contado del campo Hash,

• en caso de recepción de primero estado ÉXITOañadir también actualizar el estado, su tiempo y RemoteID en la base de datos de Servicio y ejecutar procesos de negocio (notificaciones al cliente de un cambio de estado, ejecución de un envío de servicio/producto pagado, etc.),

• en caso de situación posterior ÉXITOcada vez que
  confirme el ITN con la estructura de respuesta correcta, el estado CONFIRMADO y el valor correctamente calculado del campo Hash, sin actualizar la
  base de datos del Servicio y sin procesos de negocio.

Gestión de los estados de las transacciones desde ITN - modelo completo

En un modelo en el que se necesita el historial completo de
cambios de estado de las transacciones y/o la notificación al cliente de los principales
cambios de estado de las transacciones, se debe utilizar una lógica que se aproxime a la siguiente descripción.

Seguridad de las transacciones

Descripción de la seguridad de la transacción

El Sistema de Pago en Línea utiliza varios mecanismos para aumentar la seguridad de las transacciones que se realizan a través de él. La transmisión de
entre todas las partes de una transacción se realiza utilizando
una conexión segura basada en el protocolo TLS con una clave de 2048 bits.

Además, la comunicación se asegura mediante una función hash calculada a partir de los valores de los campos del mensaje y la clave compartida (la propia clave compartida se almacena en el Sistema de forma cifrada mediante el algoritmo AES-ECB).

Se utiliza el algoritmo SHA256 o SHA512 como función hash (método determinado en la fase de configuración del Servicio de Socio respectivo en el sistema de pago en línea). El valor predeterminado es SHA256.

Cálculo del valor de una función hash

Descripción de cómo se calcula el valor de la función hash y ejemplos de cálculos de
para mensajes básicos.

NOTAS: Los ejemplos no tienen en cuenta todos los posibles campos opcionales, por lo que si dichos campos están presentes en un
mensaje concreto, deben incluirse en la función de acceso directo en el orden del
número que aparece junto al campo.

Cálculo del valor de la función hash - Campo hash

El valor de la función hash, utilizada para autenticar el mensaje, se calcula a partir de una cadena que contiene los campos concatenados del mensaje (concatenación de campos). Los valores de los campos se concatenan, sin nombres de parámetros, y se inserta un separador (en forma de carácter |) entre valores consecutivos (no vacíos). El orden en el que se pegan los campos sigue el orden en el que aparecen en la lista de parámetros de la documentación.

IMPORTANTE En ausencia de un parámetro opcional en el mensaje o en el caso de un valor de parámetro vacío, ¡no utilice el separador!

A la cadena creada de este modo se le añade al final una
clave, que es compartida entre el Servicio Asociado y el Sistema de Pago en Línea. A partir de la cadena
creada de este modo, se calcula el valor de la función hash, que constituye el
valor del campo Hash del mensaje.

Hash = function(valores_campo_1_mensaje + "|" + valores_campo_2_mensaje + "|" + ... + "|" + values_field_n_message + "|" + key_shared);

Ejemplo de cálculo del valor de la función hash al inicio de una transacción

Datos del Servicio de Atención al Socio:
ServiceID = 2

clave_compartida = 2prueba2

Dirección de la pasarela https://{host_gates}/pathway

a. Inicio de la operación.

Llamada POST sin cesta, con parámetros:

ServicioID=2
OrderID=100
Importe=1,50

Hash=2ab52e6918c6ad3b69a8228a2ab815f11ad58533eeed963dd990df8d8c3709d1

donde

Hash=SHA256(“2|100|1.50|2test2”)

b. Inicio de la transacción. Llamada POST con el carrito de la compra.

TIP: Opción tratada en detalle en la sección Cesta de productos.

ServiceID = 2

OrderID = 100

Importe = 1,50

Producto (descrito a continuación)

clave_compartida = 2prueba2

Cesta de productos (XML)

	<?xml version="1.0" encoding="UTF-8"?>
	<productList>
	   <product>
		  <subAmount>1.00</subAmount>
		  <params>
			 <param name="productName" value="Nazwa produktu 1" />
		  </params>
	   </product>
	   <product>
		  <subAmount>0.50</subAmount>
		  <params>
			 <param name="productType" value="ABCD" />
			 <param name="ID" value="EFGH" />
		  </params>
	   </product>
	</productList>

Tras codificar con la función base64, obtenemos el valor del parámetro Product:

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48cHJvZHVjdExpc3Q+PHByb2R1Y3Q+PHN1YkFtb3VudD4xLjAwPC9zdWJBbW91bnQ+PHBhcmFtcz48cGFyYW0gbmFtZT0icHJvZHVjdE5hbWUiIHZhbHVlPSJOYXp3YSBwcm9kdWt0dSAxIiAvPjwvcGFyYW1zPjwvcHJvZHVjdD48cHJvZHVjdD48c3ViQW1vdW50PjAuNTA8L3N1YkFtb3VudD48cGFyYW1zPjxwYXJhbSBuYW1lPSJwcm9kdWN0VHlwZSIgdmFsdWU9IkFCQ0QiIC8+PHBhcmFtIG5hbWU9IklEIiB2YWx1ZT0iRUZHSCIgLz48L3BhcmFtcz48L3Byb2R1Y3Q+PC9wcm9kdWN0TGlzdD4=

El valor Hash se calcula del siguiente modo:

Hash=SHA256(“2|100|1.50|PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48cHJvZHVjdExpc3Q+PHByb2R1Y3Q+PHN1YkFtb3VudD4xLjAwPC9zdWJBbW91bnQ+PHBhcmFtcz48cGFyYW0gbmFtZT0icHJvZHVjdE5hbWUiIHZhbHVlPSJOYXp3YSBwcm9kdWt0dSAxIiAvPjwvcGFyYW1zPjwvcHJvZHVjdD48cHJvZHVjdD48c3ViQW1vdW50PjAuNTA8L3N1YkFtb3VudD48cGFyYW1zPjxwYXJhbSBuYW1lPSJwcm9kdWN0VHlwZSIgdmFsdWU9IkFCQ0QiIC8+PHBhcmFtIG5hbWU9IklEIiB2YWx1ZT0iRUZHSCIgLz48L3BhcmFtcz48L3Byb2R1Y3Q+PC9wcm9kdWN0TGlzdD4=|2test2”)

Ejemplo de cálculo del valor de una función hash cuando un cliente vuelve al sitio asociado

Datos del Servicio de Atención al Socio:

ServiceID = 2

clave_compartida = 2prueba2

<https://sklep_nazwa/strona_powrotu?ServiceID=2>&OrderID=100&Hash=254eac9980db56f425acf8a9df715cbd6f56de3c410b05f05016630f7d30a4ed

donde

Hash=SHA256("2|100|2test2")

Ejemplo de cálculo del valor de una función hash en un mensaje ITN

Datos del Servicio de Atención al Socio:

serviceID = 1

clave_compartida = 1prueba1

ITN (XML)

	<?xml version="1.0" encoding="UTF-8"?>
	<transactionList>
	   <serviceID>1</serviceID>
	   <transactions>
		  <transaction>
			 <orderID>11</orderID>
			 <remoteID>91</remoteID>
			 <amount>11.11</amount>
			 <currency>PLN</currency>
			 <gatewayID>1</gatewayID>
			 <paymentDate>20010101111111</paymentDate>
			 <paymentStatus>SUCCESS</paymentStatus>
			 <paymentStatusDetails>AUTHORIZED</paymentStatusDetails>
		  </transaction>
	   </transactions>
	   <hash>a103bfe581a938e9ad78238cfc674ffafdd6ec70cb6825e7ed5c41787671efe4</hash>
	</transactionList>

donde

Hash=SHA256(“1|11|91|11.11|PLN|1|20010101111111|SUCCESS|AUTHORIZED|1test1”)

Ejemplo de respuesta (XML)

	<?xml version="1.0" encoding="UTF-8"?>
	<confirmationList>
	   <serviceID>1</serviceID>
	   <transactionsConfirmations>
		  <transactionConfirmed>
			 <orderID>11</orderID>
			 <confirmation>CONFIRMED</confirmation>
		  </transactionConfirmed>
	   </transactionsConfirmations>
	   <hash>c1e9888b7d9fb988a4aae0dfbff6d8092fc9581e22e02f335367dd01058f9618</hash>
	</confirmationList>

donde el valor

Hash=SHA256("1|11|CONFIRMED|1test1");

Ejemplo de cálculo del valor de la función hash en la consulta de la lista de Canales de Pago

Datos del Servicio de Atención al Socio:

ServiceID = 100

MessageID = 11111111111111111111111111111111

Divisas = PLN,EUR

Idioma = EN

clave_compartida = 1prueba1

donde el valor

Hash=SHA256('100|11111111111111111111111111111111|PLN,EUR|PL|1test1')

La respuesta a la llamada anterior puede ser la siguiente (nota: no hay campo hash en la respuesta):

{
    "result": "OK",
    "errorStatus": null,
    "description": null,
    "gatewayGroups": [
        {
            "type": "PBL",
            "title": "Przelew internetowy",
            "shortDescription": "Wybierz bank, z którego chcesz zlecić płatność",
            "description": null,
            "order": 1,
            "iconUrl": null
        },
        {
            "type": "BNPL",
            "title": "Kup teraz, zapłać później",
            "shortDescription": "Kup teraz, zapłać później",
            "description": null,
            "order": 2,
            "iconUrl": null
        }
    ],
    "serviceID": "10000",
    "messageID": "2ca19ceb5258ce0aa3bc815e80240000",
    "gatewayList": [
        {
            "gatewayID": 106,
            "name": "Płatność testowa PBL",
            "groupType": "PBL",
            "bankName": "NONE",
            "iconURL": "https://testimages.autopay.eu/pomoc/grafika/106.gif",
            "state": "OK",
            "stateDate": "2023-10-03 14:35:01",
            "description": "Płatność testowa",
            "shortDescription": null,
            "descriptionUrl": null,
            "availableFor": "BOTH",
            "requiredParams": ["Nip"],
            "mcc": {
                "allowed": [1234, 9876],
                "disallowed": [1111]
            },
            "inBalanceAllowed": true,
            "minValidityTime": null,
            "order": 1,
            "currencies": [
                {
                    "currency": "PLN",
                    "minAmount": 0.01,
                    "maxAmount": 5000.00
                }
            ],
            "buttonTitle": "Płacę"
        },
		{
            "gatewayID": 701,
            "name": "Zapłać później z Payka",
            "groupType": "BNPL",
            "bankName": "NONE",
            "iconUrl": "https://testimages.autopay.eu/pomoc/grafika/701.png",
            "state": "OK",
            "stateDate": "2023-10-03 14:37:10",
            "description": "<div class=\"payway_desc\"><h1>Dane dotyczące kosztu</h1><p>Zapłać później - jednorazowo do 45 dni (...). Szczegóły oferty na: <a href="?r="https://payka.pl\" target=\"_blank\">Payka.pl</a></p></div>",
            "shortDescription": "Zapłać później - jednorazowo do 45 dni lub w kilku równych ratach",
            "descriptionUrl": null,
            "availableFor": "B2C",
            "requiredParams": [],
            "mcc": null,
            "inBalanceAllowed": false,
            "minValidityTime": 60,
            "order": 2,
            "currencies": [
                {
                    "currency": "PLN",
                    "minAmount": 49.99,
                    "maxAmount": 7000.00
                }
            ],
            "buttonTitle": "Płacę"
        }
    ]
}

Registro y explotación de Servicios basados en el Formulario Integrador

Esquema de funcionamiento para añadir y editar servicios

Este capítulo describe las reglas relacionadas con el intercambio de mensajes entre el PA y la Plataforma Integradora dentro de la funcionalidad de añadir y editar Servicios, que por defecto se realiza utilizando la API REST y opcionalmente utilizando los Web-Services del protocolo SOAP (el Servicio proporciona su definición en forma de un documento WSDL).

El Socio proporciona un enlace en su Plataforma, cuya selección por parte de el Cliente envía un mensaje a AP para recibir un enlace que dirige al Formulario del Integrador preparado por AP (los efectos visuales como el esquema de colores o el logotipo del Integrador en el formulario se determinan durante la integración).

NOTA También es posible incrustar el Formulario Integrador preparado por Autopay directamente en el sitio web Integrador (en un Iframe). Para ello, se utiliza un elemento HTML denominado Iframe. El uso de este tipo de solución implica trabajo adicional por parte del Integrador, pero permite al Socio permanecer en el sitio web del Integrador durante todo el proceso de registro/edición de la tienda. La solución se describe detalladamente en el capítulo titulado "El sitio web del integrador". "Widget de incorporación".

Los datos recogidos en el formulario (una vez cumplimentado por el cliente) son procesados por AP, donde, dependiendo del tipo de formulario, se realiza el registro/edición/adición de otro servicio. Tras superar con éxito este paso, los datos de configuración del servicio y los enlaces de verificación (al editar datos no sensibles, los enlaces no aparecerán) se envían de forma asíncrona al Integrador a través de los canales establecidos durante la integración. Paralelamente, también se envía al cliente un correo electrónico que contiene enlaces al pago de verificación (es posible desactivar este envío para sustituirlo por una comunicación que tenga lugar directamente a través del Integrador).

El cliente en este momento es redirigido automáticamente a la página de retorno del Integrador (la dirección se determina durante la integración) o se le presenta una página de agradecimiento por utilizar el servicio, que opcionalmente puede incluir enlaces para la verificación del pago y/o un enlace a la Plataforma del Integrador.

Una vez que el cliente ha pagado la transacción de verificación, AP comprueba la corrección de los datos declarados por dicho cliente durante el registro del servicio. Si AP asigna un estado de verificación positivo, se activa el servicio de pago del servicio y se envía un mensaje a el Cliente con los términos y condiciones aceptados por éste en el formulario de registro.

IMPORTANTE La versión de producción del servicio se encuentra detrás del firewall. Acceso se asigna para un finito y definido durante la integración de la IP pool. Esto no se aplica al entorno de prueba.

IMPORTANTE Para un único Integrador en un entorno determinado (prueba/producción) se proporciona un único ID de plataforma (PlatformID) y una clave compartida utilizada para construir el hash de todos los mensajes intercambiados entre el Integrador y el PA dentro del proceso de registro y edición de servicios.

IMPORTANTE El enlace generado por el PA que conduce al formulario
para registrar/editar datos de servicio tiene un tiempo de validez predeterminado de 24 horas. Este valor puede modificarse a petición del Integrador.

IMPORTANTE No está permitido compartir de ninguna forma (tampoco en código que se ejecute en un servidor de terceros) los datos de autorización del servicio prestado por el PA (PlatformID/key compartida).

IMPORTANTE Si, al registrarse o editar una tienda, el cliente selecciona varias divisas con las que se pueden realizar pagos en la tienda, cada una de estas divisas, junto con la cuenta de facturación que se le haya asignado, deberá verificarse por separado, mediante una transferencia de verificación.

IMPORTANTE En el formulario utilizado para la edición de datos, la verificación de identidad debe tener lugar antes de que el en él se muestren los datos actuales del Servicio. Para este fin, al Cliente se le presentan dos canales de verificación: un
mensaje sms o un correo electrónico. Tras seleccionar uno de ellos, se envía al cliente un código de verificación (para ello se utiliza el número de teléfono o dirección de correo electrónico facilitados por el cliente durante el proceso de registro), que deberá ser introducido por el cliente en un formulario adicional. Una vez cumplimentado correctamente el de este campo y verificado por AP, se concede al Cliente acceso al
formulario de edición de datos con todo su contenido.

NOTAS: En parte Procesamiento de transacciones y liquidaciones Se describen las
funcionalidades y cómo se integran en el ámbito relacionado con la gestión de
pagos por el Servicio y los servicios relacionados con la gestión de pagos, por ejemplo,
esquema de facturación.

En el modelo Integrador no están disponibles las siguientes opciones funciones de la parte transaccional:

a) Datos que deben intercambiarse durante la integración

b) Cesta de productos

Datos intercambiados durante la integración del formulario integrador

Datos intercambiados en el entorno de prueba

Datos transferidos de AP a Partner:

• Dirección del sistema de pago en línea
• Dirección de servicio (direcciones en las que el integrador puede utilizar los distintos métodos)
• PlatformID
• ServiceID (para el servicio de transferencia de créditos de verificación)
• Clave compartida para el servicio de registro y edición
• Clave compartida para el servicio de transferencia de créditos de verificación
• Mecanismo de funciones rápidas
• Dirección IP desde la que se envían los ITN
• Dirección del panel de administración del integrador (opcional)
• Inicio de sesión
• Contraseña

Datos facilitados por el socio a AP:

• Dirección ITN tras la transferencia de verificación
• Dirección de devolución tras la transferencia de verificación
• Información sobre las divisas de que dispondrán los comercios integradores
• Información sobre los canales para enviar la configuración del Servicio y los Enlaces de Verificación
• Dirección de correo electrónico del integrador para enviar configuraciones de servicio por correo electrónico
• Dirección en la que el integrador emitirá servicios para recibir mensajes ICN
• Información en caso de modificación del periodo de validez por defecto de un enlace que conduce al formulario de registro/edición de datos de servicio (por defecto 24 horas)

Datos transferidos en un entorno de producción

Vía AP a Socio:

• Dirección del sistema de pago en línea
• Dirección de servicio (direcciones en las que el integrador puede utilizar los distintos métodos)
• PlatformID
• ServiceID (para el servicio de transferencia de créditos de verificación)
• Clave compartida para el servicio de registro y edición
• Clave compartida para el servicio de transferencia de créditos de verificación
• Mecanismo de funciones rápidas
• Dirección IP desde la que se envían los ITN
• Dirección del panel de administración del integrador (opcional)
• Inicio de sesión
• Contraseña

Por Socio a AP:

• Dirección IP desde la que se realiza la conexión a los servicios emitidos por Autopay
• Dirección ITN tras la transferencia de verificación
• Dirección de devolución tras la transferencia de verificación
• Direcciones de correo electrónico para los informes de facturación al Integrador
• Información sobre las divisas de que dispondrán los comercios integradores
• Información sobre los canales para enviar la configuración del Servicio y los Enlaces de Verificación
• Dirección de correo electrónico del integrador para enviar configuraciones de servicio por correo electrónico
• Dirección en la que el integrador emitirá un servicio para recibir mensajes ICN
• Dirección en la que el integrador emitirá un servicio para recibir notificaciones sobre el estado de la tarjeta (necesario si el integrador desea recibir dicha información)
• Información en caso de modificación del periodo de validez por defecto de un enlace que conduce al formulario de registro/edición de datos de servicio (por defecto 24 horas)

Descarga del enlace al formulario de integrador por integrador

El intercambio de mensajes (en formato JSON) entre el PA y la Plataforma Integradora, implementando la funcionalidad de descarga de enlaces a la forma de registro/edición de los servicios, se realiza a través de una API REST. El acceso al servicio está asegurado mediante el filtrado de direcciones IP.

Descripción de los campos enviados en el mensaje de solicitud al AP

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

Ejemplo 1: Registro de servicios

	{
	   "platformId":1,
	   "messageId":"22111111112411111111111111111130",
	   "messageTime":"2016-07-20T09:35:00.000",
	   "hash":"43688c048e451fba81ea7895cca13c5b6eb953a6ddf23c6089918259163381e1",
	   "formAction":"REGISTRATION",
	   "formParams":{
		  "SERVICE_URL":"https://serivce-integrator-test.pl",
		  "COMMISSION_MODEL":{
			 "PLN":"5"
		  },
		  "IS_CARDS_ENABLED":"TRUE"
	   }
	}

Ejemplo 2: Edición de los datos de un servicio con ID = 11111

	{
	   "platformId":1,
	   "messageId":"11111111111111111111111111211254",
	   "messageTime":"2016-07-20T09:35:00.000",
	   "hash":"b16c13f8b2f6e43d583689287aaa8ca87181d037df8083c9d678e34a23983750",
	   "formAction":"UPDATE",
	   "acceptorId":120,
	   "serviceIds":[
		  11111
	   ]
	}

Ejemplo 3: Edición de los datos de un servicio con ID = 11111

	{
	   "platformId":1,
	   "messageId":"11111111111111111111111111211254",
	   "messageTime":"2016-07-20T09:35:00.000",
	   "hash":"b16c13f8b2f6e43d583689287aaa8ca87181d037df8083c9d678e34a23983750",
	   "formAction":"UPDATE",
	   "formParams":{
		  "SERVICE_URL":"https://serivce-integrator-test-nowy.pl",
		  "COMMISSION_MODEL":{
			 "PLN":"4"
		  },
	   "acceptorId":120,
	   "serviceIds":[
		  11111
	   ]
	}

Ejemplo 4: Añadir otra tienda a un comercio existente con ID = 222222

	{
	   "platformId":1,
	   "messageId":"22111111112411111111111111111131",
	   "messageTime":"2016-07-20T09:35:00.000",
	   "hash":"81bc2f50d4284cf4c638c4cf0ca6a07827eccf937152db151979b394a67a863d",
	   "formAction":"ADD_SERVICE",
	   "acceptorId":222222,
	   "formParams":{
		  "SERVICE_URL":"https://serivce-integrator-test.pl",
		  "COMMISSION_MODEL":{
			 "PLN":"5"
		  },
		  "IS_CARDS_ENABLED":"TRUE"
	   }
	}

Ejemplo 5: Registro de tiendas en el mercado español.

{
    "platformId":1,
    "messageId":"22111111112411111111111111111131",
    "messageTime":"2016-07-20T09:35:00.000",
    "hash":"81bc2f50d4284cf4c638c4cf0ca6a07827eccf937152db151979b394a67a863d",
    "formAction": "REGISTRATION",
    "formParams": {
        "SERVICE_NAME": "Test ES 13",
        "SERVICE_URL": "https://serivce-integrator-test.pl",
        "ITN_URL": "https://serivce-integrator-test.pl/itn",
        "NUMERIC_TRADE": "58",
        "IS_REFUNDS_ENABLED": "true",
        "RETURN_URL": "https://serivce-integrator-test.pl/return",
        "COMPANY_NAME": "Test ES Company",
        "TAX_ID": "ES04211376N",
        "CITY": "Madrid",
        "COUNTRY": "ES",
        "POSTAL_CODE": "28006",
        "ADDRESS": "Testino 35",
        "IS_CARDS_ENABLED": "true",
        "ACTIVITY_KIND": "FOREIGN",
        "LEGAL_FORM": "AUTONOMO",
        "REGISTRATION_DATE": "2012-01-01",
        "REGISTRATION_COUNTRY": "ES",
        "CONTACT_EMAIL": "test@test.autopay.eu",
        "PHONE": "780171556",
        "NRB": "7720387252204459354426",
        "STATEMENT_DESCRIPTOR": "test shop ES",
        "LANGUAGE": "ES"
    }
}

Descripción de los campos del mensaje de respuesta al Integrador

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

TIP: Respuesta correcta - estado http 200.

TIP: Respuesta con mensaje de error - estado http 400.

Ejemplo de respuesta correcta:

	{
		"link": "https://integrator-form-domain/ e2287514541105a2eda2b85751e88be5998aec8c99cd83ba3073365ce1a243a1",
		"hash": "f9e02e83fe50920ee2efb0d2322b6200a71f3afcc366893487ced7ad2330a610",
		"messageId": "11111111111111111111111111111229",
		"formHash": "e2287514541105a2eda2b85751e88be5998aec8c99cd83ba3073365ce1a243a1"
	}

Ejemplos de respuesta incorrecta:

	{
		"errors": [
			{
				"field": "acceptorId",
				"error": "Value for field acceptorId required!",
				"errorCode": 6003
			}
		]
	}

>

	{
		"errors": [
			{
				"field": "messageTime",
				"error": "Message time is outdated",
				"errorCode": 6016
			}
		]
	}

>

	{
		"errors": [
			{
				"field": "hash",
				"error": "Invalid hash",
				"errorCode": 6000
			}
		]
	}

Códigos de error

Widget de incorporación

Se trata de una opción adicional ofrecida por Autopay en el proceso de incorporación de la tienda, que permite al Integrador incrustar el formulario
directamente en el sitio web del Integrador. En esta versión de la solución, el formulario de registro/edición de la tienda se sigue preparando y manteniendo en el sitio de Autopay, con la diferencia de que el Socio pasa por todo el proceso estando en el sitio del Integrador, obviando la redirección al dominio de Autopay. La colocación del formulario en el sitio
del Integrador se realiza mediante un elemento HTML denominado IFRAME. Un Integrador que opte por este tipo de solución deberá
implementar adicionalmente una funcionalidad para recibir los eventos enviados por el iframe de Autopay,
necesaria para la correcta visualización del Formulario de Onboarding en el sitio del Integrador.

NOTA Autopay recomienda incrustar el widget de onboarding en un sitio Integrador cuyo sitio web esté asegurado con un certificado SSL.

NOTA La dirección web del formulario Onboarding colocada en el IFRAME del sitio Integrator es un valor variable
(el parámetro formHash del enlace cambia), por lo que debe consultarse antes cada vez que se muestre la página del formulario
en el sitio Integrator.

Ejemplo de código HTML de página utilizando el widget onboarding

<!doctype html>
<html lang="pl">
<head>
	<meta charset="utf-8">
	<title>Example usage of Autopay onboarding widget</title>
	<base href="/">
	<meta name="viewport" content="width=device-width, initial-scale=1">
	<style>
		body {
			padding: 0;
			margin: 0;
		}
		.container {
			width: 100%;
			padding-left: 15px;
			padding-right: 15px;
			max-width: 1200px;
			margin: 0 auto;
		}
		header {
			padding: 30px 0;
			border-bottom: 1px solid #ccc;
		}
		footer {
			padding: 30px 0;
			border-top: 1px solid #ccc;
		}
		iframe {
			width: 700px;
			border: 0;
		}
	</style>
</head>
<body>
<header>
	<div class="container">
		INTEGRATOR PAGE HEADER
	</div>
</header>
<main>
	<section>
		<div class="container">
			<h1>Example usage of Autopay onboarding widget</h1>
			<p>integrator text before</p>
		</div>
	</section>
	<section>
		<div class="container">
			<iframe id="iframe" src="?r=quot;https://adres-formularza-onboardingowego/form/<formHash>"></iframe>
		</div>
	</section>
	<section>
		<div class="container">
			<p> integrator text after</p>
		</div>
	</section>
</main>
<footer>
	<div class="container">
		INTEGRATOR PAGE FOOTER
	</div>
</footer>
<script type="text/javascript">
	// wait for page to load everything
	document.addEventListener("DOMContentLoaded', function() {
		// create listener for widget events
		window.addEventListener('message', (e) => {
			// if event origin not matches autopay onboarding origin, then event not belongs to widget
			if (!/onboarding\.autopay\.eu$/.test(e.origin) {
				return;
			}
			// if there is no data in event or data is not string, then event is not valid 
			if (!e.data || typeof e.data !== 'string') {
				return;
			}
			let messageData;
			// parse event data string to JSON, if it fails, messageData will remain empty
			try {
				messageData = JSON.parse(e.data)
			} catch (err) {}
			if (!messageData) {
				return;
			}
			// listener for HEIGHT_CHANGE event, thanks to which the iframe window is at full height and the scroll bar is not displayed
			if (messageData.event === 'HEIGHT_CHANGE') {
				document.getElementById('iframe').style.height = messageData.data + 'px'
			}
			// listener for SCROLL_TOP event, which scrolls page to iframe top, because scroll can't happen in full height iframe window
			if (messageData.event === 'SCROLL_TOP') {
				const scrollToPosition = window.scrollY + document.getElementById('iframe').getBoundingClientRect()['y'];
				window.scrollTo({left: 0, top: scrollToPosition, behavior: 'smooth'});
			}
			// listener for FORM_SUCCESS event, which provides necessary data to continue onboarding process
			if (messageData.event === 'FORM_SUCCESS') {
				console.log('Verification links:', messageData.data.verificationLinks)
			}
		})
	})
</script>
</body>
</html>

Retorno del cliente a la Plataforma Integradora

La redirección del cliente puede tener lugar directamente después de la correcta registro/edición de la tienda o puede estar disponible en la página con
un agradecimiento en forma de enlace.

Envío de datos de configuración de servicios y enlaces de verificación (ICN)

Una vez que el Cliente ha enviado el formulario y finalizado el proceso de registro/edición, el PA debe enviar los datos de configuración del Servicio y los Enlaces de Verificación al Integrador. Esto puede hacerse de varias
maneras. Los canales de envío se acuerdan con el Integrador durante la
integración.

Hacemos posible proporcionar la información anterior mediante el intercambio de
mensajes a través de REST, tecnología de servicios web o mediante el envío de
mensajes de correo electrónico a través de correo electrónico (en forma de archivo protegido por contraseña).

Cada uno de los canales de envío dispone de su propio sistema de renovación en caso de que falle el intento de
envío de información al Integrador.

Por motivos de seguridad, sugerimos que el intercambio de información de datos de configuración se realice utilizando la API REST (por defecto) o Web-Services en un túnel IPSec compilado o filtrando direcciones IP.

Se utiliza un campo para asociar un mensaje ICN (recibido por el Integrador) con un registro de cliente
específico del formulario. formHash, que se
envía tanto en el mensaje ICN como en respuesta a la consulta del
enlace de formulario. De este modo se garantiza que el integrador disponga de información para qué registro recibió los datos de configuración en el mensaje ICN.

Envío de datos de configuración a través de REST

El intercambio de mensajes entre el PA y el Servicio de Socios que implementa la funcionalidad de añadir y editar Servicios de Socios se lleva a cabo a través de utilizando la API REST. Los mensajes se envían en formato JSON.

Descripción de los campos enviados en el mensaje de solicitud al Integrador

IMPORTANTE El orden de los atributos de la enumeración Hash debe seguir su numeración.

Ejemplo 1.

	{
	   "acceptorID":11111,
	   "serviceID":22222,
	   "serviceKey":"sa22a2729462f643cf4c989dddcf226b99b3a6bda11db43a433ab31a7ec2abe925",
	   "hash":"580a285b9bf95e60d4eaeb470d32858a5f0191a2a51b40a18ee7612fa9ced187",
	   "verificationLinks ":[
		  {
			 "link":"sampleLink",
			 "currency":"PLN"
		  }
	   ],
	   "panelLogin":"sample panel login",
	   "panelPassword":"sample panel password",
	   "panelAddress":"sample panel address",
	   "formHash":"sample form hash",
	   "method":"REGISTER"
	}

Descripción de los campos del mensaje de respuesta al PA

	{
		"resultStatus":"OK",
		"description":"sample description"
	}

Envío de datos de configuración a través de servicios web

El intercambio de mensajes entre el PA y el Servicio Asociado que realiza la funcionalidad de añadir y editar Servicios Asociados se lleva a cabo utilizando la tecnología Web-Services del protocolo SOAP.

El servicio proporciona su definición en forma de un documento WSDL (Web
Service Definitions Language), proporcionado por el PA durante
la integración.

Descripción de los campos enviados en el mensaje de solicitud al integrador - InstantConfigurationNotificationRequest

	<xsd:element name="InstantConfigurationNotificationRequest">
		<xsd:complexType>
			<xsd:sequence>
				<xsd:elementname="InstantConfigurationNotification" type="tns: InstantConfigurationNotification "/>
			</xsd:sequence>
		</xsd:complexType>
	</xsd:element>

	<xsd:complexType name=" InstantConfigurationNotification ">
		<xsd:sequence>
			<xsd:sequence>
				<xsd:element name="AcceptorID" type="xsd:int"/>
				<xsd:element name="ServiceID" type="xsd:int"/>
				<xsd:element name="ServiceKey" type="xsd:string"/>
				<xsd:element name="Hash" type="xsd:string"/>
				<xsd:element minOccurs="0" name="VerificationLinks" type="tns:VerificationLinks"/>
				<xsd:element minOccurs="0" name="PanelLogin" type="xsd:string"/>
				<xsd:element minOccurs="0" name="PanelPassword" type="xsd:string"/>
				<xsd:element minOccurs="0" name="PanelAddress" type="xsd:string"/>
				<xsd:element name="FormHash" type="xsd:string"/>
				<xsd:element name="Method" type="tns:Method"/>
			</xsd:sequence>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:complexType name="VerificationLink">
		<xsd:sequence>
			<xsd:element name="Currency" type="xsd:string"/>
			<xsd:element name="Link" type="xsd:string"/>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:complexType name="VerificationLinks">
		<xsd:sequence>
			<xsd:element maxOccurs="unbounded" name="VerificationLink" type="tns:VerificationLink"/>
		</xsd:sequence>
	</xsd:complexType>

	<xsd:simpleType name="Method">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="REGISTER"/>
			<xsd:enumeration value="UPDATE"/>
			<xsd:enumeration value="ADD_SERVICE"/>
		</xsd:restriction>
	</xsd:simpleType>

Descripción de los campos del mensaje

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

Ejemplo 1.

	<SOAP-ENV:Envelope
		xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
		<SOAP-ENV:Header/>
		<SOAP-ENV:Body>
			<ns2: InstantConfigurationNotificationRequest
				xmlns:ns2="http://integrator/ws/">
				< InstantConfigurationNotification>
					<AcceptorID>11111</AcceptorID>
					<ServiceID>22222</ServiceID>                
					<ServiceKey>22a2729462f643cf4c989dddcf226b99b3a6bda11db43a433ab31a7ec2abe925</ServiceKey>                
					<Hash>580a285b9bf95e60d4eaeb470d32858a5f0191a2a51b40a18ee7612fa9ced187</Hash>
					<VerificationLinks>
						<VerificationLink>
							<Currency>PLN</Currency>
							<Link>sampleLink</Link>
						</VerificationLink>
					  </VerificationLinks>
					<FormHash>generated_hash</FormHash>
		   <Method>REGISTER</Method>
				</ InstantConfigurationNotification>
			</ns2: InstantConfigurationNotificationRquest>
		</SOAP-ENV:Body>
	</SOAP-ENV:Envelope>

Mensaje de respuesta a AP

	<xsd:element name=" InstantConfigurationNotificationResponse">
		<xsd:complexType>
			<xsd:sequence>
				<xsd:element name="Result" type="tns:ResultStatus"/>
				<xsd:element name="Description" type="xsd:string"/>
			 </xsd:sequence>
		</xsd:complexType>
	</xsd:element>

>

	<xsd:simpleType name="ResultStatus">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="OK"/>
			<xsd:enumeration value="ERROR"/>
		</xsd:restriction>
	</xsd:simpleType>

Descripción de los campos del mensaje

	<SOAP-ENV:Envelope
		xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
		<SOAP-ENV:Header/>
		<SOAP-ENV:Body>
			<ns2: InstantConfigurationNotificationResponse
				xmlns:ns2="http://integrator/ws/">
				 <Result>OK</Result>
				 <Description>sample description</Description>
			</ns2: InstantConfigurationNotificationResponse>
		</SOAP-ENV:Body>
	</SOAP-ENV:Envelope>

Envío de datos de configuración por correo electrónico

La información sobre el servicio se envía a la dirección de correo electrónico especificada por el
integrador en forma de archivo protegido por contraseña. El número de teléfono al que deben enviarse las contraseñas se acuerda con el integrador durante la integración.

Notificación inmediata de la modificación de los datos AML tras la verificación en el Sistema de Verificación Autopay- ICN

El sistema Autopay permite al Integrador estar informado de los cambios en los datos ALD de la Tienda. Esto permite al Integrador por su parte para actualizar los datos que se han modificado en Autopay y presentarlos al Socio.

Esto se implementó mediante el envío de mensajes en formato JSON utilizando el método HTTP POST. El correcto funcionamiento del servicio requiere la implementación de un método en el lado del Integrador para aceptar el citado mensaje.

Estructura del mensaje

La estructura del mensaje enviado al Integrador se divide en tres nodos principales, como se muestra en la tabla siguiente.

Ejemplo 1. Mensaje con estado de verificación positivo

{ 
   "revisionHeader":{ 
      "orderId":"123_2d87806818cf319d7127ffb", 
      "revisionId":"03d5627b-b9fe-40c0-ae32-5c9620d804ee", 
      "autopayVerificationStatus":"POSITIVE" 
   }, 
   "dataHeader":{ 
      "acceptorId":345, 
      "dataTime":"2024-01-16T 09:16:13", 
      "serviceId":123, 
      "hash":"35a56e960b4a4650b727b098bafd1912cf4e3012c8927ec29b3af6408bc99199" 
   }, 
   "currentData":{ 
      "company":{ 
         "name":"Testowa firma", 
         "address":{ 
            "address":"ul Testowa 77", 
            "postalCode":"80-462", 
            "city":"Gdańsk", 
            "country":"PL", 
            "street":null, 
            "houseNumber":null, 
            "flatNumber":null 
         }, 
         "nip":"8219663675",
         "regon":"955459555", 
         "edg":"123",
         "krs":"1234567890",
         "phone":{ 
            "currentValue":"+48123456789", 
            "waitingValue":null 
         }, 
         "representingPersons":[ 
            { 
               "personName":{ 
                  "firstName":"Jan", 
                  "lastName":"Kowalski" 
               }, 
               "pesel":"PL", 
               "documentData":{ 
                  "number":"BKI332498",
                  "type":"ID", 
                  "expirationDate":"2030-01-01", 
                  "country":"PL" 
               }, 
               "citizenship":"32061970611", 
               "birthData":{ 
                  "date":"1932-06-19", 
                  "country":"PL" 
               } 
            } 
         ],
         "activityKind":"SP_ZOO", 
         "beneficials":[ 
            { 
               "personName":{ 
                  "firstName":"Piotr", 
                  "lastName":"Nowak" 
               },
               "citizenship":"PL", 
               "pesel":"32061970611", 
               "birthDate":"1932-06-19" 
            } 
         ], 
         "registrationDate":"2000-01-01", 
         "plenipotentiary":{ 
            "personName":{ 
               "firstName":"Jan", 
               "lastName":"Kowalski" 
            }, 
            "citizenship":"PL", 
            "birthData":{ 
               "date":"1932-06-19", 
               "country":"PL" 
            }, 
            "pesel":"32061970611", 
            "documentData":{ 
               "number":"BKI332498", 
               "type":"ID", 
               "expirationDate":"2030-01-01", 
               "country":"PL" 
            } 
         }, 
         "physicalPerson":null, 
         "partners":[ 
            { 
               "personName":{ 
                  "firstName":"Jan", 
                  "lastName":"Kowalski" 
               }, 
               "citizenship":"PL", 
               "pesel":"32061970611", 
               "birthData":{ 
                  "date":"1932-06-19", 
                  "country":"PL" 
               }, 
               "documentData":{ 
                  "number":"BKI332498", 
                  "type":"ID", 
                  "expirationDate":"2030-01-01", 
                  "country":"PL" 
               } 
            } 
         ] 
      }, 
      "service":{ 
         "name":"Testowy sklep", 
         "serviceUrl":"https://test.autopay.eu", 
         "urlITN":"https://test.autopay.eu/itn", 
         "returnUrl":"https://test.autopay.eu/return", 
         "trade":{ 
            "id":1, 
            "name":"Alkohol" 
         }, 
         "invoiceEmail":"invoice@test.autopay.eu", 
         "contactEmail":{ 
            "currentValue":"contact@test.autopay.eu", 
            "waitingValue":null 
         },
         "complaintEmail":"complaint@test.autopay.eu", 
         "reportEmail":"report@test.autopay.eu", 
         "balanceDetails":[ 
            { 
               "settlementNRB":"59124053967877760136628953", 
               "currency":"PLN", 
               "swiftCode":null, 
               "commissionModel":2, 
               "regulationId":12 
            } 
         ] 
      } 
   } 
} 

Ejemplo 2. Mensaje con estado de verificación positivo para una tienda en el mercado español

{ 
   "revisionHeader":{ 
      "orderId":"123_2d87806818cf319d7127ffb", 
      "revisionId":"03d5627b-b9fe-40c0-ae32-5c9620d804ee", 
      "autopayVerificationStatus":"POSITIVE"      
   }, 
   "dataHeader":{ 
      "acceptorId":345, 
      "dataTime":"2024-01-16T 09:16:13", 
      "serviceId":123, 
      "hash":"35a56e960b4a4650b727b098bafd1912cf4e3012c8927ec29b3af6408bc99199" 
   }, 
   "currentData":{ 
      "company":{ 
         "name":"Test Company", 
         "address":{ 
            "address":"ul Testinio 77", 
            "postalCode":"80-462", 
            "city":"Madrid", 
            "country":"ES", 
            "street":null, 
            "houseNumber":null, 
            "flatNumber":null 
         }, 
         "nip":"1215505438",
         "regon":null, 
         "edg":null,
         "krs":null,
         "phone":{ 
            "currentValue":"123456789", 
            "waitingValue":null 
         }, 
         "representingPersons":[ 
            { 
               "personName":{ 
                  "firstName":"Joan", 
                  "lastName":"Martinez" 
               }, 
               "pesel":null, 
               "documentData":{ 
                  "number":"BKI332498",
                  "type":"ID", 
                  "expirationDate":"2030-01-01", 
                  "country":"ES" 
               }, 
               "citizenship":"ES", 
               "birthData":{ 
                  "date":"1932-06-19", 
                  "country":"ES" 
               } 
            } 
         ],
         "activityKind":"FOREIGN", 
         "beneficials":[ 
            { 
               "personName":{ 
                  "firstName":"Roberto", 
                  "lastName":"Marques" 
               },
               "citizenship":null, 
               "pesel":null, 
               "birthDate":null 
            } 
         ], 
         "registrationDate":"2000-01-01", 
         "plenipotentiary":null, 
         "physicalPerson":null, 
         "partners":[],
         "language":"ES",
         "taxId": "1215505438", 
         "registrationCountry":"ES",
         "legalForm":"AUTONOMO",
         "tradeRegisterName":"NO_REGISTER"         
      }, 
      "service":{ 
         "name":"Test shop", 
         "serviceUrl":"https://test.autopay.eu", 
         "urlITN":"https://test.autopay.eu/itn", 
         "returnUrl":"https://test.autopay.eu/return", 
         "trade":{ 
            "id":1, 
            "name":"Alkohol" 
         }, 
         "invoiceEmail":"invoice@test.autopay.eu", 
         "contactEmail":{ 
            "currentValue":"contact@test.autopay.eu", 
            "waitingValue":null 
         },
         "complaintEmail":"complaint@test.autopay.eu", 
         "reportEmail":"report@test.autopay.eu", 
         "balanceDetails":[ 
            { 
               "settlementNRB":"59124053967877760136628953", 
               "currency":"EUR", 
               "swiftCode":"XXXXXXYY", 
               "commissionModel":2, 
               "regulationId":12 
            } 
         ] 
      } 
      "addons": {
            "service": {
                "statementDescriptor": "shop name"
            }
        }
   } 
} 

Ejemplo 3. Mensaje con estado de verificación positivo para una tienda en el mercado español

{ 
   "revisionHeader":{ 
      "orderId":"123_2d87806818cf319d7127ffb", 
      "revisionId":"03d5627b-b9fe-40c0-ae32-5c9620d804ee", 
      "autopayVerificationStatus":"POSITIVE",
      "autopayVerificationStatusReasons": []       
   }, 
   "dataHeader":{ 
      "acceptorId":345, 
      "dataTime":"2024-01-16T 09:16:13", 
      "serviceId":123, 
      "hash":"35a56e960b4a4650b727b098bafd1912cf4e3012c8927ec29b3af6408bc99199" 
   }, 
   "currentData":{ 
      "company":{ 
         "name":"Test Company", 
         "address":{ 
            "address":"ul Testinio 77", 
            "postalCode":"80-462", 
            "city":"Madrid", 
            "country":"ES", 
            "street":null, 
            "houseNumber":null, 
            "flatNumber":null 
         }, 
         "nip":"1215505438",
         "regon":null, 
         "edg":null,
         "krs":null,
         "phone":{ 
            "currentValue":"123456789", 
            "waitingValue":null 
         }, 
         "representingPersons":[ 
            { 
               "personName":{ 
                  "firstName":"Joan", 
                  "lastName":"Martinez" 
               }, 
               "pesel":null, 
               "documentData":{ 
                  "number":"***",
                  "type":"***", 
                  "expirationDate":null, 
                  "country":"***" 
               }, 
               "citizenship":"ES", 
               "birthData":{ 
                  "date":"1932-06-19", 
                  "country":"ES" 
               } 
            } 
         ],
         "activityKind":"FOREIGN", 
         "beneficials":[ 
            { 
               "personName":{ 
                  "firstName":"Roberto", 
                  "lastName":"Marques" 
               },
               "citizenship":null, 
               "pesel":null, 
               "birthDate":null 
            } 
         ], 
         "registrationDate":"2000-01-01", 
         "plenipotentiary":null, 
         "physicalPerson":null, 
         "partners":[],
         "language":"ES",
         "taxId": "1215505438", 
         "registrationCountry":"ES",
         "legalForm":"AUTONOMO",
         "tradeRegisterName":"NO_REGISTER"         
      }, 
      "service":{ 
         "name":"Test shop", 
         "serviceUrl":"https://test.autopay.eu", 
         "urlITN":"https://test.autopay.eu/itn", 
         "returnUrl":"https://test.autopay.eu/return", 
         "trade":{ 
            "id":58, 
            "name":"Usługi medyczne" 
         }, 
         "invoiceEmail":"invoice@test.autopay.eu", 
         "contactEmail":{ 
            "currentValue":"contact@test.autopay.eu", 
            "waitingValue":null 
         },
         "complaintEmail":"complaint@test.autopay.eu", 
         "reportEmail":"report@test.autopay.eu", 
         "balanceDetails":[ 
            { 
               "settlementNRB":"ES1111111111111111111111", 
               "currency":"EUR", 
               "swiftCode":"XXXXXXYY", 
               "commissionModel":2, 
               "regulationId":12 
            } 
         ] 
      } 
      "addons": {
            "service": {
                "statementDescriptor": "shop name"
            }
        }
   } 
}

Descripción de los principales campos

Valores de los distintos campos en función del escenario

• Datos de contacto y verificación

Es posible que algunos de los datos de contacto requieran verificación por parte del cliente. Los campos que pueden requerir verificación son:

currentData.company.phone 
currentData.service.contactEmail 

Cada uno de estos campos se representa como un objeto:

{ 
"currentValue":"wartość", 
"waitingValue":null 
} 

currentValue - valor actualmente en vigor en el sistema
waitingValue - en espera de verificación por parte del cliente. En una situación en la que el cliente ha introducido varios valores sin verificar ninguno de ellos, el campo waitingValue contendrá el último. Un valor nulo significa que no hay datos en espera de verificación por parte del cliente.

• Cabecera de revisión

Puede haber varias formas de este titular:

Completamente terminado:

"revisionHeader":{ 
"revisionId":"046b8dcf-3581-4079-813c-34d0a2871fae", 
"autopayVerificationStatus":"PENDING", 
"orderId":"151007_2d87806818cf319d7127ffb" 
} 

Dicha cabecera se producirá cuando la transacción de verificación
de un cliente deba pagarse durante una acción iniciada por el Integrador.

OrderId vacío:

"revisionHeader":{ 
"revisionId":"046b8dcf-3581-4079-813c-34d0a2871fae", 
"autopayVerificationStatus":"PENDING", 
"orderId":null 
} 

Esta forma de encabezado se producirá cuando la acción del Integrador genere una verificación no sensible, es decir, que no requiera
el pago de la transacción de verificación.

No revisionHeader:

"revisionHeader":null 

El revisionHeader no se producirá cuando Autopay inicialice un cambio dentro del servicio/aceptante
, por ejemplo, como resultado de una verificación periódica de datos.

• Campo revisionHeader.autopayVerificationStatus

El campo indica el estado de verificación de la revisión indicada. Valores posibles para este campo:
PENDIENTE - revisión pendiente
POSITIVO - la revisión ha sido aceptada
NEGATIVO - la revisión fue rechazada
NEED_FEEDBACK - información/acción necesaria del lado del cliente

Valor del campo revisionHeader.autopayVerificationStatus indica el estado de verificación por parte de Autopay y no está relacionado con la verificación de los datos de contacto realizada por el cliente.
Valor del campo revisionHeader.autopayVerificationStatus no se aplica a los datos del nodo currentData, es el estado de la revisión cargada.

Estado de verificación negativo:

"revisionHeader":{ 
      "orderId":"123_2d87806818cf319d7127ffb", 
      "revisionId":"03d5627b-b9fe-40c0-ae32-5c9620d804ee", 
      "autopayVerificationStatus":"NEGATIVE",
      "autopayVerificationStatusReasons": [
            {
                "reason": "ACTIVITY_KIND_INACTIVE",
                "description": "działalność zawieszona"
            },
            {
                "reason": "WRONG_REPRESENTATIVE_BENEFICIARY_DATA",
                "description": "błędne dane reprezentanta/beneficjenta"
            }
        ]       
   }

Dicho encabezado puede ocurrir si la Tienda recibe un estado de verificación de NEGATIVO o NEED_FEEDBACK después de la verificación por Autopay. El envío de un nodo autopayVerificationStatusReasons adicional es opcional y depende de la configuración del Integrador.

• Campo currentData.company.physicalPerson Este campo se rellena con el objeto que se indica a continuación cuando el registro o la edición se refiere a una actividad no registrada, es decir,
  una empresa. activityKind = NON_ACCOUNTED_ACTIVITY

{ 
   "personName":{ 
      "firstName":"Jan", 
      "lastName":"Kowalski" 
   }, 

   "pesel":"69010583482", 
   "documentData":{ 
      "number":"BKI332498", 
      "type":"ID", 
      "expirationDate":"2030-01-01", 
      "country":"PL" 
   }, 
   "citizenship":"PL", 
   "birthData":{ 
      "date":"1951-06-19", 
      "country":"PL" 
   }
} 

• Campo currentData.company.address
  El campo de dirección, dependiendo de los datos almacenados en Autopay, puede adoptar dos formas:

  • address.address rellenado y address.street , address.houseNumber , address.flatNumber vacíos
    Ejemplo:

  "address":{ 
   "address":"ul Testowa 77/3", 
   "postalCode":"80-462", 
   "city":"Gdańsk", 
   "country":"PL", 
   "street":null, 
   "houseNumber":null, 
   "flatNumber":null
  }
  

  • campo vacio direccion.direccion y rellenado direccion.calle , direccion.numeroCasa , direccion.numeroPiso
    Ejemplo:

  "address":{ 
   "address":null, 
   "postalCode":"80-462", 
   "city":"Gdańsk", 
   "country":"PL", 
   "street":"ul Testowa", 
   "houseNumber":77, 
   "flatNumber":3 
  }
  

• Campos adicionales

"language":"ES",
"taxId": "1215505438", 
"registrationCountry":"ES",
"legalForm":"AUTONOMO",
"tradeRegisterName":"NO_REGISTER"

Estos son los campos enviados en caso de integración en un mercado distinto del polaco.

"statementDescriptor": "shop name"

Campo que contiene el nombre de la Tienda que se mostrará en los extractos bancarios (actualmente no está disponible el servicio para transcribir el valor de este campo en los extractos bancarios).

Notificación inmediata de un cambio en el estado de los pagos con tarjeta (Tarjeta ICN)

El proceso de hacer tarjetas de pago a disposición de la tienda requiere la verificación de la tienda tanto en el lado de AP y el lado del administrador de pago con tarjeta, por lo que el lanzamiento de por lo general toma más tiempo que la propia activación de la tienda.

El sistema permite enviar una notificación instantánea cuando se activa o desactiva la posibilidad de realizar pagos mediante tarjetas de pago en tienda, para garantizar la coherencia de la configuración de la tienda entre la plataforma integradora y AP. Esto se implementó mediante
el envío de un mensaje en formato JSON utilizando la API REST.

NOTAS: El correcto funcionamiento del servicio requiere la implementación en el lado
del Integrador de un método para aceptar el citado mensaje.

Descripción de los campos del mensaje enviado al Integrador

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

Ejemplo.

	{
	"serviceId":"1111111",
	"orderId":"22222",
	"cardsStatus":"ACTIVE",
	"hash":"81eb70b8f2c4576bfb375a7ccbfcfb196b235556bcc329aa40a3dc8bfd",
	"currencies":["PLN","EUR","GBP","USD"]
	}

Descripción de los campos del mensaje de retorno al PA

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

Ejemplo.

	{
	"serviceId":"1111111",
	"orderId":"22222",
	"confirmation":"CONFIRMED",
	"hash":"81eb70bcb8f2c4576bfb375a7ccbfcfb196b2355986556b29aa40a3dc8bfd"
	}

Notificación inmediata del cambio para activar o desactivar un canal de pago en la tienda (ICN Gateway)

El sistema permite enviar una notificación inmediata al integrador cuando los canales de pago indicados se activan y desactivan en una tienda determinada. Esto se ha implementado mediante el envío de un mensaje en formato JSON. El correcto funcionamiento del servicio requiere la implementación de un método en el lado del Integrador para recibir dicho mensaje.

Descripción del campo del mensaje enviado al Integrador.

NOTAS: Si durante la integración con el Socio se ha establecido un separador para el recuento hash de los mensajes, se utilizará éste. En este caso, el recuento hash seguirá el esquema:

Hash = SHA256(campo_mensaje_1_valor + delimitador + campo_mensaje_2_valor + delimitador + campo_mensaje_3_valor + delimitador + [campos consecutivos separados por delimitador]+ clave_compartida)

Ejemplo:

{
    "serviceId": 111111,
    "gatewayConfigurations": [
        {
            "gatewayId": 101,
            "active": false
        },
        {
            "gatewayId": 100,
            "active": true
        }
    ],
    "orderId": "47781_0a25c3c9-e0a7-4bfa-9bdf-75ca75c2569d",
    "hash": "5f3dfeec2cea228e2f4db8840fdc0e4d91d224da195618c0c67c6a7ea53c1832"
}

Descripción de los campos del mensaje de retorno a Autopay.

Ejemplo:

Przykład.
{
"serviceId":"1111111",
"orderId":"22222",
"confirmation":"CONFIRMED",
"hash":"81eb70bcb8f2c4576bfb375a7ccbfcfb196b2355986556b29aa40a3dc8bfd"
}

GetAMLCompanyData recuperado por el integrador de servicios

GetAMLCompanyDataReq

Mensaje para obtener datos de Socios que estén actualizados en el Sistema. Dado que AP está obligada a garantizar que los datos de los Socios soportados estén actualizados, éstos podrán ser actualizados (en cualquier momento) basándose en fuentes externas de confianza. En vista de lo anterior, se requiere que antes de cada visualización en la Plataforma Integradora, se realice una actualización de los mismos en la Plataforma llamando al método GetAMLCompanyData.

	<xsd:element name="GetAMLCompanyDataReq">
		<xsd:complexType>
			<xsd:sequence>
				<xsd:element name="AcceptorID" type="xsd:int"/>
				<xsd:element name="Header" type="tns:Header"/>
			</xsd:sequence>
		</xsd:complexType>
	</xsd:element>

Descripción de los campos del mensaje

	<xsd:complexType name="Header">
		   <xsd:sequence>
				   <xsd:element name="PlatformId" type="xsd:string"/>
				   <xsd:element name="MessageTime" type="xsd:dateTime"/>
				   <xsd:element name="RequestId" type="xsd:long"/>
				   <xsd:element name="Hash" type="xsd:string"/>
			 </xsd:sequence>
	</xsd:complexType>

Descripción de los campos del mensaje

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

"GetAMLCompanyDataResp"

El mensaje es una respuesta a GetAMLCompanyDataResp.

	<xsd:element name="GetAMLCompanyDataResp">
		<xsd:complexType>
			<xsd:sequence>
				<xsd:element name="Result" type="xsd:string"/>
				<xsd:element name="ErrorStatus" type="xsd:string" nillable="true"/>
				<xsd:element name="Company" type="tns:Company"/>
				<xsd:element name="isServiceActive" type="xsd:boolean" nillable="true"/>
			</xsd:sequence>
		</xsd:complexType>
	</xsd:element>

Descripción de los campos del mensaje

TIP: Tipo de mensaje Empresay sus componentes individuales
data-deeplanslation/>, se describen detalladamente en la sección Tipos compuestos.

Recuperar información sobre la lista actual de normativas disponibles - GetLegalData

El sistema permite al Integrador recuperar la lista completa actual de normativas correspondientes a los
tipos de comisión disponibles para el Integrador (CommissionModel) o una lista específica de normativas limitada por los filtros especificados en los
parámetros de solicitud. Para ello, llame al método getLegalData (https://domena_BMAutopay/getLegalData) con los parámetros adecuados. El intercambio de mensajes entre Autopay y la plataforma Integrator está en formato JSON. Todos los parámetros se pasan a través del método POST (Content-Type: application/json). A continuación se muestra una lista de parámetros disponibles. El acceso al servicio está protegido mediante filtrado de direcciones IP.

Descripción de los campos del mensaje de solicitud

Ejemplo.
Solicitud de una lista de reglamentos para las tasas de comisión 1 y 2, en polaco e inglés para la moneda PLN.

{ 
   "header":{ 
      "platformId":"111111", 
      "messageId":22222, 
      "messageTime":"2020-06-01 09:36:00", 
      "hash":"31772235489560079037848456"

   }, 
   "filterParams":{ 
      "commissionmodelList":[ 
         1, 
         2 
      ], 
      "languageList":[ 
         "PL", 
         "EN" 
      ] 
   } 
} 

Descripción de los campos del mensaje de respuesta

Respuesta correcta - http estado 200.

Respuesta con mensaje de error - estado http 400.

Ejemplo.
Devolución de la lista de reglamentos

{ 
    "regulationList": [ 
        { 
            "commissionModel": 1, 
            "language": "PL", 
            "regulationLink":"https://platnosci-accept.bm.pl/regulations/api/download/4eaf489b-c27f-40ac-b888-032f562077dd", 
            "regulationId": 41,
             "currency": "PLN" 
        }, 
        { 
            "commissionModel": 3, 
            "language": "PL", 
            "regulationLink":"https://platnosci-accept.bm.pl/regulations/api/download/70c5638e-7301-46f9-87e1-522dcff1db4e", 
            "regulationId": 42, 
 	"currency": "PLN" 
        }, 
        { 
            "commissionModel": 6, 
            "language": "PL", 
            "regulationLink":"https://platnosci-accept.bm.pl/regulations/api/download/0ef22461-7245-4501-970f-e09f2929856f", 
            "regulationId": 43, 
	    "currency": "PLN" 
        } 
    ],
    "messageId": "22121111112411112211111311212260", 
    "status": "OK", 
    "hash": "a2bd34888537a5c91c2700f12ec4e59786b03e9d4a92ad9ffd1dc49c8c8edad2" 
} 

Lista de códigos de error

Modificar la configuración del servicio - "UpdateConfiguration"

"UpdateConfigurationReq"

Un mensaje que permite al Integrador cambiar la configuración de la Tienda sin tener que realizar una transferencia de verificación.

	<xsd:element name="UpdateConfigurationReq">
		<xsd:complexType>
			<xsd:sequence>
				<xsd:element name="ServiceID" type="xsd:int" minOccurs="0"/>
				<xsd:element name="Header" type="tns:Header"/>
				<xsd:element name="ConfigurationData" type="tns:ConfigurationData"/>
				<xsd:element name="Currency" type="xsd:string"/>
			</xsd:sequence>
		</xsd:complexType>
	</xsd:element>

Descripción de los campos del mensaje

	<xsd:complexType name="Header">
		<xsd:sequence>
			<xsd:element name="PlatformId" type="xsd:string"/>
			<xsd:element name="MessageTime" type="xsd:dateTime"/>
			<xsd:element name="RequestId" type="xsd:long"/>
			<xsd:element name="Hash" type="xsd:string"/>
		</xsd:sequence>
	</xsd:complexType>

Descripción de los campos del mensaje

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

	<xsd:complexType name="ConfigurationData">
		<xsd:sequence>
			<xsd:element name="isTransactionRefundAllowed" type="tns:BooleanType" minOccurs="0"/>
			<xsd:element name="CommissionModel" type="xsd:long" nillable="true"/>
			<xsd:element name="isCardsPaymentRequired" type="tns:BooleanType" minOccurs="0"/>
			<xsd:element name="ServiceUrl" type="xsd:string" minOccurs="0"/>
		</xsd:sequence>
	 </xsd:complexType>

Descripción de los campos del mensaje

NOTAS: Dado en ServiceUrl la dirección debe contener la parte fija del dominio.
Por ejemplo, un cambio de dirección: https://nazwasklepu.integrator.pl en https://nazwasklepu.pl

"ActualizarConfiguraciónResp"

El mensaje es una respuesta a UpdateConfigurationReq.

	<xsd:element name="UpdateConfigurationResp">
		<xsd:complexType>
			<xsd:sequence>
				<xsd:element name="Result" type="xsd:string"/>
				<xsd:element name="ErrorStatus" type="xsd:string" nillable="true"/>
			</xsd:sequence>
		</xsd:complexType>
	</xsd:element>

Descripción de los campos del mensaje

Cancelación de la edición actual del servicio que se está revisando - "CancelUpdate"

Mensaje utilizado para cancelar la edición de los datos de un servicio que está
actualmente en proceso de verificación. El método se utiliza cuando la configuración del Integrador en el lado del sistema
Autopay bloquea el manejo de múltiples verificaciones a la vez para mantener la coherencia de los datos modificados. Ejecución correcta CancelarActualización permite enviar los datos del formulario para editar los datos de la tienda sin
data-deeplanslation/>esperar al estado de verificación final de la edición de datos anterior.

NOTAS: Los intentos de recuperar el enlace del formulario para un sitio que está actualmente bajo verificación terminarán en un error: SHOP_IN_VERIFICATION_STATUS.

CancelarUpdateReq

	<xsd:element name="CancelUpdateReq">
		<xsd:complexType>
			<xsd:sequence>
				<xsd:element name="ServiceID" type="xsd:int" minOccurs="0"/>
				<xsd:element name="AcceptorID" type="xsd:int" minOccurs="0"/>
				<xsd:element name="Header" type="tns:Header"/>
			</xsd:sequence>
		</xsd:complexType>
	</xsd:element>

Descripción de los campos

CancelarUpdateResp

	<xsd:element name="CancelUpdateResp">
		<xsd:complexType>
			<xsd:sequence>
				<xsd:element name="Result" type="xsd:string"/>
				<xsd:element name="ErrorStatus" type="xsd:string" nillable="true"/>
			</xsd:sequence>
		</xsd:complexType>
	</xsd:element>

Descripción de los campos

Tipos compuestos

Cabecera

Tipo de mensaje para transmitir datos de cabecera relativos a
la seguridad de la comunicación y la corrección de los datos transmitidos.

	<xsd:complexType name="Header">
		<xsd:sequence>
			<xsd:element name="PlatformId" type="xsd:string"/>
			<xsd:element name="MessageTime" type="xsd:date"/>
			<xsd:element name="RequestId" type="xsd:long"/>
			<xsd:element name="Hash" type="xsd:string"/>
		</xsd:sequence>
	</xsd:complexType>

Descripción de los campos del mensaje

IMPORTANTE El orden de los atributos de la enumeración Hash debe seguir su numeración.

Dirección

Este tipo de mensaje se utiliza para transmitir la dirección de la entidad en cuestión.

	<xsd:complexType name="Address">
		<xsd:sequence>
			<xsd:element name=”Address” type=”xsd:string/>
			<xsd:element name=”PostalCode” type=”xsd:string/>
			<xsd:element name=”City” type=”xsd:string/>
			<xsd:element name=”Country” type=”xsd:string/>
		</xsd:sequence>
	</xsd:complexType>

Descripción de los campos del mensaje

Tipo NIP

Tipo que describe el número TIN con un límite de 2 a 15 caracteres.

	<xsd:simpleType name="NIPType">
		<xsd:restriction base="xsd:string">
			<xsd:minLength value="2"/>
			<xsd:maxLength value="15"/>
		</xsd:restriction>
	</xsd:simpleType>

Moneda

Tipo que describe la moneda.

	<xsd:simpleType name="Currency">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="PLN"/>
			<xsd:enumeration value="EUR"/>
			<xsd:enumeration value="USD"/>
			<xsd:enumeration value="GBP"/>
			<xsd:enumeration value="CZK"/>
		</xsd:restriction>
	</xsd:simpleType>

ForeignTransferModeType

Sistema de transferencia de la liquidación en el caso de una cuenta extranjera.

	<xsd:simpleType name="ForeignTransferModeType">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SWIFT"/>
			<xsd:enumeration value="SEPA"/>
		</xsd:restriction>
	</xsd:simpleType>

Beneficiarios

El objeto es una lista de los tipos de beneficiarios reales del socio.

	<xsd:complexType name="Beneficials">
		<xsd:sequence>
			<xsd:element name="Beneficial" type="tns:Beneficial" minOccurs="0" maxOccurs="2"/>
		</xsd:sequence>
	</xsd:complexType>

Beneficioso

El objeto contiene el tipo de beneficiario efectivo y una posible lista de
beneficiarios de ese tipo.

	<xsd:complexType name="Beneficial">
		<xsd:sequence>
			<xsd:element name="BeneficialType" type="xsd:int"/>
			<xsd:element name="BeneficialOwners" type="tns:BeneficialOwners" minOccurs="0" />
		</xsd:sequence>
	</xsd:complexType>

Descripción de los campos del mensaje

BeneficiariosPropietarios

El tipo describe la lista de beneficiarios reales.

	<xsd:complexType name="BeneficialOwners">
		<xsd:sequence>
			<xsd:element name="BeneficialOwner" type="tns:BeneficialOwner" minOccurs="0" maxOccurs="8"/>
		</xsd:sequence>
	</xsd:complexType>

BeneficiarioPropietario

El tipo describe los datos de un único beneficiario efectivo.

	<xsd:complexType name="BeneficialOwner">
		<xsd:sequence>
			<xsd:element name="FirstName" type="xsd:string" nillable="false"/>
			<xsd:element name="LastName" type="xsd:string" nillable="false"/>
			<xsd:element name="Citizenship" type="xsd:string"/>
			<xsd:element name="Share" type="xsd:int" minOccurs="0"/>
		</xsd:sequence>
	</xsd:complexType>

Descripción de los campos del mensaje

Plenipotenciario

Tipo de mensaje que describe el proxy.

	<xsd:complexType name="Plenipotentiary">
		<xsd:sequence>
			<xsd:element name="FirstName" type="xsd:string"/>
			<xsd:element name="LastName" type="xsd:string"/>
			<xsd:element name="Citizenship" type="xsd:string"/>
			<xsd:element name="Pesel" type="xsd:string" minOccurs="0"/>
			<xsd:element name="BirthDate" type="xsd:string" minOccurs="0"/>
			<xsd:element name="BirthCountry" type="xsd:string" minOccurs="0"/>
			<xsd:element name="DocumentType" type="xsd:string" minOccurs="0"/>
			<xsd:element name="Document" type="xsd:string" minOccurs="0"/>
			<xsd:element name="DocumentExpirationDate" type="xsd:string" minOccurs="0"/>
			<xsd:element name="DocumentCountryId" type="xsd:string" minOccurs="0"/>
		</xsd:sequence>
	</xsd:complexType>

Descripción de los campos del mensaje

Socios

El tipo describe la lista de asociados.

	<xsd:complexType name="Partners">
		<xsd:sequence>
			<xsd:element name="Partner" type="tns:Partner" minOccurs="0" maxOccurs="7"/>
		</xsd:sequence>
	</xsd:complexType>

Socio

Tipo de mensaje que describe al asociado.

	<xsd:complexType name="Partners">
		<xsd:sequence>
			<xsd:element name="FirstName" type="xsd:string"/>
			<xsd:element name="LastName" type="xsd:string"/>
			<xsd:element name="Citizenship" type="xsd:string"/>
			<xsd:element name="Pesel" type="xsd:string" minOccurs="0"/>
			<xsd:element name="BirthDate" type="xsd:string" minOccurs="0"/>
			<xsd:element name="BirthCountry" type="xsd:string" minOccurs="0"/>
			<xsd:element name="DocumentType" type="xsd:string" minOccurs="0"/>
			<xsd:element name="Document" type="xsd:string" minOccurs="0"/>
			<xsd:element name="DocumentExpirationDate" type="xsd:string" minOccurs="0"/>
			<xsd:element name="DocumentCountryId" type="xsd:string" minOccurs="0"/>
		</xsd:sequence>
	</xsd:complexType>

Descripción de los campos del mensaje

Servicio

Tipo de mensaje que describe el servicio asociado.

	<xsd:complexType name="Service">
		<xsd:sequence>
			<xsd:element name="Name" type="xsd:string" nillable="false"/>
			<xsd:element name="ServiceUrl" type="xsd:string" nillable="false"/>
			<xsd:element name="UrlITN" type="xsd:string" nillable="false"/>
			<xsd:element name="ReturnUrl" type="xsd:string" nillable="false"/>
			<xsd:element name="SettlementNRB" type="xsd:string" />
			<xsd:element name="SwiftCode" type="xsd:string" minOccurs="0"/>
			<xsd:element name="ForeignTransferMode" type="tns:ForeignTransferModeType" minOccurs="0"/>
			<xsd:element name="CommissionModel" type="xsd:long" nillable="true"/>
			<xsd:element name="isCardsPaymentRequired" type="xsd:boolean" minOccurs="0" />
			<xsd:element name="AverageServiceTurnover" type="xsd:decimal" minOccurs="0" />
			<xsd:element name="AverageTransactionAmount" type="xsd:decimal" minOccurs="0" />
			<xsd:element name="EconomicPurpose" type="xsd:string" minOccurs="0" />
			<xsd:element name="EconomicPurposeDescription" type="xsd:string" minOccurs="0" />
			<xsd:element name="NumericTrade" type="xsd:int" minOccurs="0" />
			<xsd:element name="InvoiceEmail" type="xsd:string" minOccurs="0" />
			<xsd:element name="ContactEmail" type="xsd:string" minOccurs="0"/>
			<xsd:element name="ComplaintEmail" type="xsd:string" minOccurs="0"/>
			<xsd:element name="ReportEmail" type="xsd:string" minOccurs="0"/>
			<xsd:element name="isTransactionRefundAllowed" type="xsd:boolean" minOccurs="0" />
			<xsd:element name="Currency" type="tns:Currency" minOccurs="0"/>
		</xsd:sequence>
	</xsd:complexType>

Descripción de los campos del mensaje

Empresa

Tipo de mensaje para la transmisión de datos del socio.

	<xsd:complexType name="Company">
		<xsd:sequence>
			<xsd:element name="CompanyRemoteId" type="xsd:string"/>
			<xsd:element name="Name" type="xsd:string"/>
			<xsd:element name="Address" type="tns:Address"/>
			<xsd:element name="Nip" type="tns:NIPType"/>
			<xsd:element name="Krs" type="xsd:string"/>
			<xsd:element name="Phone" type="xsd:string"/>
			<xsd:element name="RepresentingPersonFirstName" type="xsd:string"/>
			<xsd:element name="RepresentingPersonLastName" type="xsd:string"/>
			<xsd:element name="RepresentingPersonPesel" type="xsd:string"/>
			<xsd:element name="RepresentingPersonDateOfBirth" type="xsd:string"/>
			<xsd:element name="RepresentingPersonBirthCountry" type="xsd:string" minOccurs="0"/>
			<xsd:element name="RepresentingPersonCitizenship" type="xsd:string"/>
			<xsd:element name="RepresentingPersonPersonalDocumentType" type="xsd:string"/>
			<xsd:element name="RepresentingPersonPersonalDocument" type="xsd:string"/>
			<xsd:element name="RepresentingPersonPersonalDocumentExpirationDate" type="xsd:string"/>
			<xsd:element name="RepresentingPersonPersonalDocumentCountryId" type="xsd:string" minOccurs="0"/>
			<xsd:element name="Service" type="tns:Service"/>
			<xsd:element name="ActivityKind" type="xsd:string"/>
			<xsd:element name="LegalForm" type="xsd:string" minOccurs="0"/>
			<xsd:element name="PanelAdministrator" type="xsd:string" minOccurs="0" />
			<xsd:element name="isListedOnTheStockExchange" type="tns:BooleanType" />
			<xsd:element name="Beneficials" type="tns:Beneficials" minOccurs="0" />
			<xsd:element name="TradeRegisterName" type="xsd:string" minOccurs="0"/>
			<xsd:element name="RegistrationDate" type="xsd:string" minOccurs="0"/>
			<xsd:element name="Plenipotentiary" type="tns:Plenipotentiary" minOccurs="0"/>
			<xsd:element name="Partners" type="tns:Partners" minOccurs="0" />
			<xsd:element name="PhysicalPerson" type="tns:PhysicalPerson" minOccurs="0"/>
		</xsd:sequence>
	</xsd:complexType>

Descripción de los campos del mensaje

PhysicalPerson

Tipo de mensaje utilizado para transferir datos de un individuo. Debe completarse cuando ActivityKind = NON_ACCOUNTED_ACTIVITY.

	<xsd:complexType name="PhysicalPerson">
		<xsd:sequence>
			<xsd:element name="FirstName" type="xsd:string"/>
			<xsd:element name="LastName" type="xsd:string"/>
			<xsd:element name="Pesel" type="xsd:string"/>
			<xsd:element name="DocumentType" type="xsd:string" minOccurs="0"/>
			<xsd:element name="Document" type="xsd:string"/>
			<xsd:element name="DocumentExpirationDate" type="xsd:string"/>
			<xsd:element name="DocumentCountryId" type="xsd:string" minOccurs="0"/>
			<xsd:element name="Citizenship" type="xsd:string"/>
			<xsd:element name="BirthDate" type="xsd:string" minOccurs="0"/>
			<xsd:element name="BirthCountry" type="xsd:string" minOccurs="0"/>
		</xsd:sequence>
	</xsd:complexType>

Descripción de los campos del mensaje

Normas para verificar los datos de los beneficiarios en el formulario

La verificación de los datos del formulario se basa principalmente en la
forma jurídica de la empresa. En función de ella, se prevén los tipos de beneficiarios, se definen sus exclusiones mutuas y el número máximo de ocurrencias de para cada tipo.

El tipo de beneficiario se define en el formulario marcando por el cliente con la declaración apropiada.

Lista de parámetros para una transferencia de créditos de verificación

El Socio que crea una nueva cuenta en el Sistema está obligado a realizar una Transferencia de Verificación. Después de su ejecución, el PA lleva a cabo una evaluación de la fiabilidad del Socio, la corrección de los datos del Socio y la evaluación AML.

Cuando el socio actualiza los datos, AP espera que se realice una transferencia de verificación, sólo para los datos sensibles y clave.

Lista de parámetros para los que el registro o la edición de datos de servicio generará un enlace de transferencia de verificación

Nombre del campo

• Nombre
• Dirección
• Correo electrónico
• Nip
• Krs
• ActividadTipo
• ServiceUrl
• LiquidaciónNRB
• NumericTrade
• TradeRegisterName
• FechaDeRegistro
• SwiftCode
• Nombre
• Apellido
• Pesel
• Tipo de documento
• Documento
• Fecha de caducidad del documento
• DocumentCountryId
• Ciudadanía
• FechaNacimiento
• País de nacimiento

NOTAS: ServiceUrl es tratada como la misma si:
a. sólo difiere en el protocolo (http/https)
b. en el curso de la integración con el Socio, se ha confirmado la migración de la dirección del Sitio Web desde/a el subdominio CMS del Integrador (p. ej. przykladowastrona.integrator.pl = przykladowastrona.pl)
c. se ha omitido o añadido el componente "www" de la dirección de la tienda (por ejemplo. przykladowastrona.pl = www. przykladowastrona.pl)

NOTAS: El TIN, el KRS y la forma jurídica son datos que no se pueden
editar. Si es necesario modificar estos datos, el servicio debe registrarse de nuevo.

Enlace a la transferencia de verificación

El enlace a la Transferencia de Verificación y todas sus notificaciones ITN, incluyen el dedicado ServiceID y OrderID construido de acuerdo con el esquema mencionado durante la integración:

OrderID = ActivationServiceID_UID

Dónde:

• ActivationServiceID - es el valor ServiceID del Servicio verificado
• UID - es una cadena que garantiza la unicidad de la Transferencia de Verificación de un Servicio determinado.
• Todas las comunicaciones (inicio y retorno de la transacción de verificación, así como todas sus notificaciones ITN, que proporcionan información sobre el progreso del proceso de verificación) se firman con la clave compartida para el servicio de transferencia de verificación (también mencionada durante la integración).

TIP: Los parámetros ITN dedicados al proceso de verificación se describen en la sección Campos adicionales en el mensaje ITN/IPN de la transacción entrante. En particular, los campos de verificationStatus y verificationStatusReasons.

TIP: Las posibles transiciones de los estados de pago, las verificaciones y sus detalles se incluyen en las secciones: Descripción detallada del cambio en el estado de verificación - para una transacción completada correctamente (resultado positivo o negativo), Descripción detallada del cambio en el estado de verificación - para una transacción no completada correctamente.

Registro y gestión de los puntos de liquidación entre AP y la plataforma del mercado de socios

Descripción del funcionamiento del servicio de registro automático y puntos de liquidación

Este documento describe las reglas relacionadas con el intercambio de mensajes entre AP y la Plataforma Marketplace del Socio como parte de la funcionalidad para añadir Puntos de Liquidación (tecnología REST).

El Afiliado deberá proporcionar un botón en su Plataforma Marketplace, cuyo clic por parte del Cliente activará un método en el sistema AP que genera un enlace real a un formulario que permite el registro de un Punto de Liquidación.

Al recibir el enlace mencionado, la Plataforma del Mercado debe realizar una redirección automática al formulario bajo este enlace.

La cumplimentación y envío de los datos de la Tienda por parte del Cliente dará lugar al registro del Punto de Facturación en el sistema AP y a la devolución de una página de agradecimiento y un enlace de verificación en línea para comprobar la corrección de los datos introducidos. El enlace de verificación también se envía a la dirección de correo electrónico facilitada por el Cliente en el formulario.

Una vez que el Cliente ha realizado el pago de verificación y AP ha recibido los datos necesarios del Canal de Pago, el Punto de Liquidación recibe un estado de verificación final. Su valor positivo da lugar a la activación del Punto de Liquidación y a la disposición para realizar pagos utilizándolo, y se enviará un mensaje al Cliente con los términos y condiciones aceptados por éste en el formulario de registro.

IMPORTANTE La versión de producción del servicio se encuentra detrás del cortafuegos. El acceso a la misma se asigna a un grupo de IP finito y definido durante la integración. Esto no se aplica al entorno de pruebas.

IMPORTANTE Se proporciona un ID de plataforma (MarketplaceID) y una clave compartida para el servicio de registro para una plataforma Marketplace por entorno (prueba/producción).

IMPORTANTE No está permitido poner a disposición los datos de autorización del servicio, es decir, MarketplaceID y la clave compartida, de ninguna forma (incluido en el código de una aplicación que se ejecute en un servidor de terceros).

Datos que deben intercambiarse durante la integración de los servicios del Punto de Facturación

Datos intercambiados en el entorno de prueba

Datos transferidos en un entorno de producción

Proceso para añadir puntos de liquidación

Descripción del proceso

El intercambio de mensajes entre AP y el Servicio Asociado que implementa la funcionalidad de añadir Puntos de Liquidación se lleva a cabo utilizando la tecnología REST. Todos los parámetros de los mensajes se pasan utilizando el método POST. El protocolo distingue entre mayúsculas y minúsculas, tanto en los nombres como en los valores de los parámetros. Los valores de los parámetros transmitidos deben codificarse en UTF-8.

Descargar enlace activo al formulario de inscripción

Una vez que el cliente haya hecho clic en el botón de registro de la plataforma Marketplace, se le enviará la siguiente dirección https://adres_usługi/api/marketplace/link debe enviarse una solicitud del enlace actual al formulario de registro. El mensaje debe enviarse con la cabecera Content-Type: application/json y los parámetros indicados en la tabla siguiente:

Descripción de los campos del mensaje

IMPORTANTE El orden de los atributos de la enumeración Hash debe seguir su numeración.

Ejemplo de cálculo Hash para el siguiente mensaje:

	{
	"marketplaceID":1,
	"messageID":"12345678901234567890123456789000",
	"hash":"wartosc_hash"
	}

donde

Hash=SHA256(1|12345678901234567890123456789000|klucz_wspoldzielony) = wartosc_hash

Respuesta a la solicitud

En respuesta a la solicitud anterior, se devuelve (en la misma sesión HTTP) un mensaje que contiene un enlace al formulario o, en caso de error, su descripción junto con una indicación del campo afectado.

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

NOTAS: Cuando la Plataforma Marketplace recibe un enlace al formulario
, se debe realizar una redirección automática al formulario.

NOTAS: Cualquier intento de registrarse debe ir precedido de la descarga del enlace al formulario.

NOTAS: El enlace al formulario está activo por defecto durante 24 horas (valor se puede cambiar a petición del Socio) después de su generación. Después de este período, la visualización del formulario de registro no es posible.

Ejemplos de mensajes intercambiados al descargar un enlace a un formulario

(a) Solicitud correctamente tramitada.

SOLICITAR

	{
	"marketplaceID":1,
	"messageID":"12345678901234567890123456789000",
	"hash":"437c941b5c88b9d0bfa58a1d073d724f55cfed794c1cf9648ba2340c3dcc803f"
	}

RESPUESTA

	{
	"link": "https://adres_usługi/marketplace/ee0e88d81c11b110c1a35a740996453d745dcde0be449686be6ec0777a02be5d",
	"messageID": "12345678901234567890123456789000",
	"hash": "d01e20cc8ab2c3fbe907e805329d915a20058e96f1d6d91a863361444cbd6379"
	}

(b) MessageID ya ha sido utilizado, no es único.

SOLICITAR

	{
	"marketplaceID":1,
	"messageID":"12345678901234567890123456789012",
	"hash":"e43ff5f4b3121d1fd267bd66aaf446b079c28292f2a966e23eb1e8a8c0aaf81a"
	}

RESPUESTA

	{
		"errors": [
			{
				"field": "messageID",
				"error": "messageId not unique"
			}
		]
	}

(c) El MessageID único debe tener 32 caracteres.

SOLICITAR

	{
	"marketplaceID":1,
	"messageID":"1234567890123456789012345678900022222",
	"hash":"dc8d14b5e3491a700e7f2479f8c196cc0db76f41b2b2ffac1f042a6cad1e5914"
	}

RESPUESTA

	{
		"errors": [
			{
				"field": "messageID",
				"error": "size must be between 32 and 32"
			}
		]
	}

(d) El hash especificado es incorrecto.

SOLICITAR

	{
	"marketplaceID":1,
	"messageID":"12345678901234567890123456789001",
	"hash":"dc8d14b5e3491a700e7f2479f8c196cc0db76f41b2b2ffac1f042a6cad1eaaaa"
	}

RESPUESTA

	{
		"errors": [
			{
				"field": "hash",
				"error": "Invalid hash"
			}
		]
	}

Ampliaciones adicionales

Modelos alternativos de iniciación de transacciones

Preautorización de la tarjeta

Descripción general del funcionamiento del servicio de preautorización de tarjetas

El soporte de preautorización de tarjetas ofrece la funcionalidad de bloquear fondos en la tarjeta del cliente durante un tiempo determinado (por ejemplo, predeterminado durante el establecimiento del bloqueo) y, a continuación, realizar un cargo. Un caso especial es cuando el bloqueo se elimina sin que se haya deducido ningún importe (por ejemplo, no se ha prestado el servicio al cliente).

Todas estas operaciones (bloqueo de fondos, adeudo, retirada del bloqueo) deben ordenarse a través de la API del Sistema de Pago Autopay. Si no hay ninguna orden de adeudo en la tarjeta durante el periodo de validez de la operación que establece el bloqueo, el Sistema liberará los fondos, notificándoselo con un mensaje estándar de Cambio de Estado de la Transacción (ITN).

Otras operaciones (cargo con éxito, colocación de un bloqueo en la tarjeta y cargo posterior) también dan lugar al envío de un mensaje ITN. Este mensaje es la única información vinculante sobre un cambio en el estado de una transacción y (utilizado junto con el servicio transactionStatus; véase la sección Consulta sobre el estado de una transacción), ayuda a gestionar la transacción sin romper la sesión con el usuario (incluso en caso de diversos problemas de red). Acuses de recibo de operaciones síncronas (nodo confirmaciónsólo sirven para presentar información preliminar sobre la orden).

Pasos de una transacción de preautorización de tarjeta

Bloqueo a petición del socio

Es posible distinguir 3 formas básicas de colocar un candado en una tarjeta:

a) Establecimiento de un bloqueo durante la autorización de un pago único (Véase Régimen A de autorización previa). El cliente rellena el formato de la tarjeta, una vez iniciada la transacción, que el Socio indica en los parámetros de inicio:

- canal de pago con tarjeta (GatewayID=1500) y

- el deseo de asegurar fondos en lugar de gravar (Mantener=verdadero)

(b) Asunción de un bloqueo al iniciar un pago automático (inscripción de la tarjeta en el Servicio o la Aplicación móvil) (Véase Régimen B de autorización previa).

TIP: El ciclo completo y todos los eventos de pago automático según la documentación, modificados por el momento en que se realiza el cargo en la tarjeta y se establece el pago automático - en el modelo de preautorización esta operación transactionClear causa estos acontecimientos.

El cliente rellena el formato de la tarjeta, una vez iniciada la transacción, que el Socio indica en los parámetros de inicio:

- canal de pago con tarjeta (GatewayID=1503),

- el hecho de aceptar las condiciones del servicio de pago automático
data-deeplanslation/> prestado por AP (RecurringAcceptanceState=ACCEPTED, o después de
acuerdos de valor empresarial. PROMPT/FORCE)

- la opción de inicializar un pago automático con un posible
data-deeplanslation/> débito en la tarjeta (RecurringAction=INIT_WITH_PAYMENT)

- el deseo de asegurar fondos en lugar de gravar (Mantener=verdadero)

(c) Establecer un bloqueo utilizando una tarjeta previamente guardada (véase Régimen C de autorización previa).

TIP: El ciclo completo y todos los eventos del pago automático según la documentación, modificados por el momento del adeudo real de la tarjeta y el establecimiento del pago automático - en el modelo de preautorización esta operación. transactionClear causa estos acontecimientos.

El cliente no rellena el formulario de la tarjeta, sino que se produce una transacción previa de backend (sin redirección), en la que el socio indica en los parámetros de inicio:

- canal de pago con tarjeta (GatewayID=1503)

- indicación de una tarjeta añadida previamente (ClientHash derivado de
RPAN)

- elección del método de pago automático (RecurringAction=MANUAL)

- el deseo de asegurar fondos en lugar de gravar (Mantener=verdadero)

Cada uno de estos métodos para establecer un bloqueo da lugar a un mensaje ITN cuyo
estado indica el resultado de la autorización de la transacción. Además de los estados
estándar, en el caso de bloqueo de fondos, el Sistema podrá proporcionar en el
estado ITN
. paymentStatus=ON_HOLD, que constituye la confirmación del establecimiento de un
bloque de fondos en la tarjeta del Cliente. Además, el ITN contendrá, por defecto, un identificador global de transacción (remoteID), que será necesario para la posterior carga del bloqueo establecido.

Débito en tarjeta a petición del socio

Descripción del cargo en la tarjeta a petición del socio

Una vez colocado el candado, el socio puede cursar una orden de adeudo en la tarjeta
previamente autorizada. (Véase Régimen D de autorización previa). En para este propósito, se debe llamar a un servicio dedicado. transactionClear (https://{host_gateway}/webapi/transactionClear) con los parámetros
correspondientes. Todos los parámetros se pasan mediante el método POST (Content-Type: application/x-www-form-urlencoded). El protocolo distingue entre mayúsculas y minúsculas tanto en los nombres como en los valores de los parámetros. Los valores de los parámetros pasados deben estar codificados en UTF-8.

Descripción de los parámetros disponibles para el cargo en tarjeta a petición del socio

Confirmación de la transacción para el cargo en tarjeta a petición del socio

Para realizar una consulta correcta, debe enviarse un encabezado HTTP definido con el contenido adecuado junto con los parámetros pasados. La cabecera adjunta debe llamarse y tener el siguiente valor pay-bm, en su totalidad debe tener el siguiente aspecto . En caso de que el mensaje sea válido, se devuelve un texto con formato XML (en la misma sesión HTTP), que contiene una confirmación de la ejecución de la operación o una descripción del error.

Estructura de confirmación (XML)

	<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
	<balancePayoff>
	<serviceID>ServiceID</serviceID>
	<messageID>MessageID</messageID>
	<remoteOutID>RemoteOutID</remoteOutID>
	<hash>Hash</hash>
	</balancePayoff>

Estructura de confirmación (XML)

	<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
	<balancePayoff>
	<balancePointID>BalancePointID</balancePointID>
	<messageID>MessageID</messageID>
	<remoteOutID>RemoteOutID</remoteOutID>
	<hash>Hash</hash>
	</balancePayoff>

Descripción de los parámetros que deben devolverse para el cargo en tarjeta a petición del socio

Liberación del bloqueo a petición del socio

Una vez establecido el bloqueo, el Socio podrá ordenar su
desbloqueo (sin deducción de fondos) (Ver Régimen E de autorización previa). Para esta operación, utilice el servicio releaseHold (Véase Anulación de una operación impagada). Después de una correcta
iniciación de una liberación de bloqueo (una respuesta correcta a una transacción de cancelación
), el Sistema entregará de forma asíncrona el ITN del paymentStatus=FALLO y paymentStatusDetails=CANCELADO.

Liberación del bloqueo tras operaciones vencidas

En caso de inactividad del Socio (una vez establecido el bloqueo) durante un período predeterminado de validez de la transacción, ésta es liberada por el Sistema (sin deducción de fondos) (Ref. Régimen F de autorización previa). El sistema cancelará la transacción, eliminará el bloqueo
y proporcionará al ITN la información paymentStatus=FALLO y paymentStatusDetails=CANCELADO.

Sistemas de autorización previa

Régimen A de autorización previa: Establecimiento de un bloqueo durante la autorización de un pago único

Régimen B de autorización previa: Asunción de un bloqueo durante el inicio de un pago automático (inscripción de la tarjeta)

Esquema C de autorización previa: Configuración de un bloqueo utilizando una tarjeta previamente almacenada

Régimen D de autorización previa: Orden del socio de adeudar una tarjeta previamente autorizada

Esquema E de autorización previa: Orden del socio de liberar el bloqueo (sin deducción de fondos)

Régimen F de autorización previa: Liberación de bloqueo por el Régimen (sin retención de fondos)

Antes de la transacción

Descripción previa a la transacción

La pretransacción amplía el modelo estándar de iniciación de transacciones mediante
la gestión de necesidades específicas:

• ordenar un enlace de pago basado en los parámetros enviados

• adeudos al cliente (si no se requiere autorización adicional
  data-deeplanslation/>por parte del cliente).

• verificar la corrección del enlace de pago antes de que el cliente sea redirigido al Sistema - la llamada valida los parámetros y la configuración del Sistema.

• acortamiento del enlace de pago - en lugar de varios/varios parámetros,
  el enlace se acorta a dos identificadores.

• ocultar los datos sensibles de los parámetros de enlace de la transacción - pretransacción tiene lugar backend y el enlace a la continuación de la transacción no contiene datos sensibles, sólo los identificadores de la continuación.

• el uso del SDK móvil en una variante mixta: el inicio de la transacción
  lo realiza el backend de la aplicación móvil en lugar del propio SDK mediante el token de transacción
  .

TIP: Detalles sobre las variantes del SDK en Documentación del SDK.

Los casos de uso específicos de Pre-transacción, son cargas:

• BLIK 0
  Para utilizar este servicio, debe proporcionar GatewayID=509 y pasar el código de autorización de la transacción
  en el parámetro AuthorizationCode.

• BLIK 0 OneClick

• Gastos de "Pago automático
  Para utilizar este servicio, debe proporcionar uno de los siguientes datos GatewayID o gatewayType="Pago automático". y los parámetros necesarios.

• Autorizaciones a través de los monederos Visa
  Para utilizar este servicio, debe proporcionar GatewayID=1511 y pasar el token codificado
  en el parámetro PaymentToken. En ausencia de un token
  , la autorización tendrá lugar en el sitio del Sistema.

• Autorizaciones a través de monederos Google Pay

NOTAS: El servicio permite cargar la tarjeta almacenada en el monedero del cliente sin redirigirla al Sistema. A menudo, se aplica una autorización adicional en forma de 3DS (comportamiento por defecto del entorno de prueba, que puede reconfigurarse).

En el modelo Marca blanca integrar como se describe y a continuación, proporcionar la GatewayID=1512 y el token codificado en el parámetro PaymentToken. En ausencia de una ficha (o de un modelo distinto del Marca blanca) simplemente indique GatewayID=1512 - La autorización
data-deeplanslation/> tendrá lugar en el sitio web del Sistema.

• Autorizaciones a través de los monederos de Apple Pay
  Para utilizar este servicio, debe proporcionar GatewayID=1513. La autorización tendrá lugar en el sitio del Sistema.

• Autorización a través del formato nativo del SDK móvil

NOTAS: El servicio permite cargar la tarjeta, cuyos detalles se proporcionan en el
formato de tarjeta segura del SDK, y el inicio de la transacción en sí lo realiza el
backend de la aplicación móvil.

Además del GatewayID apropiado - 1500 para un pago único o 1503 para activar un pago automático (y otros parámetros) - el PaymentToken obtenido del SDK y el parámetro WalletType=SDK_NATIVE (descripción en la sección Iniciar una transacción con parámetros adicionales)

Llamada a una transacción previa

Es obligatorio para las pre-transacciones enviar backend (usando por ejemplo cURL) el mensaje de inicio estándar de la transacción (ver Inicio de la transacción), con una cabecera con valores
: 'pay-bm-continue-transaction-url':

Ejemplo de cabecera

'BmHeader: pay-bm-continue-transaction-url'.)

Además, se recomienda que el parámetro ClienteIP (para
reclamaciones, a efectos de información).

Ejemplo de puesta en marcha previa a la transacción (PHP)

	$data = array(
	 'ServiceID' => '100047',
	 'OrderID' => ‘20161017143213’,
	 'Amount' => '1.00',
	 'Description' => 'test bramki',
	 'GatewayID' => '0',
	 'Currency' => 'PLN',
	 'CustomerEmail' => 'test@bramka.pl',
	 'CustomerIP' => '127.0.0.0',
	 'Title' => 'Test title',
	'Hash' => 0c5ca136e8833e40efbf42a4da7c148c50bf99f8af26f5c9400681702bd72056
	);

	$fields = (is_array($data)) ? http_build_query($data) : $data;

	$curl = curl_init('https://{host_bramki}/test_ecommerce');
	curl_setopt($curl, CURLOPT_HTTPHEADER, array('BmHeader: pay-bm-continue-transaction-url'));
	curl_setopt($curl, CURLOPT_POSTFIELDS, $fields);
	curl_setopt($curl, CURLOPT_POST, 1);
	curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
	curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, true);
	$curlResponse = curl_exec($curl);
	$code = curl_getinfo($curl, CURLINFO_HTTP_CODE);
	$response = curl_getinfo($curl);
	curl_close($curl);

	echo htmlspecialchars_decode($curlResponse);

Respuesta a la transacción previa - enlace para el seguimiento de la transacción

En el caso de una correcta validación de los parámetros (y configuración) y
la necesidad de que el cliente realice una acción adicional (seleccionar el
canal de pago -si se especifica GatewayID=0, ejecución/confirmación de transferencia, introducción de código CVC/CVV, ejecución de 3DS) - se devolverá un XML con un enlace para continuar la transacción.

Ejemplo de fichero de enlace de continuación de transacción (XML)

	<?xml version="1.0" encoding="UTF-8"?>
		<transaction>
		<status>PENDING</status>
		<redirecturl>
		https://{host_bramki}/payment/continue/96VSD39Z6E/L6CGP5BH
		</redirecturl>
		<orderID>20180824105435</orderID>
		<remoteID>96VSD39Z6E</remoteID>
		<hash>
		1c6eae2127f0c3f81fbed3b6372f128040729a4d4e562fb696c22e0db68dbbe1
		</hash>
	</transaction>

Objeto previo a la transacción

Objeto transacción representa la recepción o retirada de fondos de una cuenta AP, como una compra o un reembolso completados.

Atributos del objeto de transacción para la pretransacción

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

Respuesta a Pre-transacción - no continuación de la transacción

En caso de validación no válida o carga fallida, no se genera ningún enlace de continuación
. Se devuelve (en la misma sesión HTTP) un texto
en formato XML que indica el estado de procesamiento de la solicitud.

Ejemplo de estado de tramitación de una solicitud (XML)

<?xml version="1.0" encoding="UTF-8"?>
<transaction>
	<orderID>OrderID</orderID>
	<remoteID>RemoteID</remoteID>
	<confirmation>ConfStatus</confirmation>
	<reason>Reason</reason>
	<blikAMList>
		<blikAM>
			<blikAMKey>Klucz1</blikAMKey>
			<blikAMLabel>Etykieta1</blikAMLabel>
		</blikAM>
		<blikAM>
			<blikAMKey>Klucz2</blikAMKey>
			<blikAMLabel>Etykieta2</blikAMLabel>
		</blikAM>
	</blikAMList>
	<paymentStatus>PaymentStatus</paymentStatus>
	<hash>Hash</hash>
</transaction>

Resultado anterior a la transacción

Parámetros devueltos para el resultado de la transacción previa.

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

	<blikAM>
	<blikAMKey>Klucz1</blikAMKey>
	<blikAMLabel>Etykieta1</blikAMLabel>
	</blikAM>
	…
	<blikAM>
	<blikAMKey>KluczN</blikAMKey>
	<blikAMLabel>EtykietaN</blikAMLabel>
	</blikAM>

Validación correcta de los parámetros

Si los parámetros (y la configuración) se validan correctamente y no hay necesidad de que el cliente realice una acción adicional - se devuelve una confirmación de la orden de adeudo.

Este es el caso cuando los datos son suficientes para realizar un adeudo para el canal de pago en cuestión, por ejemplo: BLIK 0 sin el código BLIK requerido (ni indicación del alias de la app móvil del banco), pago recurrente, pago con tarjeta OneClick sin el CVC/CVV/3DS requerido.

Resultado

confirmation=CONFIRMADO

Validación incorrecta de los parámetros

Si los parámetros (y configuración) no se validan correctamente - se devuelve un error.

Resultado

confirmation=NO CONFIRMADO

También puede devolverse un error en caso de respuesta sincrónica del Canal de Pago (por ejemplo, un error específico de un intento de inicializar un pago automático BLIK, es decir, reason= RECURRENCY_NOT_SUPPORTED).

NOTAS: También puede devolverse un error en caso de respuesta sincrónica del Canal de Pago (por ejemplo, un error específico de un intento de inicializar un pago automático BLIK, es decir reason=RECURENCY_NOT_SUPPORTED). Otro caso conocido es también el error de validación de la dirección indicada en el parámetro de inicio CustomerEmail (INVALID_EMAIL).

Tratamiento de las respuestas para las transacciones

Solicitar los datos de una transferencia rápida

Descripción de la orden de transferencia de datos en una transacción de transferencia rápida

La Transferencia Rápida es un método de pago que requiere que el Cliente reescriba de forma independiente los datos de transferencia proporcionados por el Sistema. Qué tipo de es un Canal de Pago dado, lo dice el parámetro gatewayType en respuesta a la llamada de servicio "Consulta de la lista de
Canales de Pago actualmente disponibles". Los datos de la transferencia se pueden mostrar al cliente:

• en el sitio AP (ejecución de transacciones basada en el modelo estándar de
  inicio de transacciones descrito en la parte Inicio de la transacción)

• en el sitio web del Socio (la ejecución de la transacción sin redirigir
  al cliente al sitio de la AP se describe más adelante).

Llamando a

Para la correcta transmisión del mensaje, un mensaje de inicio de transacción estándar debe ser enviado backend (por ejemplo,
cURL), con un encabezado
'BmHeader' de valor: pay-bm (En su totalidad, la cabecera debería tener este aspecto 'BmHeader: pay-bm'.). En caso de cabecera mal definida o de que falte cabecera, el mensaje se leerá erróneamente. Además, se recomienda pasar el parámetro
CustomerIP como se describe en IP de usuario (necesario para
procesos de reclamación, informes) y obligatorio es para pasar un parámetro distinto de cero. GatewayID (o gatewayType "Transferencia rápida
").

Implementación del inicio de transacciones en segundo plano (PHP)

	$data = array(
	 'ServiceID' => '100047',
	 'OrderID' => '20150723144517',
	 'Amount' => '1.00',
	 'Description' => 'test bramki',
	 'GatewayID' => '71',
	 'Currency' => 'PLN',
	 'CustomerEmail' => 'test@bramka.pl',
	 'CustomerIP' => '127.0.0.0',
	 'Title' => 'Test title',
	 'ValidityTime' => '2016-12-19 09:40:32',
	 'LinkValidityTime' => '2016-07-20 10:43:50',
	 'Hash' => 'e627d0b17a14d2faee669cad64e3ef11a6da77332cb022bb4b8e4a376076daaa'
	);

	$fields = (is_array($data)) ? http_build_query($data) : $data;

	$curl = curl_init('https://{host_bramki}/test_ecommerce');
	curl_setopt($curl, CURLOPT_HTTPHEADER, array('BmHeader: pay-bm'));
	curl_setopt($curl, CURLOPT_POSTFIELDS, $fields);
	curl_setopt($curl, CURLOPT_POST, 1);
	curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
	curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, true);
	$curlResponse = curl_exec($curl);
	$code = curl_getinfo($curl, CURLINFO_HTTP_CODE);
	$response = curl_getinfo($curl);
	curl_close($curl);

	echo htmlspecialchars_decode($curlResponse);

Respuesta - detalles de la transferencia

En el caso de pagos de este tipo, el Sistema genera un conjunto de datos necesarios para realizar una transferencia intrabancaria (y por tanto rápida) a la cuenta bancaria AP. Estos datos se colocan en la respuesta al inicio de la transacción
, en un documento xml.

Respuesta del sistema de pago al inicio de la transacción (XML)

	<?xml version="1.0" encoding="UTF-8"?>
	<transaction>
		<receiverNRB>47 1050 1764 1000 0023 2741 0516</receiverNRB>
		<receiverName>Autopay</receiverName>
		<receiverAddress>81-718 Sopot, ul. Powstańców Warszawy 6</receiverAddress>
		<orderID>9IMYEH2AV3</orderID>
		<amount>1.00</amount>
		<currency>PLN</currency>
		<title>9IMYEH2AV3  - weryfikacja rachunku</title>
		<remoteID>9IMYEH2AV3</remoteID>
		<bankHref>https://ssl.bsk.com.pl/bskonl/login.html</bankHref>
		<hash> fe685d5e1ce904d059eb9b7532f9e06a64c34c1ea9fcf29b62afefdb7aad7b75 </hash>
	</transaction>

Lista de parámetros devueltos para la respuesta

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

NOTAS: Utiliza la información anterior para mostrar los datos de la transferencia
y redirige al usuario a la página de inicio de sesión del banco.

BLIK 0 Pago con un clic

Descripción de los pagos BLIK 0 OneClick

Es una solución dedicada a los pagos BLIK, que permite realizar un pago sin introducir un código BLIK (y sin tener que abandonar el sitio web). Su iniciación con éxito en el Sistema desencadena el lanzamiento/despertar automático de la aplicación móvil del banco y la presentación de la transacción al Usuario para su confirmación.

Beneficios potenciales:

• La provisión del primer método de pago cómodo y seguro en mCommerce que no requiere un número de tarjeta abre este segmento a nuevos clientes,

• una mejor experiencia de compra para el cliente: paga más rápido y con mayor comodidad,

• Frecuencia de compra y valor de vida del cliente - Los clientes están más dispuestos y es más probable que compren en aquellas tiendas en las que el proceso de compra es más cómodo,

• Tasa de conversión - el servicio tiene un mayor control sobre el proceso de compra y pago (el cliente no lo abandona), se elimina el riesgo de pérdida de la cesta,

• decisión rápida de la transacción - en poco tiempo la transacción está sujeta a
  autorización, denegación o cancelación,

• El servicio tiene la opción de cubrir el análisis de la propia etapa de hacer
  pagos.

Un requisito previo para hacer BLIK 0 OneClick disponible para el Cliente es la autorización en el Servicio (tener una cuenta y haber iniciado sesión previamente en él). Si, durante un pago BLIK previamente realizado, junto con otra
información de pago, el Servicio ha enviado un UID Alias dedicado (descripción de parámetros. BlikUIDKey y BlikUIDLabel en otra parte del documento
), y el cliente, al confirmar el pago en la aplicación móvil
, indicó que quería recordar la tienda, esto tuvo el efecto de vincular permanentemente (normalmente durante un período de 2 años) al Cliente del Servicio a su aplicación, es decir, registrar el UID Alias. Su uso posterior dará lugar a
la autorización de la transacción sin el código.

Llamar a pagos BLIK 0 OneClick

Se recomienda no forzar el código BLIK al seleccionar un Canal de Pago BLIK. En su lugar, merece la pena mostrar el hipervínculo "Quiero introducir el código BLIK" bajo el botón "Comprar y pagar" para permitir que el código se introduzca en el primer intento (en caso de que el Cliente quiera realizar un pago BLIK desde una aplicación móvil distinta de aquella en la que ha almacenado previamente el Servicio dado).

El servicio debe realizar una transacción previa, con especial atención a:

• especificando el parámetro GatewayID = 509 - indicación de canal de pago BLIK,

• indicación de parámetros BlikUIDKey y BlikUIDLabel - indicación del requerido en el BLIK 0 OneClick Alias UID (identificador de usuario
  ).

• especificando el parámetro AuthorizationCode - si el cliente ha introducido el código BLIK,

• especificando el parámetro BlikAMKey - si el cliente ha indicado la etiqueta de la aplicación móvil del banco de entre la lista presentada en el Servicio,

• manejo de posibles respuestas pre-transacción, incluyendo el manejo de "Respuesta - sin seguimiento" y errores específicos de BLIK 0 OneClick:

(a) un error en muchas de las aplicaciones móviles del banco (confirmation=NO CONFIRMADO y reason=ALIAS_NONUNICA) - mostrar la lista de etiquetas devuelta en la pretransacción de la lista de alias (pares clave + etiqueta contenidos en la estructura de la etiqueta BlikAMList), para recuperar la clave seleccionada e introducirla en el parámetro BlikAMKey otro intento de pre-transacción

(b) errores de autorización (confirmation=NO CONFIRMADO y motivo de uno de los valores: ALIAS_RECHAZADO, ALIAS_NO_ENCONTRADO, BILLETE_ERRÓNEO, BILLETE_VENCIDO, BILLETE_UTILIZADO) - visualización del campo del código Blik, para descargarlo e introducirlo en el parámetro AuthorizationCode otro intento de pre-transacción

Transferencias a la Agencia Tributaria

Descripción

El sistema permite realizar transferencias a la Agencia Tributaria.

Validación de títulos de transferencias a la Agencia Tributaria

nombre del validador: US_TITLE_VALIDATOR

Title="/TI/______________/OKR/______/SFP/_______/TXT/_________{idtransremote_out}", gdzie:

(a) TI: significa Identificador del Contribuyente (P para PESEL o N para NIP o R para REGON). Afecta a:

• Y en NRB (0/1)
• X en NRB, que es un PESEL o NIP.

(b) OKR: Año, tipo de período y número del período por el que se paga el impuesto

• R - año en formato de dos dígitos
• P - semestre
• K - trimestre
• M - mes
• D - década
• J - día
• 0 (cero) - para créditos no relacionados con el ejercicio contable

Número de período:

• los caracteres R 4-7 no deben rellenarse
• para P caracteres 4-5 = 01 o 02, caracteres 6-7 no rellenados
• para K caracteres 4-5 = 01,02,03 o 04, caracteres 6-7 no rellenados
• para M caracteres 4-5 = 01 a 12, caracteres 6-7 no rellenados
• para D caracteres 4-5 = 01,02 o 03, caracteres 6-7 = 01 a 12
• para J caracteres 4-5 = 01 a 31, caracteres 6-7 = 01 a 12

(c) SPP: símbolo del formulario de pago:

d) TXT: texto adicional (máx. 29 caracteres)

e) {idtransremote_out} → constante de título, que debe estar al final de la cadena. No se deben pegar valores adicionales en este lugar.

Google Pay

Descripción

Google Pay es un sistema de pago instantáneo e intuitivo de Google. Permite al usuario completar el proceso de pago sin rellenar un formulario de tarjeta, ya que los datos de la tarjeta se almacenan de forma segura en los servidores de la empresa.

Google Pay es un producto que permite obtener datos encriptados
de la tarjeta de pago de un cliente permitiendo su cargo en cuenta.

Para pagar a través de Google Pay, es necesario guardar su
tarjeta de pago en su cuenta de Google, utilizando cualquier
plataforma de Google (por ejemplo, comprando apps en Google Play) o directamente en la página web de Google Pay.

NOTAS: El servicio requiere la firma previa de un acuerdo con el operador de la tarjeta
. Para más detalles, póngase en contacto con el
Departamento Comercial de Autopay.

Sistema de comunicación

Después de hacer clic en "Pagar con Google Pay", aparece un
formulario de Google Pay en la página de la tienda. En él, el cliente confirma su cuenta de Google y la tarjeta con la que pretende pagar (en esta fase, también puede cambiar la tarjeta por otra diferente o añadir una nueva). El script transmite los datos codificados de la tarjeta en el fondo de a través de la función postMessageentonces la tienda tiene que aceptarlos y codificarlos mediante la función base64 y finalmente enviarlos en el parámetro PaymentToken junto con otros parámetros (datos de la transacción).

En su sitio web, la tienda debe llamar a la secuencia de comandos proporcionada por Google con sustituido los datos del procesador de pagos.

TIP: Detalles en Documentación para desarrolladores de Google.

Esquema detallado de comunicación e intercambio de datos

Registro de transacciones de Google Pay

1. La tienda en su sitio debe enviar una solicitud al sistema de pago en línea AP, para recuperar los datos necesarios para procesar Google Pay (paybmApiResponse).

TIP: Un ejemplo de cómo enviar una solicitud está disponible en Pago automático de GitHub.

2. A continuación, la tienda debe llamar a la secuencia de comandos proporcionada en el archivo Partes del tutorial de documentación para desarrolladores de Googleque contiene:

(a) Modificación de los datos del procesador de pagos:

const tokenizationSpecification = {
	type: 'PAYMENT_GATEWAY',
	parameters: {
		'gateway': 'bluemedia',
		'gatewayMerchantId': paybmApiResponse.acceptorId
	}
};

b) Datos devueltos por el sistema de pago en línea AP transferidos en la instalación PaymentDataRequest.merchantInfo:

PaymentDataRequest.merchantInfo = {
	merchantId: paybmApiResponse.merchantId,
	merchantOrigin: paybmApiResponse.merchantOrigin,
	merchantName: paybmApiResponse.merchantName,
	authJwt: paybmApiResponse.authJwt,
};

3. Después de hacer clic en "Pagar con Google Pay", aparece un
   formulario de Google Pay en la página de la tienda. En él, el cliente confirma su cuenta de Google y la tarjeta con la que pretende pagar (en esta fase, también puede cambiar la tarjeta por otra diferente o añadir una nueva). Un script en segundo plano pasa los datos codificados de la tarjeta, que la tienda debe aceptar y luego codificar con la función Base64 y enviar en el parámetro PaymentToken junto con los demás parámetros de inicio de la operación (es decir, los datos de la operación del sistema de pago en línea AP - los detalles se describen en la parte de la sección Iniciar una transacción con parámetros adicionales).

TIP: Un ejemplo completo de integración con Google Pay está disponible en Pago automático de GitHub.

Información complementaria

Para mantener la integridad estética del diseño utilizado en el sitio web y la aplicación móvil de
, utilice la orientación que proporciona en la sección partes de la documentación para desarrolladores de las Directrices de marca Google para descripciones de estilo y botones de páginas web, y para partes Tutorial de documentación para desarrolladores Google., donde encontrará la información que necesita para desarrollar una
aplicación móvil.

Apple Pay

Implementación de Apple Pay en el sitio web de la tienda.

Solicitud para ponerse en contacto con el producto de infraestructura de pagos: se necesita apoyo informático.

1. Creación de una cuenta por el Socio y obtención de un certificado de procesamiento de pagos de conformidad con el documento Configurar Apple Pay (iOS, watchOS)

- certificado de comunicación - para la llamada presentación -identificador de comerciante

- certificado de débito - certificado de procesamiento de pagos

2. Implantación de la web de acuerdo con documento Apple Pay en la Web

3. Preparación de 2 puntos finales por parte del socio, en un dominio registrado con Apple (utilizando 2 certificados de Apple):

- hasta el inicio de la sesión

- cobrar al cliente en función del token de Apple

CONSEJO: safari (el navegador del cliente) se comunica con el endpoint de retorno de sesión (mencionado anteriormente), tras lo cual Apple se consulta a sí mismo la sesión de Autopay.

4. Procesamiento de Apple Pay

• Como parte de su registro de servicios con Apple, genere su certificado identidad comercial.
• Generar un certificado procesamiento de pagos basado en el certificado proporcionado por AP CSR

NOTA: Los certificados CSR de AP para aceptación y para producción difieren).

• Después de utilizarlo en el proceso de registro de Apple, proporcione al PA un certificado firmado por Apple y envíelo a través de Formulario de autopago

  CONSEJO: El cliente debe facilitar el país, la ciudad, el dominio del sitio web y el correo electrónico de la persona de contacto.

• Como parte del procesamiento de pagos en el sitio del socio, inicie una sesión API de Apple.

• A continuación, devuelva el token Autopay en el parámetro PaymentToken start.

NOTA: El descifrado del token es responsabilidad del PA.

Formato del token de pago: una porción de un objeto en formato json que devuelve la api de ApplePay:

  EncryptedPaymentData {
	  String version;
	  String data;
	  String signature;
	  Header header;
  }
  Header {
	  String ephemeralPublicKey;
	  String publicKeyHash;
	  String transactionId;
	  String applicationData;
  }
  

NOTA: Al enviar una solicitud ApplePayPaymentRequest, debe rellenar el campo applicationData con el valor orderId codificado en Base64, como se describe en la sección documento applicationData.

Widget de pago automático (modelo Marca Blanca)

Los afiliados que deseen incrustar algunos de los inicios de transacción directamente en su sitio / en su carrito de compras (en el llamado modelo WhiteLabel) pueden hacerlo mediante la integración de la Autopay Widget. Actualmente, el Widget Autopay soporta la recogida de datos de la tarjeta (dentro del PaywayId 1500/1503) y Visa Mobile comienza (PaywayId 1523)

IMPORTANTE El Socio no tiene derecho a almacenar los datos de la Tarjeta (en particular, número de tarjeta, código de seguridad CVC, CVV2), con la excepción de los parámetros transmitidos al procesar pagos automáticos por AP, como se describe en esta sección.

IMPORTANTE El sitio web del socio en el que se utilice la funcionalidad del widget Autopay debe estar cifrado y el IFRAME HTML con el widget debe estar incrustado en una dirección HTTPS con utilizando el protocolo TLS.

IMPORTANTE El socio se compromete a presentar a AP, en formato electrónico, los siguientes documentos:
(a) de una sola vez (antes de la celebración del Contrato): un cuestionario SAQ-A PCI cumplimentado (Sección 2); El documento será proporcionado por AP o está disponible para su descarga en el sitio web: https://www.pcisecuritystandards.org
b) Trimestralmente: el resultado de la auditoría trimestral PCI ASV, incluido un escaneado de direcciones/redes/dominios IP externos (públicos) - IPv4 y/o IPv6. Dicha auditoría deberá ser realizada por uno de los contratistas autorizados que figuran en: https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors

WidgetJS SDK de autopago

Usted tendrá que utilizar el Autopay WidgetJS SDK para incrustar y comunicarse con el widget de Autopay. En resumen, todo se reducirá a incrustar el HTML IFRAME con el widget y configurar el JS SDK para manejar los mensajes (eventos) producidos cuando el Titular de la tarjeta interactúa con el widget. El mensaje final es un evento con estado ÉXITO_DEL_FORMULARIO incluyendo paymentToken necesario para el inicio backend de las transacciones en la API del sistema de pago en línea AP.

Incorporación del SDK

A continuación se muestran ejemplos de cómo incrustar y sindicar fácilmente un widget, utilizando el SDK Autopay WidgetJS, tanto para los canales de tarjeta como para VisaMobile.

El SDK de Autopay WidgetJS está disponible en widget-nuevo/widget-comunicacion.min.js una vez colocado en el <head>

<script src="?r=quot;https://testcards.autopay.eu/widget-new/widget-communication.min.js"></script>

accedemos al objeto WidgetConnection

var widgetConfigObject = { ... };
var widget = new WidgetConnection(widgetConfigObject)

que, cuando se complementa con una configuración en forma de objeto JSON, permitirá la comunicación completa con la API de Autopay y, como resultado, garantizará que reciba un evento con un estado de ÉXITO_DEL_FORMULARIO z paymentToken.

Ejemplos de configuraciones

Ejemplo de configuración de los datos de la tarjeta

Configuración:

{ language: 'pl', amount: 1.23, currency: 'PLN', serviceId: 123456 }

PaymentToken devuelto:

{status: 'FORM_SUCCESS', message: 'ey...9', id: 'OGFlZTYyYTMtN2U2OS00MTU1LTgyNDctNmMwMGI2NjE5ZDQy'}

Ejemplo de configuración para datos VisaMobile

Configuración:

{ language: 'pl', amount: 1.23, currency: 'PLN', serviceId: 123456, merchantName: 'ShopName' }

PaymentToken devuelto:

{status: 'FORM_SUCCESS', message: 'ey...9', prefix: '48', phoneNumber: '666666666', id: 'OGFlZTYyYTMtN2U2OS00MTU1LTgyNDctNmMwMGI2NjE5ZDQy'}

Discusión detallada de la configuración del objeto WidgetConnection

Idioma

Determina la versión de idioma en la que se presentará el widget.

Nombre del campo: idioma Formato cadena Valores: por defecto enActualmente se admiten los siguientes idiomas: cs, de, el, en, es, fr, hr, hu, it, en, ro, Se, sk, sl, uk

Importe de la transacción

Importe de la transacción

Nombre del campo: importe Formato float Valores: una cantidad escrita en formato flotante, por ejemplo "PLN 1,23" es 1.23

importe: 1,23, divisa: "PLN", serviceId: 123456, merchantName: "ShopName".

Moneda de transacción

Moneda de la transacción

Nombre del campo: divisa Formato cadena Valores: por defecto PLNotras divisas en un formato compatible con la configuración actual del servicio

Número de servicio

Número de servicio recibido de Autopay (depende del entorno de desarrollo)

Nombre del campo: serviceId Formato entero Valores: normalmente seis dígitos

Tipo de recurrencia (sólo para tarjetas)

Indicación del tipo de inicio de la recidiva (Sólo para el canal 1503 relacionado con el inicio de la recidiva)

Nombre del campo: recurringAction Formato cadena Valores: 'INIT_WITH_REFUND', 'INIT_WITH_PAYMENT'

Nombre de la tienda (sólo para VisaMobile)

Nombre que se muestra al usuario en la notificación de VisaMobile en la aplicación móvil del banco
(Solo para el canal 1523 de VisaMobile).

Nombre del campo: merchantName Formato cadena Valores: Nombre de la tienda

Widget de tarjeta - Ejemplo de aplicación en un sitio web asociado

IMPORTANTE El siguiente ejemplo de código HTML fue creado con fines ilustrativos. Con el fin de realmente ejecutarlo en su equipo local, el siguiente archivo HTML debe ser colocado bajo algún dominio local (cualquiera, puede ser prueba.local). Este HTML no se puede disparar en el navegador como un archivo local porque los eventosJS intercambiados entre IFRAME y la página se verifican para la consistencia de dominio (y por lo tanto algún dominio debe estar presente).

La siguiente página pretende imitar a Front Merchant, mostrando qué elementos necesitan ser implementados para integrarse con el Widget Autopay.

En el navegador, la siguiente página de ejemplo consta de tres secciones:

• la sección superior contiene una selección de canales de pago específicos
• la sección central contiene el lugar donde se incrustará el IFRAME HTML, en el que se colocará la dirección del widget (visamobile o tarjeta estándar si es necesario)
• la sección inferior contiene un botón (inactivo por defecto) PayButon incluido con el SDK de JS para controlar el inicio del proceso en el widget (en este ejemplo, el botón sólo se activa cuando recibe un mensaje de que la validación es correcta y se han completado los datos necesarios para iniciar el proceso)

Cuando se selecciona un canal de tarjeta (payway: 1500 o 1503), se cargará una vista de formato de tarjeta dedicado (basado en HTML IFRAME). Cuando se introduzcan datos completos y válidos de la tarjeta en el widget, (gracias a los eventos de validación) se activará el botón "Pagar" en el front-end del Comerciante.

Pista: Como puede ver en el ejemplo, también es posible soportar el canal VisaMobile en el modelo WhiteLabel. La implementación/disposición es análoga a la del widget de tarjeta, por lo que el código siguiente ya contiene ambos casos.

Validación y cumplimentación de datos

El SDK JS recibe eventos del widget cuando se entra en el Widget Autopay. ESTADO_VALIDEZ con valor válido: false

Una vez que tengamos los datos completos de la tarjeta, el último evento será ESTADO_VALIDEZ con un valor de válido: true

{status: 'VALIDITY_STATUS', message: null, valid: true, id: 'M2Zl...mU2'}

La activación del botón puede basarse en este evento PayButton

Pista: En el entorno de pruebas, los pagos con tarjeta se basan en un simulacro de 3ds y un simulacro de autorización. Los números de las tarjetas de prueba corresponden a los distintos escenarios. La lista completa de casos de prueba figura en un apéndice aparte.

Pantalla DCC

Si el escenario y la tarjeta cumplen las condiciones para obtener una oferta DCC, aparecerá una pantalla adicional con una propuesta de conversión de divisas para el Titular de la Tarjeta

El titular de la tarjeta puede optar por utilizar el débito de la tarjeta en su moneda nativa o dejar la moneda original. La validación también se produce en esta pantalla.

La selección de la moneda del titular de la tarjeta no afectará el comerciante y el importe original de la transacción en sí, sino que afectará a la cantidad que se cargará la tarjeta. Si el Titular de la Tarjeta no desea utilizar la oferta de conversión de divisas DCC, selecciona la divisa original (es decir, en este caso PLN).

Obtener una ficha

El botón debe estar vinculado al SDK JS del widget de pago automático para que al hacer clic en él se active una llamada al método widget.sendForm(); en las instalaciones WidgetConnection Que en última instancia dará lugar a un evento ÉXITO_DEL_FORMULARIOes decir, obtener el valor del paymentToken (en el campo mensaje).

{status: 'FORM_SUCCESS', message: 'eyJ...n19', id: 'M2Z...ZmU2'}

Card Widget - Esquema detallado de comunicación e intercambio de datos

A continuación se muestra un diagrama detallado de la comunicación entre el comerciante, el titular de la tarjeta y los sistemas de pago Autopay en el caso de la denominada integración WhiteLabel (es decir, utilizando un widget de tarjeta)

Transferencia segura de los datos de la tarjeta al sistema Autopay y flujo completo de transacciones:

• (0) Reenvío al front-end de los datos de configuración que inician la incrustación del widget
• (1) Visualización del formato de tarjeta del widget incrustado en el frontend del comerciante (los datos de la tarjeta no se proporcionan en el frontend del comerciante, sino en el frontend del widget Autopay)
• (2) El titular introduce los datos de la tarjeta
• (3) Transmisión de los datos de la tarjeta utilizando una conexión TLS asegurada con un certificado de Validación Extendida al backend de CardsAutopay ** Se aplica sólo si es posible proponer DCC ** ** (3a) Devolución de los detalles de la propuesta de conversión de moneda DCC ** (3b) El Titular de la tarjeta toma una decisión, si desea utilizar DCC ** (3c) Transmisión de los datos de la tarjeta introducidos previamente por el Titular y la decisión DCC sigue.
• (4) WidgetJS recibe de CardsAutopay y envía a la interfaz del comerciante (a través de JS) el valor del campo paymentToken
• (5) El frente comercial recibe el token de pago del widget a través de un evento JavaScript.
• (6) El Merchant Front transfiere el token de pago al Merchant Backend.
• (7) Inicio del backend Pre-transacción con paymentToken recibido previamente del frente
• (8) Autopay API devuelve la URL la continuación de la transacción que se utilizará para redirigir al inicio de la transacción con el usuario
• (9) El backend del comerciante pasa una URL de redirección al frontend del comerciante.
• (10) Redireccionamiento del titular de la tarjeta desde el sitio web del comerciante a PayAutopay para la autenticación 3DS
• Se lleva a cabo la verificación 3DS (dependiendo de la decisión del banco, puede ser una verificación completa o simplificada).
• (11) Cuando el Titular de la Tarjeta "regresa" de la 3DS, el resultado de la autenticación se completa/recoge y autoriza
• (12) Autopago recibe un resultado de débito
• (13) El estado de la transacción se comunica al sistema de pago en línea (en segundo plano)
• (14) El titular de la tarjeta es redirigido desde el sitio web de PayAutopay (tras la autenticación 3DS) de vuelta al sitio web del comerciante
• (15) Asíncronamente al backend del Comerciante llega el mensaje ITN con el estado de la transacción
  ** ( en el caso de una transacción que inicia una recurrencia, el backend de Merchant también recibe un mensaje adicional RPAN )

Widget Visa Mobile - Ejemplo de aplicación en un sitio web asociado

A continuación se muestra un ejemplo de una sencilla implementación HTML/JS utilizando el widget VisaMobile (y el widget de tarjeta)

{ 'status': 'FORM_SUCCESS', 'message': 'eyJrZ...', ... }

Para esta integración es crucial el lugar en el código JS que se encarga de recibir eventos, en particular el evento de estado ÉXITO_DEL_FORMULARIOcomo contiene en el campo mensaje el valor de paymentToken que el comerciante debe pasar a su backend para completar los parámetros de la API de Autopay y permitir que el pago se inicie en Autopay.

Página de ejemplo

En el navegador, la siguiente página de ejemplo consta de tres secciones:

• la sección superior contiene iconos/botones para canales de pago específicos (utilizando representaciones gráficas de Autopay)
• la sección central contiene el lugar donde se coloca el IFRAME HTML, en el que se insertará la dirección del widget (visamobile o tarjeta estándar, según sea necesario)
• la sección inferior contiene un botón (inactivo por defecto) PayButon incluido con el SDK de JS para controlar el inicio del proceso en el widget (en este ejemplo, el botón sólo se activa cuando recibe un mensaje de que la validación es correcta y se han completado los datos necesarios para iniciar el proceso)

Cuando se selecciona un canal dedicado a VisaMobile, se muestra una vista dedicada (basada en HTML IFRAME), en la que la introducción del número de teléfono completo (gracias a los mensajes de validación) da lugar a la activación del botón "Pagar".

Validación y cumplimentación de datos

Al introducir un número de teléfono, Autopay Widget JS SDK recibe eventos del widget ESTADO_VALIDEZ con valor válido: false Una vez que tengamos el número de teléfono completo, el último evento será ESTADO_VALIDEZ con un valor de válido: true

{status: 'VALIDITY_STATUS', message: null, valid: true, id: 'M2Zl...mU2'}

La activación del botón puede basarse en este evento PayButton

Obtener una ficha

El botón debe estar vinculado al SDK JS del widget de pago automático para que al hacer clic en él se active una llamada al método widget.sendForm(); en las instalaciones WidgetConnection Que en última instancia dará lugar a un evento ÉXITO_DEL_FORMULARIOes decir, obtener el valor del paymentToken.

{status: 'FORM_SUCCESS', message: 'eyJ...n19', prefix: '48', phoneNumber: '666666666', id: 'M2Z...ZmU2'}

Widget Visa Mobile - Esquema detallado de comunicación e intercambio de datos

Inicio de la transacción:

• (1) Comience introduciendo su número de teléfono en el widget VisaMobile
• (2) Lanzamiento de transacciones VisaMobile
• (3) Reembolso de VisaMobile
• (4) Volver del widget a Comerciante (usando JS) el generado paymentToken
• (5) El Merchant Front transfiere el token de pago al Merchant Backend.
• (6) Inicio del backend Pre-transacción con paymentToken el paymentToken recibido anteriormente
• (7) La devolución recibe inmediatamente una respuesta XML PENDIENTE (porque se procesa en segundo plano)
• (8) En el anverso Merchant, se presenta la pantalla de espera de resultados

Posible cancelación de la transacción (desde el paywall de PayAutopay ):

• (9 bis) Si el usuario no recibe la notificación en la aplicación móvil o cambia de opinión, tiene la opción de cancelar la transacción desde el muro de pago.
• (9b) Se envía una solicitud de cancelación desde el sistema CardsAutopay a Visa
• (9c) El sistema CardsAutopay recibe un resultado de cancelación de Visa
• (9d) El resultado de la cancelación es aceptado por el sistema PayAutopay y presentado al usuario en el paywall de PayAutopay.
• (9e) Se envía un paralelo ITN (con estado negativo) a Comerciante

Carga y devuelve el resultado:

• (10) Esperar los datos del token de pago de Visa (si un cliente de VisaMobile confirma en la aplicación móvil que desea pagar con una tarjeta específica para un pedido determinado)
• (11) Sigue una orden de adeudo
• (12) Recibimos un resultado de carga positivo o negativo
• (13) El estado de la transacción se envía a la pasarela PayAutopay
• (14) La pasarela Autopay envía el resultado de la transacción al Comerciante en forma de un ITN

Discusión del código HTML JS de ejemplo (Widget de tarjeta y VisaMobile)

El siguiente código se utilizó para generar las integraciones de ejemplo mencionadas anteriormente en las secciones con ejemplos de la implementación del widget de tarjeta, así como del widget Visa Mobile

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Autopay Widget Integration Example</title>
    <script src="?r=quot;https://testcards.autopay.eu/widget-new/widget-communication.min.js"></script>
    <style>/* pominięte w przykladzie */</style>
</head>
<body>
<div>
  <form onsubmit="submitForm(event)" novalidate>
   <div class="form-group"><p>Transaction amount:</p><span>1,23 PLN</span></div>

    <!-- przykładowa implementacja mechanizmu wyboru kanału płatności po stronie merchanta -->
    <p>Choose payment method:</p>
    <ul>
      <li onclick="setPayway(event, 1500)">One time payment with card</li>
      <li onclick="setPayway(event, 1503)">Remember your card</li>
      <li onclick="setPayway(event, 1523)">Pay with VisaMobile</li>
    </ul>

    <!-- miejsce, w które wstrzyknięty zostanie HTML IFRAME z widget"em -->
    <div class="form-group" id="iframe-wrapper">
      <iframe id="iframe"></iframe>
    </div>

    <!-- przycisk wywołujący akcję w widget'cie -->
    <button type="submit" id="button" disabled="disabled">PayButton</button>
  </form>
</div>
<script type="text/javascript">
window.addEventListener('load', () => {
    // pomocnicze zmienne (tylko na potrzeby przykładu)
    var currentPayway = null;
    var widget = null;

    // przykładowe konfiguracje zależne od środowiska devloperskiego (tylko na potrzeby przykładu)
	var AUTOPAY_CARDS_DOMAIN_ENV_PROD = 'https://cards.autopay.eu';
	var AUTOPAY_CARDS_DOMAIN_ENV_TEST = 'https://testcards.autopay.eu';

	var MERCHANTS_SERVICE_ID_ENV_PROD = 903555;
	var MERCHANTS_SERVICE_ID_ENV_TEST = 903555;

    // pomocnicza metoda obsługująca wybór kanału płatności i osadzenie widget'u
    function setPayway (event, paywayId) {
        if (currentPayway === paywayId) {
            return;
        }
        currentPayway = paywayId
        removeWidget();
        disableSubmitButton();
        markActiveIcon(event);

        if (paywayId === 1500) {
            startWidget('/widget-new/partner'   , { language: 'en', amount: 1.23, currency: 'PLN', serviceId: MERCHANTS_SERVICE_ID_ENV_TEST });
            return
        }
        if (paywayId === 1503) {
            startWidget('/widget-new/partner'   , { language: 'en', amount: 1.23, currency: 'PLN', serviceId: MERCHANTS_SERVICE_ID_ENV_TEST, recurringAction: 'INIT_WITH_REFUND' });
            return
        }
        if (paywayId === 1523) {
            startWidget('/widget-new/visamobile', { language: 'en', amount: 1.23, currency: 'PLN', serviceId: MERCHANTS_SERVICE_ID_ENV_TEST,  merchantName: 'ShopName' });
			return
        }
    }

    // pomocnicza metoda (tylko na potrzeby przykładu) ustawiająca obramowanie na wybranym kanale płatności
    function markActiveIcon (event) {
        var currentActive = document.querySelector('ul li.active');
        if (currentActive) {
            currentActive.classList.remove('active');
        }
        var newActive = event.target;
        if (newActive.nodeName.toLowerCase() === 'img') {
            newActive = newActive.parentNode;
        }
        newActive.classList.add('active');
    }

    // główna metoda odpowiadająca za osadzenie IFRAME z widget'em i zestawienia komunikacji między nim a jego obiektowym reprezentantem WidgetConnection
    function startWidget (widgetVariantUrl, widgetConfig) {
        if (!widgetEvents || !WidgetConnection) {
            return;
        }
        var iframeEl = document.getElementById('iframe');
        iframeEl.src = AUTOPAY_CARDS_DOMAIN_ENV_TEST + widgetVariantUrl;
        widget = new WidgetConnection(widgetConfig)

        widget.startConnection(iframeEl).then(() => {

            // obsłużenie głównego, finalnego event'u zawierającego wartość PaymentToken'a
            widget.on(widgetEvents.formSuccess, function (message, eventData) {
                console.log('payment token event =>', eventData);
                console.log('payment token value:', message);
                // w tym miejscu powinno być wywołanie API merchanta, aby przekazać paymentToken (message) do backend'u merchanta;    <<<<<<<<<<<<<<<<<
            })

            // obsłużenie event'ów związanych z walidacją podczas wprowadzania danych w widget'cie przez użytkownika/cardholder'a
            widget.on(widgetEvents.validityStatus, function (message, eventData) {
                console.log('form validation status =>', eventData);
                if (eventData.valid) {
                    enableSubmitButton();
                } else {
                    disableSubmitButton();
                }
            })

            // obsłużenie event'u związanego z walidacją w momencie wprowadzania danych w widget'cie przez użytkownika/cardholder'a
            widget.on(widgetEvents.validationResult, function (message, eventData) {
                console.log('form validation result =>', eventData);
                if (eventData.valid) {
                    enableSubmitButton();
                } else {
                    disableSubmitButton();
                }
            })

            // obsłużenie event'u showModal
            widget.on(widgetEvents.showModal, function () {
                console.log('show modal');
            })
        })
    }

    // pomocnicza metoda (tylko na potrzeby przykładu) ustawiająca usuwanie widget'u dla innych, niż kartowe, kanałów płatnosći (w przykladzie jest kanał 106 PBL)
    function removeWidget () {
        if (!widget) {
            return;
        }
        widget.stopConnection();
    }

    // pomocnicza metoda (tylko na potrzeby przykładu)
    function enableSubmitButton () {
        document.getElementById('button').removeAttribute('disabled');
    }

    // pomocnicza metoda (tylko na potrzeby przykładu)
    function disableSubmitButton () {
        document.getElementById('button').setAttribute('disabled', 'disabled');
    }

    // pomocnicza metoda (tylko na potrzeby przykładu) powiązująca naćiśnięcie aktywnego przycisku zapłać z wywołaniem sendForm() w obiekcie widget'u
    function submitForm (event) {
        event.preventDefault();
        if (!widget || widget.invalid) {
            return;
        }
        disableSubmitButton();
        widget.sendForm();
    }

    window.setPayway = setPayway;
    window.submitForm = submitForm
});
</script>
</body>
</html>

Pago con tarjeta integrado en el servicio (iFrame)

El iFrame de tarjeta (PayBmCheckout) ya no es compatible, en su lugar, para el pago con tarjeta incrustado en el sitio del Socio, utilice Widget de tarjeta.

Pago automático

Descripción del pago automático

Los pagos automáticos son una forma extremadamente cómoda y segura de realizar transacciones recurrentes. Consiste en la recogida automática de las cuentas por cobrar del cliente en sus fechas de pago. El servicio debe activarse primero. En el caso de las tarjetas, esto se hace por redirigir al cliente al formulario de activación del servicio. En el caso de BLIK
, en cambio, mediante la aceptación de un pago automático en la Aplicación Móvil. Una vez que dicha transacción de activación ha sido autorizada con éxito, el
AP transmite al Partner un mensaje estándar de
cambio de estado de la transacción (ITN) y un
mensaje de activación del servicio de pago automático (RPAN). El mensaje RPAN contiene el campo clientHashque el Socio identificará el pago automático específico durante los débitos posteriores y la desactivación del servicio.

Todas las transacciones dentro del ciclo de vida de un pago automatizado
(activación y adeudos) se procesan dentro de Canales de Pago
dedicados (BLIK -. GatewayID=522, Tarjetas - GatewayID = 1503) o gatewayType="Pago automático".. Al integrar pagos automáticos BLIK, es posible especificar (en los datos facilitados antes de la integración) la vida útil de los pagos automáticos activados (ilimitada por defecto) o especificarla en la transacción de inicialización (parámetro RecurringValidityTime).

Activación del pago automático

La activación del pago automático consiste en la autorización de transacción de activación, comunicación ITN y RPAN. Tras la recepción de la RPAN, el socio está listo para realizar débitos recurrentes (o un clic).

Se trata de activar el servicio de pago automático durante
el pago de un servicio/bien (así RecurringAction=INIT_WITH_PAYMENT y liquidación de la operación al Socio).

Proceso de activación del servicio de pago automático

El mensaje ITN enviado tras un pago automático es similar a los recibidos tras pagos puntuales (sólo se amplía con el nodo
RecurringDatay - para los pagos con tarjeta - CardData). Los otros dos elementos del proceso de activación del servicio son el inicio de la transacción y RPAN.

Mensaje automático de inicio de transacción

El proceso de activación del servicio se inicia desde el Sitio Asociado mediante el inicio de la transacción con el parámetro RecurringAction permite controlar el comportamiento
del Sistema:

(a) el valor de INIT_CON_PAGO - corresponde a la activación del servicio de pago automático al pagar un servicio/bien (la tarjeta o cuenta se carga con el importe adeudado y los fondos del pago se transfieren al Socio); en la lista de canales de pago disponibles, el sistema presenta únicamente pagos automáticos (a menos que se haya seleccionado un canal de pago en el Servicio),

(b) el valor de INIT_WITH_REFUND - corresponde a la activación del servicio de pago automático fuera del proceso de pago del servicio/mercancía (la tarjeta o cuenta se carga con el importe de 1 PLN, seguido de devolución automática de fondos a la cuenta del Cliente); en la lista de canales de pago disponibles, el Sistema presenta únicamente pagos automáticos (si no se ha seleccionado ningún canal de pago en el Sitio web),

(c) el valor de INIT_SIN_PAGO - corresponde a la activación del servicio de pago automático fuera del proceso de pago del servicio/bien; Valor admitido únicamente en el modelo de Marca Blanca, para el método BLIK. El importe inicial de este valor es 0,00.

d) sin parámetro (o vacío) - a menos que se haya seleccionado un canal de pago en el Servicio, el Sistema mostrará todos los canales de pago disponibles para el Servicio (incluidos los automáticos) y dejará que el Cliente decida: pago único o iniciar un pago automático. Si el Cliente elige el pago automático, la transacción se facturará al Socio de la forma estándar (y el parámetro RecurringAction=INIT_WITH_PAYMENT volverá en RPAN).

NOTAS: No se permite iniciar transacciones de activación con el canal de pago automático seleccionado, pero sin la RecurringAction seleccionada.

En algunos casos (si se deduce de la respuesta del método legalData) RecurringAcceptanceState (con un valor de ACEPTADOlo que significa que el
Cliente ha leído y aceptado los términos y condiciones del pago automático en el
Sitio Asociado) y RecurringAcceptanceID.

La activación del servicio de tarjeta de pago automático se lleva a cabo en formatos proporcionados por AP. El cliente debe introducir
datos de la tarjeta: nombre, apellidos, número de tarjeta, fecha de caducidad y código CVV.

En el caso del pago automático desde una cuenta bancaria (BLIK), la autorización tiene lugar sin especificar los datos de la tarjeta: por ejemplo, con el código BLIK (transportado en los parámetros de inicio en AuthorisationCode), o a través de BLIK OneClick Alias (transportado en los parámetros de inicio en BlikUIDKey/BlikUIDLabel). Los pagos automáticos para el método BLIK se pueden iniciar en dos variantes:

1. Modelo M - con confirmación de cada pago por parte del cliente en la app móvil del banco (canal 522),
2. Modelo O - sin confirmación de pago en el banco (canal 524). En este modelo, la certificación de la Merchant Service de acuerdo con el procedimiento descrito en: https://blik.com/lp/reccuring-payments/BLIK-Recurring-Payments---Certification-Checklist.141951091.html

Una vez autorizada la transacción, el Sistema AP transmite al Servicio Asociado un mensaje de cambio de estado de la transacción (ITN) y un mensaje de activación automática del servicio de pago (RPAN). El mensaje RPAN está dedicado a eventos de activación de pagos automáticos y contiene su identificador (ClientHash), que el Socio utilizará durante posteriores adeudos y desactivación del servicio. El RPAN también contiene información de acción para el proceso de pago automático (RecurringAction, descrito anteriormente).

Notificación del lanzamiento de un pago automático (RPAN)

Tras la recepción de un estado de pago positivo para la activación del pago automático, se envía un mensaje dedicado al Servicio. Esta notificación consiste en el envío por parte del Sistema AP de un documento XML que contiene datos sobre el pago automático activado. El documento se envía a través del protocolo HTTPS (puerto 443 por defecto), a través del método POST, como un parámetro HTTP llamado recurring. Este parámetro se
almacena utilizando el mecanismo de codificación de transporte Base64.

Formato de documento (XML)

	<?xml version="1.0" encoding="UTF-8"?>
	<recurringActivation>
		<serviceID>ServiceID</serviceID>
		<transaction>
			<orderID>OrderID</orderID>
			<remoteID>RemoteID</remoteID>
			<amount>999999.99</amount>
			<currency>PLN</currency>
			<gatewayID>GatewayID</gatewayID>
			<paymentDate>YYYYMMDDhhmmss</paymentDate>
			<paymentStatus>PaymentStatus</paymentStatus>                 
			<paymentStatusDetails>PaymentStatusDetails</paymentStatusDetails>
			<startAmount>999998.99</startAmount>
			<invoiceNumber>InvoiceNumber</invoiceNumber>
			<customerNumber>CustomerNumber</customerNumber>
			<customerEmail>CustomerEmail</customerEmail>
			<customerPhone>CustomerPhone</customerPhone>
		</transaction>
		<recurringData>
			<recurringAction>RecurringAction</recurringAction>
			<clientHash>ClientHash</clientHash>
			<expirationDate>YYYYMMDDhhmmss</expirationDate>
		</recurringData>
		<cardData>
			<index>Index</index>
			<validityYear>ValidityYear</validityYear>
			<validityMonth>ValidityMonth</validityMonth>
			<issuer>Issuer</issuer>
			<bin>BIN</bin>
			<mask>Mask</mask>
		</cardData>
		<hash>Hash</hash>
	</recurringActivation>

Valores de los elementos: orderID, serviceID, importe relativos a cada uno de los pagos automáticos activados son idénticos a los valores de los campos correspondientes facilitados por el Servicio al iniciarse el respectivo pago de inicialización.

Descripción de los parámetros devueltos para activar el pago automático

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

TIP: Elemento hash (mensaje) se utiliza para autenticar la
del documento. El valor de este elemento se calcula como el valor de la función hash a partir de una cadena que contiene los valores concatenados de todos los campos del documento y la clave compartida adjunta. Para obtener una descripción de cómo se calcula el hash
, consulte la sección Seguridad de las transacciones.

Respuesta a la notificación

La respuesta de notificación espera un estado HTTP de 200 (OK) y
texto en formato XML (no codificado en Base64), devuelto por el
Partner Service en la misma sesión HTTP, que contenga un acuse de recibo del
mensaje.

Estructura de confirmación (XML)

	<?xml version="1.0" encoding="UTF-8"?>
	<confirmationList>
		<serviceID>ServiceID</serviceID>
		<recurringConfirmations>
			<recurringConfirmed>
				<clientHash>ClientHash</clientHash>
				<confirmation>Confirmation</confirmation>
			</recurringConfirmed>
		</recurringConfirmations>
		<hash>Hash</hash>
	</confirmationList>

Elemento de confirmación del pago automático

Elemento confirmación se utiliza para transmitir el estado de la verificación de la
autenticidad de la transacción por parte del Servicio Asociado. El valor del elemento se determina comprobando la corrección del valor del parámetro. serviceIDcomparación de los valores de los campos orderID i importe en el
mensaje de notificación y en el mensaje que inicia la transacción,
así como verificar que el hash calculado a partir de los
parámetros del mensaje coincide con el valor pasado en el campo hash del mensaje.

Se proporcionan dos valores para el elemento confirmación:

a) CONFIRMADO - los valores de los parámetros en ambos mensajes y el parámetro hash coinciden: la transacción es auténtica;

b) NO CONFIRMADO - los valores de los dos mensajes son diferentes o un hash no coincide - transacción no auténtica;

TIP: Elemento hash (en respuesta a un mensaje) se utiliza para autenticar la respuesta y se calcula a partir de los valores de los parámetros de respuesta. Para obtener una descripción de cómo se calcula el resumen, consulte la sección Seguridad de las transacciones.

Si no hay una respuesta correcta a las notificaciones enviadas, el sistema de pago en línea realizará otro intento de transmisión transcurrido un tiempo especificado. El servicio del socio debe realizar su propia lógica empresarial (por ejemplo, lanzar un servicio de pago automático, enviar correos, etc.) sólo después de que el primer mensaje de un determinado ClientHash.

Plan de reproducción de mensajes ITN/ISTN/IPN/RPAN/RPDN

A continuación se muestra un diagrama que describe la renovación programada de los mensajes (nos reservamos
, sin embargo, la posibilidad de renovar cualquiera de ellos en cualquier momento).

NOTAS: La repetición continua del mensaje idéntico
por parte del Sistema indica una falta de respuesta o una respuesta incorrecta al mismo por parte del Servicio, y requiere
por parte del Socio para el diagnóstico urgente de la causa.

Carga para pago automático

Recepción correcta del identificador de servicio (ClientHash), hace que el
Socio esté preparado para cobrar automáticamente al Cliente los
bienes/servicios adquiridos en el Servicio. El proceso consta de transacciones y comunicación ITN.

A continuación se muestra el proceso de cobro automático al cliente por el servicio/mercancía (así RecurringAction=MANUAL/AUTO y liquidación de la operación al Socio).

El mensaje ITN enviado tras un pago automático es similar a los recibidos tras pagos puntuales. Sólo se amplía con el nodo RecurringData y (para pagos con tarjeta) CardData.

Mensaje de inicio de operación de pago automatizada

Para realizar una carga automática, el Servicio Asociado debe realizar una Pre-transacción con el parámetro ClientHashcompatible con el servicio de pago automático
previamente activado (procedente del RPAN), con
parámetro RecurringAcceptanceState vale NOT_APPLICABLE y el valor correspondiente del parámetro RecurringAction:

a) AUTO - pago periódico (débito sin participación del cliente),

b) MANUAL - pago con un solo clic (débito ordenado por el cliente, denominado OneClick).

NOTAS: La participación del cliente en la opción MANUAL, suele limitarse a llamar a un mensaje (seleccionando en el Servicio la opción de pagar con la tarjeta
almacenada). En la gran mayoría de los casos, se requiere una autorización adicional en el banco (en forma de código 3DS o CVC). Entonces, en lugar de un
débito (y el estado del pedido en respuesta a una pretraducción), el
sistema devolverá un enlace para continuar - este es el comportamiento predeterminado del sistema en el
entorno de prueba. Con el fin de probar un escenario de carga sin necesidad de autorización adicional, se debe declarar la necesidad de cambiar la configuración del Sistema para la duración de la prueba.

NOTAS: Opción no disponible para los pagos automáticos BLIK (BLIK OneClick).

Desactivación del servicio

El interlocutor puede desactivar el servicio de pago automático en cualquier momento. El proceso puede consistir en un mensaje que ordene la desactivación del y un mensaje RPDN (dedicado a eventos de cancelación del servicio de pago automático).

También puede ocurrir que la cancelación del servicio se inicie por parte del PA (por ejemplo, a petición del cliente, banco u organización de tarjetas). En tal situación, el Sistema también entregará un mensaje RPDN.

Mensaje de desactivación del pago automático

El servicio puede desactivar el servicio a través de un mensaje dedicado. Todos los parámetros
se pasan a través del método POST (a la carpeta https://{host_gateway}/desactivar_recurrente). El protocolo distingue entre mayúsculas y minúsculas tanto en los nombres como en los valores de los parámetros. Los valores de los parámetros pasados deben estar codificados en UTF-8.

Lista de parámetros para desactivar el pago automático

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

NOTAS: El elemento Hash (mensaje) se utiliza para autenticar el documento. El valor de este elemento se calcula como el valor de una función hash a partir de una cadena que contiene los valores concatenados de todos los campos del documento y la clave compartida adjunta.

Respuesta

En respuesta a la notificación, se devuelve un texto con formato XML en la misma sesión HTTP
, que contiene un acuse de recibo.

Estructura de confirmación (XML)

	<?xml version="1.0" encoding="UTF-8"?>
	<confirmationList>
		<serviceID>ServiceID</serviceID>
		<messageID>MessageID</messageID>
		<recurringConfirmations>
			<recurringConfirmed>
				<clientHash>ClientHash</clientHash>
				<confirmation>Confirmation</confirmation>
				<reason>Reason</reason>
			</recurringConfirmed>
		</recurringConfirmations>
		<hash>Hash</hash>
	</confirmationList>

Confirmación de elementos

Elemento confirmación se utiliza para transmitir el estado de verificación de la autenticidad de la operación por parte del Servicio. El valor del elemento se determina comprobando la corrección de los valores de los parámetros. serviceID y clientHash con los especificados en el mensaje RPAN al inicio de un determinado pago de activación, así como verificar que el hash calculado a partir de los parámetros del mensaje coincide con el valor pasado en el campo Hash.

Se proporcionan dos valores para el elemento confirmación:

a) CONFIRMADO - valores de los parámetros son correctos y el parámetro Hash son consistentes - operación auténtica;

b) NO CONFIRMADO - valores en ambos mensajes son incorrectos o Hash mismatch - operación no auténtica;

NOTAS: El elemento hash (en el mensaje de respuesta) se utiliza para autenticar la respuesta y se calcula a partir del valor de los parámetros de respuesta. El valor de este elemento se calcula como el valor de una función hash a partir de una cadena que contiene los valores concatenados de todos los campos del documento (sin etiquetas) y la clave compartida adjunta. Para una descripción de la función Seguridad de las transacciones.

Notificación de desactivación del pago automático (RPDN)

Cuando se desactiva el pago automático para un determinado ClientHash, se envía un mensaje dedicado en forma de documento XML, es a través del protocolo HTTPS (puerto 443 por defecto), utilizando el método POST, con un parámetro denominado recurrente. Este parámetro se almacena utilizando el mecanismo de codificación de transporte Base64.

Formato de documento (XML)

	<?xml version="1.0" encoding="UTF-8"?>
	<recurringDeactivation>
		<serviceID>ServiceID</serviceID>
		<recurringData>
			<recurringAction>RecurringAction</recurringAction>
			<clientHash>ClientHash</clientHash>
			<deactivationSource>DeactivationSource</deactivationSource>
			<deactivationDate>DeactivationDate</deactivationDate>
		<recurringData>
		<hash>Hash</hash>
	</recurringDeactivation>

Los valores de los elementos serviceID, clientHash pertenecientes a cada uno de los
pagos cíclicos desactivados, son idénticos a los valores de los
campos correspondientes proporcionados en el mensaje RPAN al inicio del
pago de inicialización respectivo.

Descripción de los parámetros devueltos

IMPORTANTE El orden de los atributos de la enumeración Hash debe seguir su numeración.

NOTAS: El elemento hash (mensaje) se utiliza para autenticar el documento. El valor de este elemento se calcula como el valor de una función hash a partir de una cadena que contiene los valores concatenados de todos los campos del documento y la clave compartida adjunta.

Acuse de recibo del mensaje

La respuesta a la notificación espera el estado HTTP 200 (OKq) y
texto en formato XML (no codificado en Base64), devuelto por el Servicio en la misma
sesión HTTP, que contiene un acuse de recibo del mensaje.

Estructura de confirmación (XML)

	<?xml version="1.0" encoding="UTF-8"?>
	<confirmationList>
		<serviceID>ServiceID</serviceID>
		<recurringConfirmations>
			<recurringConfirmed>
				<clientHash>ClientHash</clientHash>
				<confirmation>Confirmation</confirmation>
			</recurringConfirmed>
		</recurringConfirmations>
		<hash>Hash</hash>
	</confirmationList>

Confirmación de elementos

Elemento confirmación se utiliza para transmitir el estado de verificación de la autenticidad de la operación por parte del Servicio. El valor del elemento se determina comprobando la corrección de los valores de los parámetros. serviceID y clientHash con los especificados en el mensaje RPAN al inicio de un determinado pago de inicialización, y la verificación de que el hash calculado a partir de los parámetros del mensaje coincide con el valor pasado en el campo hash.

Se proporcionan dos valores para el elemento confirmación:

a) CONFIRMADO - valores de los parámetros son correctos y el parámetro hash son coherentes - operación auténtica.

b) NO CONFIRMADO - valores en ambos mensajes no son válidos o
hash mismatch - operación no auténtica.

NOTAS: El elemento hash (en la respuesta del mensaje) se utiliza para la autenticación de la respuesta y se calcula a partir del valor de los parámetros de respuesta. El valor de este elemento se calcula como el valor de una función hash a partir de una cadena que contiene los valores hash de todos los campos del documento (sin etiquetas) y la clave compartida incluida. Para obtener una descripción de cómo calcula el hash, consulte la sección Seguridad de las transacciones.

Si no hay una respuesta correcta a las notificaciones enviadas, el Sistema realizará otro intento de comunicación transcurrido un tiempo determinado. El
Servicio debe realizar su propia lógica de negocio (por ejemplo, detener
el pago automático, el envío por correo, etc.), sólo después del primer
mensaje RPDN sobre un determinado ClientHash.

TIP: Le recomendamos que lea también las secciones Supervisión
de las comunicaciones ITN/ISTN/IPN/RPAN/RPDN i Sistema de renovación de mensajes ITN/ISTN/IPN/RPAN/RPDN.

Verificación de la identidad del ordenante

Descripción de la verificación de la identidad del ordenante

La verificación de la identidad del ordenante puede realizarse sobre la base de la comparación de los datos proporcionados para la verificación en los parámetros de inicio de la transacción y los datos obtenidos del pago registrado en el Sistema. Si durante la integración se acuerda la opción de verificar los datos y se aportan los datos declarados por el cliente para su verificación en el inicio de la transacción, el Sistema realizará una comprobación de la veracidad de dichos datos y su resultado se colocará en el mensaje ITN junto a los datos del ordenante de la transferencia. Para
la mayoría de las transacciones PBL, el primer mensaje ITN no
contendrá los datos de dirección (nombres, dirección) del cliente. Estos datos se completan en el Sistema después de escanear el historial de cuentas AP del canal de pago respectivo. La cumplimentación de estos datos da lugar al envío de un mensaje ITN posterior al Socio, que ya contiene estos datos.

Campos del mensaje de inicio de transacción asociados a un servicio (descripción en la sección Iniciar una transacción con parámetros adicionales):

• VerificaciónFName,

• VerificaciónLNombre,

• VerificaciónStreet,

• VerificaciónCasaNo,

• VerificaciónCalleEscaleraNo,

• VerificaciónNº de calle

• VerificaciónCódigo postal,

• VerificaciónCiudad,

• VerificaciónNRB

Los campos del mensaje ITN asociados al servicio (descritos en la sección Campos adicionales en el mensaje ITN/IPN de la transacción entrante):

• nodo customerData

• verificationStatus

• nodo verificationStatusReasons

TIP: Las instrucciones detalladas sobre cómo interpretar los estados de
pagos y verificaciones en este proceso se encuentran en la sección Campos adicionales en el mensaje ITN/IPN de la transacción entrante.

Iniciar una transacción con parámetros adicionales

El inicio de las transacciones puede realizarse con los parámetros adicionales que se indican en los apartados siguientes.

IMPORTANTE El orden de los atributos de la enumeración Hash debe seguir su numeración.

Cesta de productos

Descripción de la cesta de productos

La cesta de productos se envía como un parámetro (método POST) llamado Products. Su valor se codifica con el protocolo de transporte Base64.

Formato antes de la codificación (XML)

	<?xml version="1.0" encoding="UTF-8"?>
	<productList>
		<product>
			<subAmount>SubAmount1</subAmount>
			<params>Params1</params>
		</product>
		<product>
			<subAmount>SubAmount2</subAmount>
			<params>Params2</params>
		</product>
		…
		<product>
			<subAmount>SubAmountN</subAmount>
			<params>ParamsN</params>
		</product>
	</productList>

Nodo productList debe contener al menos 1 elemento producto,
cada nodo. producto deben contener cada uno un elemento de subImporte i parámetros.

Elemento subImporte debe contener un importe de producto positivo (el separador decimal es un punto seguido de dos dígitos de penique). La suma de importes de productos consecutivos debe ser igual al importe indicado en el parámetro Importe (el importe de la transacción).

Si no se cumplen las condiciones anteriores, el Sistema devolverá un error.

Parámetros de los elementos

Elemento parámetros se puede utilizar para comunicar información específica del producto. Los nombres de los parámetros y su significado están sujetos a un acuerdo en forma de trabajo cada vez durante
la integración.

Ejemplos de parámetros de productos y su significado a continuación.

• En este caso, el nodo contiene el nombre del producto:

		<params>
			<param name="productName" value="Nazwa produktu 1" />
		</params>

• En este caso, el nodo contiene dos valores asignados al producto, que pueden denotar, por ejemplo, el tipo de producto y su nombre:

		<params>
			<param name="productType" value="ABCD" />
			<param name="productName" value="Nazwa produktu 1" />
		</params>

• En caso de que el Servicio tenga saldo en el Sistema, y prevea realizar devoluciones al Cliente de la totalidad o parte del importe abonado por el producto designado, se obliga a transferir en el producto su único identificador (parámetro denominado productID con tipo cadena{1,36} (Caracteres alfanuméricos latinos y caracteres permitidos: _ i -)):

		<params>
			<param name="productID" value="12456" />
		</params>

• Si el Socio utiliza una estructura ampliada (múltiples puntos de facturación), está obligado a transmitir en cada producto el identificador del punto de facturación (parámetro denominado idBalancePoint con tipo integer{1,10}):

		<params>
			<param name="idBalancePoint" value="12456" />
		</params>

• En caso de que el Socio utilice la facturación TRANSFERENCIA_MASIVAes decir

  • cada transacción se liquida inmediatamente después del depósito y

  • las liquidaciones se realizan a nivel de producto/punto de liquidación
    (es decir, se realizan tantas transferencias de liquidación tras el depósito como productos en la cesta), y

  • no se han establecido datos de facturación fijos (o no todos
    los datos de facturación están establecidos rígidamente en la configuración de facturación),

El socio debe proporcionar en cada producto los datos que faltan para la facturación de ese producto. Los parámetros disponibles que constituyen los datos son:

• clienteNRB - número de cuenta de destino para la facturación.
  Formato NRB (26 dígitos con suma de comprobación). Si durante la integración de se establece el uso de cuentas no polacas, entonces el campo transfiere IBAN y el rango de datos esperado del campo cambia a: alfanuméricos caracteres latinos (mín. 15, máx. 32 caracteres). Especificar valores en formato IBAN dará lugar a la necesidad de especificar en el producto también los parámetros swiftCode, foreignTransferMode.

• título - título de la transferencia de liquidación del producto. En ciertos casos, fuera del control de AP, el título de la transferencia de liquidación puede ser modificado independientemente por el Banco desde el que se produjo la liquidación.
  Caracteres alfanuméricos latinos aceptables y caracteres del rango
  :

• receiverName - el nombre del destinatario de la transferencia que liquida el producto.
  Caracteres alfanuméricos latinos aceptables y caracteres del rango
  :

Ejemplo de aplicación de parámetros a un producto:

	<params>
		<param name="customerNRB" value="83109010980000000107285707" />
		<param name="title" value="Rozliczenie produktu X" />
		<param name="receiverName" value="Jan Kowalski" />
	</params>

• En el modelo Marketplace, el Socio está obligado a transmitir en cada
  producto el identificador del punto de facturación (parámetro denominado idBalancePoint de tipo entero{1,10}). Esto también se aplica a la del saldo del punto de liquidación.

Ejemplo de parámetros de la cesta:

	<params>
		<param name="idBalancePoint" value="12456" />
		<param name="productName" value="Zasilenie salda dla Autopay" />
	</params>

Visualización de la cesta de productos en la pantalla de selección del canal de pago

Si se ha establecido durante las discusiones de la cesta de productos que su resumen se va a mostrar en la página del Sistema (la pantalla de selección del Canal de Pago), se pueden especificar las etiquetas de cada parámetro utilizado en la cesta. El Sistema puede utilizar la etiqueta por defecto del parámetro o puede aceptarla al inicio de la transacción.

El valor del atributo título se mostrará antes del valor del parámetro de producto.

Ejemplo de atributo title

	<params>
		<param name="productName" value="Nazwa produktu 1" title="Nazwa"/>
		<param name="productType" value="ABCD" title="Typ"/>
	</params>

Opciones adicionales de comunicación en línea para el socio

Campos adicionales en el mensaje ITN/IPN de la transacción entrante

Descripción

La notificación inmediata de un cambio en el estado de una transacción puede contener
campos adicionales (véase Sistemas de autorización previa). Su aparición es una cuestión de configuración, determinada durante la integración (por defecto, sólo el nodo se envía
. customerData).

El hecho de que se trate de un mensaje ITN o IPN viene determinado únicamente por la presencia de un nodo producto.

Lista completa de campos adicionales del mensaje NIT/NIP

IMPORTANTE El orden de los atributos de la enumeración Hash debe seguir su numeración.

NOTAS: Para contar los valores Hash, se toman los atributos valor otros nodos parámetros.producto.

Ejemplo de mensaje ITN/IPN con parámetros adicionales (XML)

	<?xml version="1.0" encoding="UTF-8"?>
	<transactionList>
	  <serviceID>ServiceID</serviceID>
	  <transactions>
	  <transaction>
		<orderID>OrderID</orderID>
		<remoteID>RemoteID</remoteID>
		<amount>999999.99</amount>
		<currency>PLN</currency>
		<gatewayID>GatewayID</gatewayID>
		<paymentDate>YYYYMMDDhhmmss</paymentDate>
		<paymentStatus>PaymentStatus</paymentStatus>                 
		<paymentStatusDetails>PaymentStatusDetails</paymentStatusDetails>
		<addressIP>127.0.0.1</addressIP>
		<customerNumber>1111111</customerNumber>
		<title>title</title>
		<customerData>
		  <fName>fName</fName>
		  <lName>lName</lName>
		  <streetName>streetName</streetName>
		  <streetHouseNo>streetHouseNo</streetHouseNo>
		  <streetStaircaseNo>streetStaircaseNo</streetStaircaseNo>
		  <streetPremiseNo>streetPremiseNo</streetPremiseNo>
		  <postalCode>postalCode</postalCode>
		  <city>city</city>
		  <nrb>nrb</nrb>
		  <senderData>senderData</senderData>    
		</customerData>
		<verificationStatus>verificationStatus</verificationStatus>
		<verificationStatusReasons>
		   <verificationStatusReason>reason1</verificationStatusReason>
		   <verificationStatusReason>reason2</verificationStatusReason>
		   <verificationStatusReason>reason3</verificationStatusReason>
		</verificationStatusReasons>
		<startAmount>999998.99</startAmount>    
		<recurringData>
			<recurringAction>RecurringAction</recurringAction>
			<clientHash>ClientHash</clientHash>
			<expirationDate>YYYYMMDDhhmmss</expirationDate>
		</recurringData>
		<cardData>
			<index>Index</index>
			<validityYear>ValidityYear</validityYear>
			<validityMonth>ValidityMonth</validityMonth>
			<issuer>Issuer</issuer>
			<bin>BIN</bin>
		</cardData>
		<product>
			<subAmount>SubAmount</subAmount>
			<params>
				<param name="idBalancePoint" value="idBalancePoint"/>
				<param name="invoiceNumber" value="invoiceNumber"/>
				<param name="customerNumber" value="customerNumber"/>
				<param name="subAmount" value="SubAmount"/>
			</params>
		</product>
	  </transaction>
	  </transactions>
	  <hash>Hash</hash>
	</transactionList>

Descripción detallada del cambio en el estado de verificación - para una transacción completada con éxito (resultado positivo o negativo)

Descripción detallada del cambio de estado de verificación - para una transacción no completada correctamente

Estados detallados de las transacciones

El mensaje ITN para una transacción entrante contiene, además del estado del pago
(campo paymentStatus) una descripción detallada de ese estado (campo paymentStatusDetails). Esta descripción debe tratarse como informativa, la lista de sus valores permitidos crece constantemente y la aparición de nuevos valores puede no implicar la no aceptación del mensaje ITN.

Valores de estado de la transacción - Estados generales (independientes del canal de pago)

Valores de estado de las transacciones - Estados de las tarjetas

Valores de estado de la transacción - Estados específicos de la transacción BLIK

Notificación inmediata del cambio de estado del producto (IPN)

En el caso de un socio que utilice estructura ampliada (Cesta de productos con múltiples puntos de facturación), el Sistema proporciona notificaciones independientes de los cambios de estado de cada producto. Este servicio tiene sentido si los puntos de facturación individuales deben recibir sus propias notificaciones. En este caso, la configuración de la IPN (dirección para las notificaciones, campos que deben incluirse en el mensaje, etc.) se almacena precisamente en el nivel de configuración del punto de facturación. La estructura de la IPN es similar a la de la ITN (ampliada únicamente por el nodo producto similar a la descrita en el capítulo Campos adicionales en el mensaje ITN/IPN de la transacción entrante, complementado únicamente por la repetición de la cantidad subImporte en params). Ejemplo de IPN en la subsección Campos adicionales en el mensaje ITN/IPN de la transacción entrante).

Notificación inmediata de un cambio en el estado de una operación de liquidación (ISTN)

Es posible proporcionar mensajes sobre todos los desembolsos (liquidaciones, desembolsos de saldos y reembolsos) realizados por el Sistema como parte del servicio de pago. Dado que el servicio no está habilitado por defecto, la necesidad de este servicio, junto con la dirección postal de la RTI, deberá ser solicitada por el Socio durante la determinación de los requisitos.

Si la comunicación ISTN se activa con éxito, el Sistema transmite inmediatamente notificaciones sobre el hecho de la ordenación de la operación de liquidación (reintegros/devoluciones, en su caso) y el cambio de su estado. Las confirmaciones se envían, a la dirección en el servidor del Servicio del Socio establecido durante la adición de la configuración del Servicio del Socio:

https://sklep_nazwa/odbior_informacji_o_rozliczeniu

Esta notificación consiste en el envío por parte del Sistema de un documento XML que contiene los nuevos estados de las transacciones. El documento se envía a través del protocolo HTTPS (puerto 443 por defecto). El documento se envía
a través del método POST, como un parámetro HTTP denominado transacciones. Este parámetro se almacena utilizando el mecanismo de codificación de transporte Base64.

Formato de documento (XML)

	<?xml version="1.0" encoding="UTF-8"?>
	<transactionList>
		<serviceID>ServiceID</serviceID>
		<transactions>
			<transaction>
				<isRefund>true/false</isRefund>
				<productID>ProductID</productID>
				<orderID>OrderID</orderID>
				<orderOutID>OrderOutID</orderOutID>
				<remoteID>RemoteID</remoteID>
				<remoteOutID>RemoteOutID</remoteOutID>
				<amount>999999.99</amount>
				<currency>PLN</currency>
				<transferDate>YYYYMMDDhhmmss</transferDate>
				<transferStatus>TransferStatus</transferStatus>                 
				<transferStatusDetails>TranasferStatusDetails</transferStatusDetails>
				<title>Title</title>
				<receiverBank>ReceiverBank</receiverBank>      
				<receiverNRB>ReceiverNRB</receiverNRB>
				<receiverName>ReceiverName</receiverName>
				<receiverAddress>ReceiverAddress</receiverAddress>
				<senderBank>SenderBank</senderBank>
				<senderNRB>SenderNRB</senderNRB>
			</transaction>
		</transactions>
		<hash>Hash</hash>
	</transactionList>

Parámetros devueltos

IMPORTANTE El orden de los atributos de la enumeración Hash debe seguir su numeración.

Respuesta a la notificación

En respuesta a la notificación, se espera un texto en formato XML (no codificado en Base64), devuelto por el Servicio Partner en la misma sesión HTTP, que contiene un acuse de recibo del estado de la transacción.

Estructura de confirmación (XML)

	<?xml version="1.0" encoding="UTF-8"?>
	<confirmationList>
		<serviceID>ServiceID</serviceID>
		<transactionsConfirmations>
			<transactionConfirmed>
				<remoteOutID>RemoteOutID</remoteOutID>
				<confirmation>Confirmation</confirmation>
			</transactionConfirmed>
		</transactionsConfirmations>
		<hash>Hash</hash>
	</confirmationList>

Elemento confirmación se utiliza para transmitir el estado de verificación de la autenticidad de la transacción por parte del servicio asociado. El valor del elemento
se determina validando el valor del parámetro
serviceID, así como verificando que el hash calculado coincide con el valor
pasado en el campo hash.

Se proporcionan dos valores para este elemento:

a) CONFIRMADO - el parámetro hash es consistente - transacción auténtica;

b) NO CONFIRMADO - el parámetro hash es inconsistente - transacción
no auténtica;

Si no hay una respuesta correcta a las notificaciones enviadas, el Sistema realizará nuevos intentos de comunicar un nuevo estado una vez transcurrido un tiempo especificado. El Servicio Asociado debe realizar su propia lógica de negocio,
sólo después del primer mensaje sobre un estado de pago determinado.

TIP: Merece la pena echar un vistazo a Plan de reproducción de mensajes ITN/ISTN/IPN/RPAN/RPDN.

Descripción detallada del comportamiento y cambio de los estados de liquidación (transferStatus)

En el modelo básico, el Sistema sólo proporcionará el estado ÉXITOSin embargo, una notificación más precisa es posible
. La opción completa debe ser notificada durante la integración e implica el siguiente patrón de transiciones de estado.

Una orden para una operación de liquidación envía un estado PENDIENTE. Posteriormente, el sistema proporcionará ÉXITO o FALLO. Para las transacciones
para las que se ha producido el estado ÉXITO, ya no debería haber un cambio de estado a FALLO. No obstante, puede producirse un cambio de
estado de detalle (los posteriores
mensajes de cambio de estado de detalle son meramente informativos y no deben implicar
la reejecución de ninguna lógica empresarial).

En casos especiales (por ejemplo, un error en el banco), una transacción originalmente
confirmada puede pasar a ser reejecutada, y así
cambiar su estado a. PENDIENTE y de nuevo en ÉXITO.

Otro caso especial puede ser la situación de FALLO (por ejemplo, después de un
error interno del Sistema), luego se sustituye por el estado de la ÉXITO.

Servicios adicionales

Consulta de la lista de canales de pago disponibles actualmente

Descripción

Con el fin de construir una vista de selección de método de pago en el Servicio, el Sistema permite que la lista actual de los canales de pago para ser consultado de forma remota. Para ello, llame al método gatewayList (https://{host_gateway}/gatewayList/v3) con parámetros correspondientes (en formato JSON). Todos los parámetros se transmiten utilizando la tecnología REST. El protocolo distingue entre mayúsculas y minúsculas tanto en los nombres como en los valores de los parámetros. Los valores de los parámetros pasados deben estar codificados en UTF-8.

Lista de parámetros disponibles

IMPORTANTE El orden de los atributos de la enumeración Hash debe seguir su numeración.

Ejemplo de mensaje

{
	"ServiceID": 47498,
	"MessageID": "11111111111111111111111111111111",
	"Currencies":"PLN,EUR",
	"Language": "PL",
	"Hash": "306519f632e53a5e662de0125da7ac3f8135c7e4080900f2b145d4b25ff1b55d"
}

Respuesta a la solicitud

En respuesta a una solicitud, se devuelven 2 listas de definiciones en la misma sesión HTTP:

a) Canales de pago (nodo gatewayList)

b) Grupos de pago (nodo gatewayGroups)

A continuación encontrará una descripción detallada del mensaje devuelto:

Ejemplo de respuesta

{
    "result": "OK",
    "errorStatus": null,
    "description": null,
    "gatewayGroups": [
        {
            "type": "PBL",
            "title": "Przelew internetowy",
            "shortDescription": "Wybierz bank, z którego chcesz zlecić płatność",
            "description": null,
            "order": 1,
            "iconUrl": null
        },
        {
            "type": "FR",
            "title": "Dane do przelewu",
            "shortDescription": "Zleć przelew wykorzystując podane dane",
            "description": null,
            "order": 2,
            "iconUrl": null
        },
        {
            "type": "BNPL",
            "title": "Kup teraz, zapłać później",
            "shortDescription": "Kup teraz, zapłać później",
            "description": null,
            "order": 3,
            "iconUrl": null
        }
    ],
    "serviceID": "10000",
    "messageID": "2ca19ceb5258ce0aa3bc815e80240000",
    "gatewayList": [
        {
            "gatewayID": 106,
            "name": "Płatność testowa PBL",
            "groupType": "PBL",
            "bankName": "NONE",
            "iconURL": "https://testimages.autopay.eu/pomoc/grafika/106.gif",
            "state": "OK",
            "stateDate": "2023-10-03 14:35:01",
            "description": "Płatność testowa",
            "shortDescription": null,
            "descriptionUrl": null,
            "availableFor": "BOTH",
            "requiredParams": ["Nip"],
            "mcc": {
                "allowed": [1234, 9876],
                "disallowed": [1111]
            },
            "inBalanceAllowed": true,
            "minValidityTime": null,
            "order": 1,
            "currencies": [
                {
                    "currency": "PLN",
                    "minAmount": 0.01,
                    "maxAmount": 5000.00
                }
            ],
            "buttonTitle": "Płacę"
        },
        {
            "gatewayID": 9,
            "name": "Przelew z innego banku",
            "groupType": "FR",
            "bankName": "BANK TEST",
            "iconURL": "https://testimages.autopay.eu/pomoc/grafika/9.gif",
            "state": "OK",
            "stateDate": "2023-10-03 14:35:02",
            "description": "<b>Szybki przelew</b>",
            "shortDescription": "Szybki przelew",
            "descriptionUrl": null,
            "availableFor": "BOTH",
            "requiredParams": [],
            "mcc": null,
            "inBalanceAllowed": true,
            "minValidityTime": null,
            "order": 2,
            "currencies": [
                {
                    "currency": "PLN"
                }
            ],
            "buttonTitle": "Wygeneruj dane do przelewu"
        },
		{
            "id": 701,
            "name": "Zapłać później z Payka",
            "groupType": "BNPL",
            "bankName": "NONE",
            "iconUrl": "https://testimages.autopay.eu/pomoc/grafika/701.png",
            "state": "OK",
            "stateDate": "2023-10-03 14:37:10",
            "description": "<div class=\"payway_desc\"><h1>Dane dotyczące kosztu</h1><p>Zapłać później - jednorazowo do 45 dni (...). Szczegóły oferty na: <a href="?r="https://payka.pl\" target=\"_blank\">Payka.pl</a></p></div>",
            "shortDescription": "Zapłać później - jednorazowo do 45 dni lub w kilku równych ratach",
            "descriptionUrl": null,
            "availableFor": "B2C",
            "requiredParams": [],
            "mcc": null,
            "inBalanceAllowed": false,
            "minValidityTime": 60,
            "order": 3,
            "currencies": [
                {
                    "currency": "PLN",
                    "minAmount": 49.99,
                    "maxAmount": 7000.00
                }
            ],
            "buttonTitle": "Płacę"
        }
    ]
}

NOTAS: El resultado de la consulta del método debe ser guardado y actualizado cada minuto para comprobar la disponibilidad del canal. En caso de que falte una respuesta o sea incorrecta, debe mostrarse la última configuración conocida y correcta de los canales de pago. Esta es la segunda razón para mantener una copia temporal de la gatewayList en el Servicio de socios. Una respuesta no válida debe considerarse como una respuesta vacía, un tiempo de espera o una lista de nodos vacía. gatewayGroups o gatewayList.

Solicitar una lista de las autorizaciones formales disponibles en la actualidad

Descripción

Descripción de una integración que permite utilizar una lista de pagos integrada en un servicio (o aplicación móvil) sin pasos de transición. En
algunos casos, en lugar de un paso de transición, el comportamiento
estándar del sistema prevé el bloqueo del inicio de la transacción.

El contenido formal pertinente (es decir, las cláusulas de información
y, en su caso, los términos y condiciones) debe mostrarse ya en el momento de la selección del método de pago,
y, a continuación, debe transmitirse al Sistema de Pago en Línea la confirmación de su visualización y, en su caso, aceptación (en forma de identificadores).

El sistema permite consultar a distancia la lista actual de obligaciones y
contenidos formales relacionados. Para ello se utiliza el método legalData (https://{host_gates}/legalData) con los correspondientes parámetros
(en formato JSON).

TIP: Todos los parámetros se transmiten utilizando tecnología REST. El protocolo distingue entre mayúsculas y minúsculas tanto en los nombres como en los valores de los parámetros. Los valores de los parámetros transmitidos deben estar codificados en UTF-8.

Lista de parámetros disponibles

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

Ejemplo de mensaje

	{
		"ServiceID": 102422,
		"MessageID": "11111111111111111111111111111111",
		"GatewayID": 1500,
		"Language": "PL",
		"Hash":"61789013d932e2bc728d6206f7e9222b93e3176f7f07f6aa8cce1ccd65afaf0d"
	}

Lista de parámetros devueltos

En respuesta a la solicitud, se devuelve una lista (en la misma sesión HTTP), que contiene más contenido formal en forma de: ID, tipo y redacción del contenido, su ubicación en el Servicio, dirección a las reglas y otra información adicional.

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

Ejemplo de respuesta

	{
		"serviceID": "102422",
		"messageID": "11111111111111111111111111111111",
		"gatewayID": "1500",
		"language": "PL",
		"serviceModel": "PAYER",
		"regulationList": [
			{
				"regulationID": 6288,
				"type": "RECURRING",
				"url": "https://host/path?params",
				"labelList": [
					{
						"labelID": 1,
						"inputLabel": "<ul><li>\r\nZapoznałem się i akceptuję <a id=\"regulations_pdf\" target=\"_blank\" href=https://{host_bramki}/path?params>Regulamin świadczenia usług płatniczych</a> oraz <a class=\"privacy-policy\" href=\"https://{host_bramki}/polityka-prywatnosci.pdf\" target=\"_blank\">Politykę prywatności</a></li><li>\r\nChcę aby usługa została zrealizowana niezwłocznie, a w przypadku odstąpienia od umowy, wiem, że nie otrzymam zwrotu poniesionych kosztów za usługi zrealizowane na moje żądanie do chwili odstąpienia od umowy\r\n</li></ul>",
						"placement": "ABOVE_BUTTON",
						"showCheckbox": true,
						"checkboxRequired": true
					}
				]
			},
			{
				"regulationID": 1,
				"type": "PRIVACY",
				"labelList": [
					{
						"labelID": 1,
						"inputLabel": "Autopay korzysta z plików cookie. Pozostając na tej stronie, wyrażasz zgodę na korzystanie z plików cookie zgodnie z <a class=\"privacy-policy\" href="?r="https://{host_bramki}/polityka-prywatnosci.pdf\" target=\"_blank\">Polityką prywatności Autopay S.A. </a> Możesz samodzielnie zarządzać cookies zmieniając odpowiednio ustawienia swojej przeglądarki lub oprogramowania urządzenia."
						"placement": "BOTTOM_OF_PAGE",
						"showCheckbox": false,
						"checkboxRequired": false
					}
				]
			}
		],
		"hash": "61789013d932e2bc728d6206f7e9222b93e3176f7f07f6aa8cce1ccd65afaf0d",
		"result": "OK",
		"errorStatus": null,
		"description": null
	}

Descripción de la gestión de la respuesta

Dado que los requisitos formales del contenido de las cláusulas, su disposición y el método de aceptación dependen del canal de pago utilizado, este método debe llamarse cada vez que se seleccione (de ahí la obligatoriedad del parámetro de la opción GatewayID).

El contenido y el comportamiento relevantes deberían adaptarse dinámicamente a las respuestas del Sistema (por ejemplo, debería aparecer una casilla de verificación obligatoria con una cláusula informativa y un enlace a los términos y condiciones). Por supuesto, con el fin de hacer que la
aplicación funcione rápido, el uso de una caché para
recordar las respuestas de las llamadas recientes (por ejemplo, durante 1 minuto) es bienvenido.

El consentimiento mostrado (y posiblemente aprobado) en el momento de la transición al pago debe confirmarse en el Sistema mediante la inclusión en el mensaje de inicio en el parámetro de inicio de su identificador (y, por lo tanto, el valor correspondiente de la etiqueta reglamentoID).

En función del valor del campo tipo reglamentos:

- para la cláusula mostrada/aceptada de tipo=DEFAULT:

a. al parámetro DefaultRegulationAcceptanceID debe ir su valor
. reglamentoID;

b. al parámetro DefaultRegulationAcceptanceState debe ir
valor ACEPTADO y

c. al parámetro DefaultRegulationAcceptanceTime debe pulsar el valor
correspondiente al momento de aceptación del consentimiento marcando la casilla
y pulsando el botón "Iniciar pago".

- para la cláusula mostrada/aceptada de tipo=RECURRENTE:

a. al parámetro RecurringAcceptanceID debe alcanzar su valor reglamentoID;

b. al parámetro RecurringAcceptanceState debe alcanzar el valor de ACEPTADO y

c. al parámetro RecurringAcceptanceTime debe pulsar el valor correspondiente al momento de aceptación del consentimiento marcando la casilla de verificación y pulsando el botón "Iniciar pago".

NOTAS: Campos (por ejemplo serviceModel, url, labelID) y valores de campo (por ejemplo PSD2, RODO, PRIVACIDAD) métodos legalData no son necesarios para la gestión de
, pero debe preverse que se produzcan en la
respuesta a una solicitud.

Consulta de saldo

Descripción

Para todos los servicios, es posible consultar el saldo actual. Para
esto, se debe llamar al método. saldoObtener https://{host_gates}/webapi/balanceGet con los parámetros correspondientes. Todos los parámetros se pasan mediante el método POST (Content-Type: application/x-www-form-urlencoded). El protocolo distingue entre mayúsculas y minúsculas tanto en los nombres como en los valores de los parámetros. Los valores de los parámetros pasados deben estar codificados en UTF-8.

Lista de parámetros disponibles para la balanza actual

IMPORTANTE El orden de los atributos de la enumeración Hash debe seguir su numeración.

Respuesta a la solicitud de saldo actual

En respuesta a la solicitud, se devuelve un texto en formato XML (en la misma sesión HTTP), que contiene un acuse de recibo de la operación para o una descripción del error.

Estructura de confirmación (XML)

	<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
	<balanceGet>
		<serviceID>ServiceID</serviceID>
		<messageID>MessageID</messageID>
		<balance>Balance</balance>
		<currency>Currency</currency>
		<hash>Hash</hash>
	</balanceGet>

o

	<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
	<balanceGet>
		<balancePointID>BalancePointID</balancePointID>
		<messageID>MessageID</messageID>
		<balance>Balance</balance>
		<currency>Currency</currency>
		<hash>Hash</hash>
	</balanceGet>

Lista de campos de respuesta

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

Equilibrar la oferta

Descripción

Para los servicios que tengan saldo en el Sistema, es posible realizar operaciones
de abono del saldo contra futuras devoluciones. Para ello, es necesario realizar un inicio de operación con el parámetro TransactionSettlementMode o
valores NONE y Importe indicando el importe de la recarga.

El uso de Pretransacciones permitirá la entrega sencilla de la transacción
finalizada al pagador (por ejemplo, proporcionando la
dirección del departamento de contabilidad del socio en CustomerEmail).

NOTAS: El servicio debe ser acordado con el custodio del negocio. En el modelo Marketplace, también será necesario construir una cesta de productos indicando qué BalancePointID se va a alimentar.

Retiradas de saldo

Descripción

Para los servicios que tienen saldo en el Sistema, es posible realizar operaciones de
para retirar todo o parte del saldo a la cuenta definida para
liquidaciones. Para ello es necesario llamar al método balancePago (https://{host_gates}/settlementapi/balancePayoff) con los parámetros
correspondientes.

Todos los parámetros se pasan a través del método POST (Content-Type: application/x-www-form-urlencoded). El protocolo distingue entre mayúsculas y minúsculas tanto en los nombres como en los valores de los parámetros. Los valores de los parámetros pasados deben estar codificados en UTF-8.

Lista de parámetros disponibles para la retirada de saldo

IMPORTANTE El orden de los atributos de la enumeración Hash debe seguir su numeración.

NOTAS: Campos obligatorios ServiceID o BalancePointID.
Si se especifican ambos, se detendrá el procesamiento de la solicitud y se producirá un error http.

Respuesta a la solicitud

Al recibir una solicitud de retirada de saldo, el Sistema realiza una verificación inicial con los campos y sus valores enviados en el mensaje y guarda la orden para su ejecución. En respuesta a la solicitud, se devuelve un texto con formato XML (en la misma sesión HTTP), que contiene un acuse de recibo de que la orden se ha guardado en la cola para su ejecución o una descripción del error (la estructura del mensaje de error se describe en el apartado Mensajes de error.

NOTAS: El acuse de recibo de una orden no equivale a su ejecución efectiva. Una retirada de saldo puede procesarse hasta 30 minutos después del envío de la solicitud de retirada y puede que no siempre tenga éxito. En caso de que surjan problemas durante el procesamiento de una retirada de saldo (por ejemplo, fondos insuficientes en el saldo), al día hábil siguiente se envía un informe con información sobre las retiradas de saldo que no han tenido éxito.

Estructura de confirmación (XML)

	<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
	<balancePayoff>
		<serviceID>ServiceID</serviceID>
		<messageID>MessageID</messageID>
		<hash>Hash</hash>
	</balancePayoff>

o

	<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
	<balancePayoff>
		<balancePointID>BalancePointID</balancePointID>
		<messageID>MessageID</messageID>
		<hash>Hash</hash>
	</balancePayoff>

Descripción de los campos

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

NOTAS: Todas las respuestas distintas de la supuesta (es decir, con campos incorrectos, en particular en blanco o incorrectos hash). En caso de que el Sistema autorice al emisor del mensaje de retorno pero la operación falle, la respuesta seguirá el esquema descrito en el apartado Mensajes de error. En caso de error de comunicación o de saldo insuficiente (por ejemplo, ON_DEMAND_ERROR), la orden puede renovarse. Si el saldo está bloqueado (BALANCE_DISABLED) o la configuración no está activa (PARTNER_DISABLED), la orden no debe renovarse.

IMPORTANTE En caso de que se devuelva un error en respuesta a una solicitud de retirada de saldo, la solicitud puede volver a intentarse, pero tenga en cuenta que cualquier solicitud de retirada que no termine en error puede ejecutarse. En caso de problemas de conexión, que superen el tiempo máximo de respuesta, se puede repetir la solicitud con el mismo MessageID sin temor a duplicar la orden.
En caso de saldo bloqueado (BALANCE_DISABLED) o configuración inactiva (PARTNER_DISABLED), la solicitud no debe renovarse. 3 errores seguidos (independientemente de la causa) bloquearán el servicio de desembolso bajo demanda para la IP remitente de mensajes especificada durante 10 minutos - las llamadas durante este tiempo para esta IP finalizarán con un error TEMPORARY_DISABLED.

Devolución de operaciones

Descripción

Para los servicios con saldo en el Sistema, es posible realizar operaciones de devolución al Cliente de todo o parte del importe abonado por la transacción indicada. La devolución de la totalidad de la transacción puede realizarse una sola vez (en caso de que se intente repetidamente solicitar la devolución de la misma transacción, el Sistema devuelve un error debidamente descrito). Las devoluciones de parte del importe de una transacción pueden realizarse en ella varias veces, siempre que su total no supere el importe del depósito.

Para realizar una devolución de transacción, llame al método transactionRefund (https://{host_gates}/settlementapi/transactionRefund) con los parámetros correspondientes. Todos los parámetros se pasan mediante el método POST (Content-Type: application/x-www-form-urlencoded). El protocolo distingue entre mayúsculas y minúsculas tanto en los nombres como en los valores de los parámetros. Los valores de los parámetros pasados deben estar codificados en UTF-8.

Lista de parámetros disponibles

IMPORTANTE El orden de los atributos de la enumeración Hash debe seguir su numeración.

En respuesta a la solicitud, se devuelve un texto con formato XML (en la misma sesión HTTP), ya sea confirmando la operación o describiendo el error (descrito a continuación).

Estructura de confirmación (XML)

	<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
	<transactionRefund>
		<serviceID>ServiceID</serviceID>
		<messageID>MessageID</messageID>
		<hash>Hash</hash>
	</transactionRefund>

Descripción de los campos

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

La opción de realizar reembolsos a las transacciones pagadas es posible hasta 12
meses atrás, a contar desde la fecha en que se inició la transacción. Una excepción son los pagos BLIK, que, debido a limitaciones de tiempo por parte del proveedor del canal de pago
, pueden reembolsarse hasta 6 meses atrás.

Estos plazos se aplican a la tramitación de las devoluciones a través del
panel de administración y del transactionRefund, por ejemplo, a través de las herramientas administrativas propias de
. Cuando se superen, se devolverá un error
(TRANSACCIÓN_DEMASIADO_ANTIGUO_PARA_DEVOLUCIÓN). El esquema de funcionamiento es análogo al de las retiradas de saldo. Es decir, el Sistema acepta la orden y la procesa de forma asíncrona en un máximo de 30 minutos, y en caso de fallo, la información sobre la operación que termina en un error se envía en un informe en el siguiente día hábil.

En caso de problemas de conexión, superando el tiempo máximo de respuesta, la solicitud se puede repetir con el mismo MessageID sin temor a una solicitud duplicada. Todas las respuestas distintas de la supuesta (es decir, con campos
no válidos, en particular, en blanco o no válidos. hash). Si el Sistema autoriza al remitente del mensaje de retorno
, pero la operación falla, se devuelve como respuesta un mensaje de error
.

Devoluciones de productos

Descripción

Para los sitios con un saldo en el Sistema y especificando
de los productos en el carrito de la compra, el parámetro productID, es posible realizar la operación de devolución al Cliente de la totalidad o parte del importe pagado por el producto indicado. La devolución con éxito de la totalidad del importe del producto se puede realizar una vez (en caso de un intento repetido de ordenar la devolución del mismo producto, el Sistema devuelve un error debidamente descrito). Devoluciones de parte del importe del producto se pueden realizar en él varias veces, siempre y cuando su suma no supere el importe pagado al producto.

Para realizar una devolución de producto, llame al método productoReembolso (https://{host_gates}/settlementapi/productRefund) con los parámetros
correspondientes. Todos los parámetros se pasan mediante el método POST (Content-Type: application/x-www-form-urlencoded). El protocolo distingue entre mayúsculas y minúsculas tanto en los nombres como en los valores de los parámetros. Los valores de los parámetros pasados deben estar codificados en UTF-8.

Lista de parámetros

IMPORTANTE El orden de los atributos para la enumeración Hash debe seguir su numeración
.

Respuesta a la solicitud

En respuesta a la solicitud, se devuelve un texto en formato
XML (en la misma sesión HTTP), que contiene un acuse de recibo de la operación o una descripción del
error (descrito a continuación).

Estructura de confirmación (XML)

	<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
	<productRefund>
		<serviceID>ServiceID</serviceID>
		<messageID>MessageID</messageID>
		<hash>Hash</hash>
	</productRefund>

Descripción de los campos

IMPORTANTE El orden de los atributos de la enumeración Hash debe seguir su numeración.