# Documentación integración WANNME

# 1. Introducción

Bienvenidos a la documentación de integración de WANNME. Durante estas páginas explicaremos los distintos modos de integración con nuestra plataforma. Esta documentación está destinada a técnicos y desarrolladores que quieran integrarse con WANNME.

Disponemos de dos formas de comunicación con nuestra plataforma: un APIREST securizado para la comunicación entre sistemas y módulos de pago o plugins para las plataformas CMS descritas en el punto 5.

# 2. Autenticación

# 2.1. Credenciales

Es necesario ponerse en contacto con WANNME para la obtención de las credenciales de operación. Estas credenciales son únicas por empresa colaboradora y entorno (sandbox / producción).

• Usuario web
• Contraseña web
• Partner Id
• Clave privada (necesaria para la firma de las peticiones, no debe ser distribuida ni usada como texto plano)
• APIKEY de acceso al APIREST

# 2.2. Entornos

Disponemos de dos entornos, un entorno de sandbox y un entorno de producción. Todas nuestras URL están disponibles a través de HTTPS.

El entorno de sandbox está dedicado a pruebas durante el proceso de desarrollo de las integraciones con las empresas colaboradoras. En este entorno tanto los datos como las transacciones no son reales, siendo siempre utilizados datos de pruebas que se destruyen cada cierto tiempo. En el entorno de producción tanto los datos como las operaciones son reales.

URL sandbox https://rest-demo.wannme.com/integration/v2

URL producción https://rest.wannme.com/integration/v2

Documentación técnica API Reference

# 2.3. Autenticación

Para asegurar la autenticación de las peticiones que se realizan al APIREST, todas deben incluir los siguientes elementos:

• APIKEY en cabecera: La cabecera de la petición debe incluir el APIKEY de acceso al APIREST (Ver 4. Integración APIREST para más información).
• Checksum y Partner Id en el cuerpo: El cuerpo de la petición debe incluir dos parámetros que aseguran su autenticación. Por un lado el PartnerId que identifica al comercio y por otro un parámetro de control resumen de la petición denominado checksum. Este está compuesto por una cadena codificada en SHA512 que concatena algunos parámetros significativos de la petición (definidos en cada end-point) y la clave privada del comercio. Esta clave privada solo deberá ser incluida como parte de la firma en las peticiones nunca como texto plano.

En los callbacks de notificaciones nuestras peticiones incluirán de igual modo al parámetro checksum, construido de igual manera. En cada notificación o end-point se especifica la forma de construir la cadena para posteriormente cifrarla con el algoritmo SHA512.

Si se envía una petición sin incluir el checksum se recibirá una respuesta con estado 400. En caso de mandar un checksum no válido para esa petición, se recibirá una respuesta con estado 500

# 3. Uso de la integración

A continuación se presenta una serie de listas con los datos maestros utilizados WANNME. Toda esta información se puede obtener a través de sus correspondientes end-points, por ejemplo los estados de los cobros: /wannmepay/masterdata/.

# 3.1. Estados de los cobros

Los cobros pueden tener los siguientes estados:

URL de consulta: integration/v2/wannmepay/masterdata/payment-states

Cuando un cobro se crea figura en estado CREADO. Cuando el usuario accede al cobro se situa en estado ACCEDIDO. En el momento en el que el usuario procede al pago el cobro se situa en PAGO EN PROCESO, de donde puede transitar hacia el estado PAGO COMPLETADO o ERROR / PAGO INCOMPLETO sino ha podido pagar. El cobro se situará en estado CADUCADO si el usuario no ha realizado el pago antes de la fecha de caducidad fijada en la creación del cobro.

# 3.1.1. Sub estados de los cobros

Los cobros pueden tener los siguientes sub-estados:

Los sub estados del cobro aportan más información sobre un cobro cuando se encuentra en alguna determinada etapa.

# 3.2. Estados de los recobros

Los recobros pueden tener los siguientes estados:

URL de consulta: integration/v2/wannmepay/masterdata/debt-case-states

# 3.2.1. Sub estados de los recobros

Los recobros pueden tener los siguientes sub-estados:

# 3.3. Estados de los recurrentes

Los recurrentes pueden tener los siguientes estados:

URL de consulta: integration/v2/wannmepay/masterdata/recurrent-states

# 3.3.1. Sub estados de los recurrentes

Los recurrentes pueden tener los siguientes sub-estados:

# 3.4. Estados de los agrupados

Los agrupados pueden tener los siguientes estados:

URL de consulta: integration/v2/wannmepay/masterdata/merge-payment-states

# 3.4.1. Sub estados de los agrupados

Los agrupados pueden tener los siguientes sub-estados:

URL de consulta: integration/v2/wannmepay/masterdata/merge-payment-sub-states

# 3.4.2. Estados de las definiciones de cobro

Las definiciones de agrupados pueden tener los siguientes estados:

URL de consulta: integration/v2/wannmepay/masterdata/merge-payment-slice-states

# 3.5. Estados de los merchant

Los diferentes valores que se pueden presentar en el atributo stateId de un merchant son los siguientes:

Cuando un merchant es creado o modificado se evalúa su información hasta que se sitúe en el estado de verificación. Será WANNME el que valide la documentación aportada y transitará el merchant a un estado operativo. En los entornos de sandbox existe un endpoint para poder realizar esta transicción de forma manual.

# 3.6. Notificaciones

# 3.6.1. URL's de notificación

En la creación de un cobro, recobro, agrupado o recurrente se puede proporcionar una URL de notificación a la que WANNME llamará en cada transición de estado de la entidad o en cada cambio que se produzca en la entidad, y se enviará por POST a la URL indicada. Se llamará a la URL de notificación antes de devolver el control en las URL de return (solo en el caso de un cobro). Esta URL puede ser configurada por defecto a nivel de partner para todos los cobros, recurrentes, agrupados o recobros o bien se puede indicar en cada generación de entidad.

Por ejemplo, un cobro que se crea y se comparte recibe la notificación de creado y la notificación de compartido, si se volviera a compartir se generaría otra notificación de compartido. Es decir, se pueden producir notificaciones en el cambio de estado, pero también dentro de cada estado se pueden notificar eventos con el mismo estado. Otro ejemplo sería cuando se completa un pago se notificaría la transación de en proceso a completado, pero también se notificará en el estado completado la liquidación de ese cobro.

En el caso de un recurrente, se puede cambiar la URL de notificación del primer cobro una vez inicializado, y se pueden proporcionar URL de notificación para los cobros manuales o para las programaciones en el caso del plan de pagos. La URL de notificación del primer cobro la heredan todos los cobros, salvo que se proporcione una distinta tanto para los cobros manuales como para las programaciones.

En caso de utilizar una dirección de notificación, si esta fuese una redirección debe de compartir protocolo con el origen y el destino. Se recomienda el uso de HTTPS para cualquier URL que se intercambie con WANNME.

# Tipos notificaciones

Los tipos de notificación pueden ser los siguientes:

# Notificaciones de cobro

La información enviada en las notificaciones de cobro es la siguiente:

{
  "id": "1600329190190828548",
  "checksum": "8b8478cc8e4b14076135183bca4e88653cf848ce",
  "checksum512": "8b8478cc8e4b14076135183bca4e88653cf848ceasdfasdf333333dd",
  "notificationType": "PAYMENT",
  "receiptNumber":"1600329190190828548",
  "transactionCode":"",
  "amount": 50,
  "statusCode": 1,
  "statusDescription": "CREADO",
  "subStatusCode": 0,
  "subStatusDescription": "xxxxxx",
  "partnerReference1": "ref1",
  "partnerReference2": "",
  "uniqueNotificationId": "1600329388963",
  "recurrentPaymentId":"",
  "debtCaseId":"",
  "errorCode":"",
  "errorDescription":"",
  "paymentMethod":"",
  "partnerId":"",
  "customField1":"",
  "customField2":"",
  "customField3":"",
  "customField4":"",
  "customField5":"",
  "customField6":""
}

checksum SHA1(id + uniqueNotificationId + partnerReference1 + clave_privada) DEPRECATED checksum512 SHA512(id + uniqueNotificationId + partnerReference1 + clave_privada)

# Notificaciones de recobro

La información enviada en las notificaciones de recobro es la siguiente:

{
  "id": "1600329190190828548",
  "checksum": "8b8478cc8e4b14076135183bca4e88653cf848ce",
  "checksum512": "8b8478cc8e4b14076135183bca4e88653cf848ceasdfasdf333333dd",
  "notificationType": "DEBT_CASE",
  "statusCode": 1,
  "statusDescription": "CREADO",
  "subStatusCode": 0,
  "subStatusDescription": "xxxxxx",
  "partnerReference1": "ref1",
  "partnerReference2": "",
  "uniqueNotificationId": "1600329388963",
  "partnerId":"",
  "customField1":"",
  "customField2":"",
  "customField3":"",
  "customField4":"",
  "customField5":"",
  "customField6":""
}

checksum SHA1(id + uniqueNotificationId + partnerReference1 + clave_privada) DEPRECATED checksum512 SHA512(id + uniqueNotificationId + partnerReference1 + clave_privada)

# Notificaciones de recurrente

La información enviada en las notificaciones de recurrente es la siguiente:

{
  "id": "1600329190190828548",
  "checksum": "8b8478cc8e4b14076135183bca4e88653cf848ce",
  "checksum512": "8b8478cc8e4b14076135183bca4e88653cf848ceasdfasdf333333dd",
  "notificationType": "RECURRENT_PAYMENT",
  "statusCode": 1,
  "statusDescription": "CREADO",
  "subStatusCode": 0,
  "subStatusDescription": "xxxxxx",
  "partnerReference1": "ref1",
  "partnerReference2": "",
  "uniqueNotificationId": "1600329388963",
  "partnerId":"",
  "debtCaseId":"",
  "customField1":"",
  "customField2":"",
  "customField3":"",
  "customField4":"",
  "customField5":"",
  "customField6":""
}

checksum SHA1(id + uniqueNotificationId + partnerReference1 + clave_privada) DEPRECATED checksum512 SHA512(id + uniqueNotificationId + partnerReference1 + clave_privada)

# Notificaciones de agrupado

La información enviada en las notificaciones de agrupado es la siguiente:

{
  "id": "1600329190190828548",
  "checksum": "8b8478cc8e4b14076135183bca4e88653cf848ce",
  "checksum512": "8b8478cc8e4b14076135183bca4e88653cf848ceasdfasdf333333dd",
  "notificationType": "MERGE_PAYMENT",
  "statusCode": 1,
  "statusDescription": "CREADO",
  "subStatusCode": 0,
  "subStatusDescription": "xxxxxx",
  "partnerReference1": "ref1",
  "partnerReference2": "",
  "uniqueNotificationId": "1600329388963",
  "partnerId":"",
  "customField1":"",
  "customField2":"",
  "customField3":"",
  "customField4":"",
  "customField5":"",
  "customField6":""
}

checksum SHA1(id + uniqueNotificationId + partnerReference1 + clave_privada) DEPRECATED checksum512 SHA512(id + uniqueNotificationId + partnerReference1 + clave_privada)

# Notificaciones de punto de venta

La información enviada en las notificaciones de punto de venta es la siguiente:

{
  "partnerId": "cxfffffs4",
  "checksum": "8b8478cc8e4b14076135183bca4e88653cf848ce",
  "checksum512": "8b8478cc8e4b14076135183bca4e88653cf848ceasdfasdf333333dd",
  "notificationType": "MERCHANT",
  "stateId": "4",
  "stateName": "4/4 .......",
  "merchantReference1":"",
  "merchantReference2":"",
  "uniqueNotificationId": "1600329388963"
}

checksum SHA1(partnerId + uniqueNotificationId + clave_privada) DEPRECATED

checksum512 SHA512(partnerId + uniqueNotificationId + clave_privada)

# 3.6.2. URL's de redirección de cobros

En la creación de un cobro se pueden proporcionar URL's de vuelta (redirección) para los estados de pago correcto o pago con error. WANNME devolverá el control a estas URL's una vez se produzca el pago por parte de cliente tanto en la situación de OK como de KO. Estas URL's desde su creación deben de ir informadas con el identificador necesario para localizar en el sistema destino la entidad relacionada, esto debe hacerse en el query string, puesto que son redirecciones sin cuerpo. Estas URL's pueden ser configuradas por defecto a nivel de partner para todos los cobros o bien se pueden indicar en cada generación de un cobro.

# 3.7. Importación de mandatos SEPA en los cobros

Es posible importar mandatos SEPA ya creados en un cobro, es condición necesaria que previamente el cobro tenga los datos completos del cliente.

# 3.8. Gestión multi idioma

WANNME soporta la internacionalización de los contenidos en varios idiomas. La selección del idioma deseado (ver tabla de códigos) se realiza a través de la cabecera opcional Content-Language que se podrá incluir en cada una de las peticiones realizadas a este API. Si no existiese esta cabecera el idioma por defecto es el Español. Por otro lado, el idioma en el cuál WANNME devuelve los contenidos se especifica en la cabecera Accept-Language que WANNME incluirá en todas sus respuestas.

# 4. Integración APIREST

Para el uso de los end-point proporcionados por WANNME es necesario situar la APIKEY proporcionada en las cabeceras de la llamada. El tipo de cabecera a usar es:

Authorization APIKEY

De no utilizar una credencial valida el sistema responderá con un estado 401 Unauthorized. Estas KEYs caducarán si no son utilizadas en un año.

Se establece otro sistema de seguridad a partir del resumen de determinados datos de la llamada a cada end-point con un algoritmo de resumen. (Para información detallada ver 2.3. Autenticación)

Algunos ejemplos del API-REST para Postman se pueden descargar aqui Collection Environment

# 4.1. Gestión de cobros

Ponemos a disposición de los desarrolladores diversos métodos para la creación y manipulación de cobros en el sistema WANNME. Se pueden crear y actualizar los cobros, así como recuperar la información asociada a los mismos. En el Swagger se encuentra la información necesaria para proporcionar el checksum de cada llamada.

# 4.1.1 Algunas consideraciones sobre el cobro:

• Para la creación del cobro es necesario proporionar de forma obligatoria los campos partnerId, checksum, amount y partnerReference1
• checksum SHA512(partnerId + clave_privada + amount + partnerReference1)
• El campo partnerReference2 es opcional, y junto con el campo partnerReference1 son los identificadores del comercio que permiten localizar el cobro en tu sistema, deben de ser únicos
• Es posible definir a nivel de punto de venta las direcciones de notificación y de retorno OK y KO para no enviarlas en cada creación de cobro. Se examina primero la creación, si existen URL’s se usarán las de la creación, sino se utilizarán las definidas por punto de venta si existen
• El parámetro manualPayment configura el cobro manual. Si se configura a true, no se enviarán sms ni email, si se configura a false los parámetros sendSMS y sendEmail se utilizarán según sean proporcionados

# 4.1.2 Acciones sobre el expediente de cobro

Las acciones que se pueden ejecutar sobre un expediente de cobro son:

• cancel: permite cancelar un cobro existente
• share: permite compartir el cobro y enviar las notificaciones al cliente (sms, email, etc.)
• total-refund: permite realizar una devolución completa del cobro si es posible

# 4.1.3 Pago dividido (Split Payment)

Esta opción permite indicar los diferentes comercios que pueden reciben el importe del cobro realizado. Los receptores serán identificados mediante el identificador del comercio partnerId, y la cantidad amount que les corresponde, será definida según el tipo del pago dividido splitPaymentType, pudiendo ser una cantidad fija (splitPaymentType = "FIXED") o un porcentaje del total (splitPaymentType = "PERCENTAGE").

Para utilizar está opción el cobro deberá incluir una lista con los SplitPayments, teniendo en cuenta:

• Todos los splitPayments deben ser del mismo tipo.
• La suma de las cantidades parciales debe ser igual a la importe del cobro

Cobro: Objeto payment

{
  "partnerId": "string",
  "checksum": "string",
  "amount": 0,
  "description": "string",
  "partnerReference1": "string",
  "partnerReference2": "string",
  "customField1": "string",
  "customField2": "string",
  "customField3": "string",
  "customField4": "string",
  "customField5": "string",
  "customField6": "string",
  "mobilePhone": "string",
  "mobilePhone2": "string",
  "mobilePhone3": "string",
  "email": "string",
  "email2": "string",
  "email3": "string",
  "usersGroup": "string",
  "notificationURL": "string",
  "returnOKURL": "string",
  "returnKOURL": "string",
  "documentId": "string",
  "expirationDate": "2022-06-13T11:00:54.424Z",
  "paymentMethods": [
    "string"
  ],
  "signType": 0,
  "customer": {
    "documentType": 0,
    "document": "string",
    "firstName": "string",
    "lastName1": "string",
    "lastName2": "string",
    "viaType": 0,
    "address": "string",
    "floorStairsDoor": "string",
    "postalCode": "string",
    "location": "string",
    "countryType": 0,
    "provinceType": 0,
    "bankAccountIban": "string"
  },
  "extra": {
    "sendSMS": true,
    "sendEmail": true,
    "manualPayment": true,
    "paymentPassword": "string",
    "tokenizeOnly": true,
    "sendCertifiedSMS": true
  },
  "splitPayments": [
    {
      "partnerId": "string",
      "reference": "string",
      "description": "string",
      //"PERCENTAGE" || "FIXED"
      "splitPaymentType": "string",
      "amount": 0
    }
  ]
}

# 4.2. Gestión de recobros

Ponemos a disposición de los desarrolladores diversos métodos para la creación y manipulación de recobros en el sistema WANNME. Se pueden crear y actualizar los recobros, así como recuperar la información asociada a los mismos. En el Swagger se encuentra la información necesaria para proporcionar el checksum de cada llamada.

Los recobros permiten la gestión de los intervinientes y de los cobros asociados al proceso de recobro.

# 4.2.1 Configuración del recobro

Se puede configurar el recobro con los siguientes atributos en tiempo de creación:

• sendPaymentAllMobilePhones: se enviará la notificación de los cobros a todos los teléfonos configurados en el recobro, sino está activa esta propiedad solo se enviará al teléfono principal
• sendPaymentAllEmails: se enviará la notificación de los cobros a todos los emails configurados en el recobro, sino está activa esta propiedad solo se enviará al teléfono principal
• createTotalAmountPaymentAuto: en tiempo de creación esta propiedad permite la creación automática de un cobro por la totalidad del recobro
• sendPaymentAuto: en caso de estar activada la propiedad createTotalAmountPaymentAuto, se permite el envío automático de las notificaciones por sms, email.
• requestCustomerDocumentInPayment: se solicitará al cliente el DNI como contraseña para acceso a los cobros

# 4.2.2 Acciones sobre el expediente de recobro

Las acciones que se pueden ejecutar sobre un expediente de recobro son:

• cancel: permite cancelar un recobro existente

Recobro: Objeto debt-case

{
  "partnerId": "partnerId_comercio",
  "checksum": "campo_calculado",
  "amountTotalDebt": 500,
  "amountPrincipalDebt": 50,
  "amountPending": 490,
  "amountRealDiscount": 10,
  "amountMaximumDiscount": 20,
  "amountMinimumPartialPayment": 30,
  "amountExternalPayment": 0,
  "description": "",
  "mobilePhone1": "",
  "mobilePhone2": "",
  "mobilePhone3": "",
  "email1": "",
  "email2": "",
  "email3": "",
  "dueDate" : "",
  "partnerReference1" : "",
  "partnerReference2": "",
  "documentURL1": "",
  "documentURL2": "",
  "documentURL3": "",
  "usersGroup" : "",
  "notificationURL":"",
  "mainCustomer" : {
    "address": "",
    "bankAccountIban": "",
    "document": "",
    "documentType": 0,
    "firstName": "",
    "floorStairsDoor": "",
    "lastName1": "",
    "lastName2": "",
    "location": "",
    "postalCode": "",
    "provinceType": 0,
    "viaType": 0
  },
  "creditor" : {
    "bankAccountHolderName": "",
    "bankAccountIban": "",
    "bankAccountSwift": "",
    "brandName": "",
    "debtCaseManagementType": 0,
    "document": "",
    "documentType": 0,
    "judicialStateType": 0,
    "name": ""
  },
  "extra" : {
      "sendPaymentAllMobilePhones" : false,
      "sendPaymentAllEmails" : false,
      "createTotalAmountPaymentAuto" : false,
      "sendPaymentAuto" : false,
      "requestCustomerDocumentInPayment" : false   
  }
}

Objeto debt-case-customer

{
  "mobilePhone1": "",
  "mobilePhone2": "",
  "mobilePhone3": "",
  "email1": "",
  "email2": "",
  "email3": "",
  "documentType": 0,
  "document": "",
  "firstName": "",
  "lastName1": "",
  "lastName2": ""
}

# 4.3. Gestión de recurrentes

Un expediente recurrente permite planificar un conjunto de cobros en el tiempo pudiendo hacerse de forma libre (plan de pagos) o de forma recurrente (suscripción). Ponemos a disposición de los desarrolladores diversos métodos con los que se pueden crear y actualizar expedientes recurrentes en el sistema WANNME, así como recuperar la información asociada a los mismos. En el Swagger se encuentra la información detallada de cada petición así como la información necesaria para proporcionar el checksum de cada una de ellas.

# Tipos de recurrente

Un expediente recurrente puede ser una suscripción o un plan de pagos. La diferencia entre ellos es que la suscripción permite la generación de cobros de importe igual y periodicidad constante, mientras que los planes de pago permiten la generación de cobros planificados o no, de cantidades distintas y periodicidades también distintas.

En la creación del recurrente se deberá definir si se trata de un plan de pagos o de una suscripción mandando la definición correspondiente. Solo debe mandarse la estructura subscription o paymentPlan que corresponda, en caso de mandar las dos la petición fallará.

# Definición de plan de pagos

Un plan de pagos se define incluyendo la estructura paymentPlan, que solo contiene el atributo finalizeRecurrent que configura si el recurrente debe ser finalizado al ejecutar la última de sus programaciones.

paymentPlan: Estructura interna que define un plan de pagos

{
  ...  
  "paymentPlan": {
    "finalizeRecurrent": false
  }
  ...
}

# Definición de suscripción

Una suscripción se define incluyendo la estructura subscription, con los siguientes atributos:

• amount: cantidad en euros de cada cuota
• intervalType: intervalo de la recurrencia (tipos).
• startDate: fecha en la que comienza la recurrencia. Si está vacía en el momento de la inicialización, se tomará ese instante como fecha de inicio. Puede ser una fecha pasada.
• endDate: fecha en la que finaliza la recurrencia (opcional). Tiene que ser posterior a la fecha de inicio.
• amountFirstInstallment: cantidad para la cuota inicial (opcional). Esta cantidad es independiente del importe definido para el ciclo de recurrencia. Si no se define una fecha especial para esta cuota inicial a traves de firstInstallmentDate, esta cantidad será añadida a la primera cuota del ciclo de recurrencia.
• firstInstallmentDate: fecha de ejecución de la cuota inicial (opcional). Tiene que ser anterior a la fecha de inicio. En esta fecha se creará un primer cobro independiente de la recurrencia, si no se ha definido importe en amountFirstInstallment y el recurrente es de ejecución automática, llegada esta fecha se generará un primer cobro de importe 0, que permitirá poder capturar el método de pago del cliente en la fecha deseada anterior al comienzo de la recurrencia.

subscription: Estructura interna que define una suscripción

{
  ...
  "subscription" : {
    "amount":120,
    "intervalType":0,
    "startDate":"2023-01-23T12:34:56.123456789Z",
    "endDate":"2024-01-23T12:34:56.123456789Z",
    "amountFirstInstallment":33.33,
    "firstInstallmentDate":"2022-01-23T12:34:56.123456789Z"
  }
  ...
}

Trás la creación del recurrente, esta estructura incluirá también el atributo nextInstallmentDate, representando la fecha de la próxima cuota de la recurrencia, pudiendo ser modificada incluyendo este atributo en la petición de modificación.

# Modos de ejecución de cobros

Los recurrentes tienen dos modos diferentes para ejecutar sus cobros, ejecución automática o ejecución manual. En la modalidad automática se permite la captura de un medio de pago del cliente para posteriormente poder cargarle cobros sin su intervención. Por el contrario, en la modalidad manual, no se captura ningún método de pago del cliente, los cobros son simplemente creados. Si se desea se puede configurar que los cobros de un recurrente manual sean, compartidos de forma automática por email y sms.

# Configuración del recurrente

El recurrente tiene una serie de funcionalidades que pueden ser configuradas mediante su objeto de configuración:

config: estructura del objeto de configuración

{
  ...
  "config": {
        "executePastSchedulesAfterActivation": true,
        "sharingConfig": {
            "sendToAllPhones": false,
            "sendToAllEmails": false
        },
        "firstPaymentConfig": {
            "sharingConfig": {
                "shareBySms": true,                
                "smsTemplateId": null,
                "shareByEmail": true,
                "emailTemplateId": null
            }
        },        
        "manualExecutionConfig": {
            "enable": false,
            "sharingConfig": {
                "shareBySms": true,
                "smsTemplateId": null,
                "shareByEmail": false,
                "emailTemplateId": null
            }
        },
        "schedulePriorNoticeConfig": {
            "enable": false,
            "numberOfDays": null,
            "sharingConfig": {
                "shareBySms": true,
                "smsTemplateId": null,
                "shareByEmail": true,
                "emailTemplateId": null
            }
        }
    }
  ...
}

Si en la petición de creación de un recurrente no se manda este objeto, el recurrente creado será configurado por defecto. Si en la modificación de un recurrente no se manda este objeto no se verán alterados los valores actuales de la configuración.

# Apartados de la configuración

El objeto de configuración tiene 5 apartados:

• Ejecución de cuotas pasadas tras activación - executePastSchedulesAfterActivation: esta opción permite que cuando el recurrente sea activado, también durante la inicialización, se ejecuten aquellas cuotas programadas cuya fecha haya pasado. Por defecto está activado.
• Configuración general de compartir - sharingConfig: en este apartado se puede configurar a modo general si se desea que cuando se manden mensajes al cliente se hagan a todos sus teléfonos (sendToAllPhones) y/o a todos sus correos (sendToAllEmails). Por defecto se comparte solo al telefono e email principal.
• Configuración relacionada al primer cobro - firstPaymentConfig: este apartado configura los mensajes que comparten con el cliente el primer cobro. Esto se realiza a través de un objeto de configuración de compartir. El primer cobro puede ser con importe o en el caso de los recurrentes de ejecución automática también puede ser de importe 0. En función de como sea el cobro, se deberá elegir la plantilla deseada correspondiente. De no elegir ninguna se utilizará la plantilla predeterminada. La configuración de compartir el primer cobro puede ser sobreescrita en el momento de la inicialización. Ver inicialización del recurrente.
• Ejecución manual - manualExecutionConfig: este apartado permite cambiar el modo de ejecución a manual. Se activa con el atributo enable y se puede configurar el envío de las cuotas mediante un objeto de configuración de compartir. El recurrente por defecto ejecuta sus cobros de modo automático.
• Preaviso de programaciones - schedulePriorNoticeConfig: este apartado permite mandar mensajes de preaviso de las cuotas, por defecto desactivado. Se activa con el atributo enable, numberOfDays define el número de días previos a la cuota en que se mandarán los mensajes y el envío de las estos se configura mediante un objeto de configuración de compartir.

# Configuración de compartir

El objeto sharingConfig, incluido en algunas de las configuraciones, permite definir si se mandan mensajes al cliente por sms (shareBySms) y/o email (shareByEmail) y que plantillas se usan (smsTemplateId y emailTemplateId). Por defecto tiene activado el envío tanto por sms como por email y no tiene plantilla seleccionada por lo que usará las predeterminadas.

# Funcionamiento del recurrente

Un expediente recurrente puede ser de tipo plan de pagos o de tipo suscripción. En tiempo de creación se deber proprocionar la información para determinar de que tipo de recurrente se trata. Si es una suscripción es necesario proporcionar una cantidad y un tipo de periodicidad, es decir, una frecuencia de recurrencia. Un plan de pagos puede ser creado e incluso inicializado sin que tenga programaciones, que podrán ser añadidas posteriormente.

# Modificación de un recurrente

Un recurrente puede ser modificado mientras está en estado CREADO o DETENIDO, si ha sido inicializado.

Antes de ser inicializado es posible cambiar el tipo de recurrencia entre plan de pagos y suscripción y el modo de ejecución entre automático y manual.

En el caso de las suscripciones, después de la inicialización no se podrá cambiar la fecha de inicio (startDate), solo modificable en periodo de creación. Una vez EN PROCESO, el resto de atributos podrán ser modificados, siempre que se detenga, incluida la fecha de próxima cuota nextInstallmentDate (atributo añadido en la inicialización). Toda suscripción que ya haya sido inicializada va a tener siempre valores en los atributos de fecha de inicio y de próxima cuota, si se mandase una petición de modificación sin incluir alguno de estos dos valores, se mantendrán los valores actuales.

# Gestión de programaciones

Los planes de pagos pueden gestionar sus programaciones sin que tenga que ser detenido, pudiendo crear, modificar y eliminar programaciones, así como recuperar la lista de ellas.

# Acciones sobre el expediente recurrente

Sobre un expediente recurrente se pueden ejecutar las siguientes acciones:

• /initialize: comienza la inicialización del recurrente (estado EN PROCESO).
• /pause: permite detener la recurrencia del expediente recurrente (estado DETENIDO). Debe ser detenido para poder ser modificado
• /resume: permite reanudar la recurrencia del expediente recurrente que previamente ha sido detenido (estado EN PROCESO).
• /cancel: permite cancelar un expediente recurrente existente (estado CANCELADO)
• /manual-payment: permite ejecutar un cobro manual (solo en recurrentes de ejecución automática)

# Inicialización de un recurrente (.../action/initialize)

Una vez creado el expediente recurrente (estado CREADO) debe de ser inicializado a través de la acción initialize con lo que comienza el ciclo de recurrencia (estado EN PROCESO).

Si existe una cuota que ejecutar en el momento de la inicialización se creará el cobro correspondiente. Si no existe dicha cuota pero se trata de un recurrente automático, se generará también un primer cobro pero en este caso de importe 0. El primer cobro de un recurrente automático, tenga o no importe, deberá ser completado por el cliente para almacenar su método de pago y así poder ejecutar posteriormente las cuotas. En caso de ser generado, el primer cobro será devuelto en la respuesta a la petición de inicialización. Esta petición permite la redefinición de la configuración de compartir el primer cobro a través de los atributos sendPaymentAuto que permite configurar que se comparta el primer cobro y sendPaymentToAllEmails y sendPaymentToAllPhones que especifica si se debe compartir a todos los correos y/o telefonos disponibles.

En el caso de una suscripción que tenga fecha de inicio pasada o de un plan de pagos con programaciones con fecha de programación pasada, en la inicialización entra en juego el atributo de configuración executePastSchedulesAfterActivation que en caso de estar activo, valor por defecto, generará cobros para las cuotas correspondientes al periodo entre la fecha de inicio y la fecha actual.

# Inicialización de una suscripción

Aunque una suscripción sea automática, si la fecha de inicio (startDate) es futura y tiene definido una fecha para la cuota inicial (firstInstallmentDate), no se creará el primer cobro durante la inicialización ya que será creado en la fecha definida.

# Pausa de un recurrente (.../action/pause)

En ocasiones se desea detener (estado DETENIDO) una recurrencia para por ejemplo poder realizar alguna modificación (no es posible modificar un recurrente que esta en marcha) o pausar la ejecución de las cuotas o programaciones (verificar el atributo executePastSchedulesAfterActivation para definir el comportamiento que debe tener al volver a activarlo). Solo es posible detener recurrentes en proceso (estado EN PROCESO).

# Activación de un recurrente (.../action/resume)

Esta acción vuelve a poner en marcha (estado EN PROCESO) el recurrente. En este momento si el atributo de configuración executePastSchedulesAfterActivation esta activo, se ejecutarán aquellas cuotas programadas cuya fecha haya pasado.

# Cancelación de un recurrente (.../action/cancel)

Con esta acción se cancela el recurrente, lo que provocará la cancelación de todas las programaciones que tenga programadas y de todos aquellos cobros generados que no hayan sido completados o cancelados.

La cancelación deja al recurrente en el estado finalizasta CANCELADO. No se puede cancelar un recurrente que haya sido COMPLETADO.

# Cobro manual (.../action/manual-payment)

Un recurrente con ejecución automática de las cuotas permite realizar en cualquier momento cobros manuales manual-payment, es decir la generación y ejecución de sobre el método de pago almacenado de un cobro por un importe distinto al marcado en la suscripción o en las programaciones del plan de pagos.

# Cobros en error

En el caso de los recurrentes de ejecución automática, si su primer cobro fallase, estando su estado en ERROR, el recurrente pasará también a ERROR hasta que se solucione la incidencia.

Durante el ciclo de recurrencia si alguna cuota del recurrente falla (cobro en estado de ERROR), el recurrente reflejará esta situación a través de su subestado CUOTAS CON ERROR. El API dispone de métodos que permiten efectuar acciones sobre cobros en error:

• Reintento: un recurrente con ejecución automática de las cuotas permite reintentar un cobro que haya fallado mediante la invocación de la acción (.../action/retry). Intentará de nuevo cobrar la cuota usando el método de pago capturado.
• Reseteo: También es posible resetear un cobro en error de un recurrente a través de los endpoint del cobro payment/reset.

# Finalización del recurrente

# Finalización de planes de pago

Un plan de pagos podrá ser finalizado si está configurado para que se finalice tras la ejecución de su última programación mediante su atributo finalizeRecurrent.

# Finalización de suscripciones

Una suscripción podrá ser finalizada si su fecha de fin es excedida y no tiene cuotas pendientes o en error.

Un recurrente no podrá ser finalizado mientras que alguna de sus cuotas esté en error o no haya sido pagada. Su finalización además dependerá de si es plan de pagos o suscripción.

Cuando un recurrente es finalizado su estado pasa a COMPLETADO y es complementado con uno de los siguientes subestados: Cuotas finalizadas, Con cuotas reembolsadas, Con cuotas canceladas o Con cuotas reembolsadas y canceladas.

# Objeto recurrente

A continuación la estructura completa del expediente recurrente. Incluye las estructuras de los dos tipo de recurrente posibles, suscripción y plan de pagos, de los que se espera solo uno en las peticiones, con los dos simultáneamente fallará. Además la estructura de la suscripción incluye la fecha de próxima cuota nextInstallmentDate, atributo que es añadido a partir de la inicialización.

Recurrente: Objeto recurrent-payment

{
  "partnerId": "partnerId_comercio",
  "checksum": "campo_calculado",
  "description": "",
  "mobilePhone": "",
  "mobilePhone2": "",
  "mobilePhone3": "",
  "email": "",
  "email2": "",
  "email3": "",
  "partnerReference1" : "",
  "partnerReference2": "",
  "notificationURL":"",
  "usersGroup": "string",
  "subscription" : {
    "amount":120,
    "intervalType":0,
    "startDate":"2023-01-23T12:34:56.123456789Z",
    "endDate":"2024-01-23T12:34:56.123456789Z",
    "amountFirstInstallment":33.33,
    "firstInstallmentDate":"2022-01-23T12:34:56.123456789Z",
    "nextInstallmentDate":"2023-05-23T12:34:56.123456789Z"
  },
  "paymentPlan": {
    "finalizeRecurrent": false
  },
  "customer": {
    "address": "",
    "bankAccountIban": "",
    "document": "",
    "documentType": 0,
    "firstName": "",
    "floorStairsDoor": "",
    "lastName1": "",
    "lastName2": "",
    "location": "",
    "postalCode": "",
    "provinceType": 0,
    "viaType": 0
  },
  "config": {
        "executePastSchedulesAfterActivation": true,
        "sharingConfig": {
            "sendToAllPhones": false,
            "sendToAllEmails": false
        },
        "firstPaymentConfig": {
            "sharingConfig": {
                "shareBySms": true,                
                "smsTemplateId": null,
                "shareByEmail": true,
                "emailTemplateId": null
            }
        },        
        "manualExecutionConfig": {
            "enable": false,
            "sharingConfig": {
                "shareBySms": true,
                "smsTemplateId": null,
                "shareByEmail": false,
                "emailTemplateId": null
            }
        },
        "schedulePriorNoticeConfig": {
            "enable": false,
            "numberOfDays": null,
            "sharingConfig": {
                "shareBySms": true,
                "smsTemplateId": null,
                "shareByEmail": true,
                "emailTemplateId": null
            }
        }
    }
}

# 4.4. Gestión de agrupados

Un expediente agrupado permite dividir un importe a pagar entre diferentes fuentes de pago, que serán especificadas mediante las Definiciones de cobro (Slices). Una vez inicializado el agrupado (/initialize), cada Slice definido generará un cobro individual y tanto el agrupado como sus definiciones de cobro pasarán a estar en proceso IN_PROGRESS. Un expediente agrupado será completado COMPLETED cuando todos sus cobros sean pagados de forma exitosa. Dos acciones pueden detener el proceso de un expediente agrupado, por un lado, la invocación de la cancelación (/cancel) y por otro la caducidad, en el caso de haber sido definida una fecha de caducidad y que esta haya sido superada. En ambos casos se procederá a la finalización de los cobros, lo que implica que los que hayan sido pagados serán reembolsados y los que no, serán cancelados.

# 4.4.1 Uso de expedientes agrupados

El API de integración presenta métodos para la gestión de los expedientes agrupados. Un expediente agrupado está formado por la información básica de la entidad y el conjunto de definiciones de cobros. La información básica de la entidad contiene datos que definen al agrupado, como URL's, meta información, información de cliente, configuración, etc. El conjunto de definiciones de cobro permite especificar cuantos cobros va a generar el agrupado en el proceso de inicialización y determinada información asociada a cada uno de los cobros. La suma de todas las cantidades de las definiciones debe de ser igual al importe definido en el agrupado.

De esta forma la principal característica del expediente agrupado es que para considerar esta entidad como finalizada, deben de finalizarse todos los cobros definidos y generados en el proceso de inicialización. La cancelación en cualquier momento del expediente agrupado conlleva la cancelación de los cobros y su reembolso en caso de haber sido abonados. Esta cancelación puede producirse en cualquier momento desde que el agrupado es inicializado, ya sea por expiración de la fecha de caducidad (si existiese) o por la cancelación del agrupado mientras este se encuentre en proceso o finalizado.

# 4.4.2 Pago dividido en expediente agrupado

El expediente agrupado permite utilizar la modalidad de pago dividido en los cobros. Para ello las definiciones de cobro (slices) deberán incluir las definiciones del pago dividido splitPayments y ser del tipo SPLIT_PAYMENT.

{
  ...
  "slices": [
    {
      ...
      "type": "SPLIT-PAYMENT",
      ...      
    }],
  ...
}

Para la utilización de cobro sin pago dividido el tipo de los slices será: STANDARD_PAYMENTS

# 4.4.3 Creación y modificación

Ponemos a disposición de los desarrolladores diversos métodos para la creación y manipulación de expedientes agrupados en el sistema WANNME. Se pueden crear y actualizar los expedientes agrupados, así como recuperar la información asociada a los mismos. En el Swagger se encuentra la información necesaria para proporcionar el checksum de cada llamada.

Una petición de creación o modificación de un expediente agrupado puede incluir, de forma opcional, la lista con las definiciones de cobro (slices) para ser creadas o modificadas, así como las definiciones de pago dividido (splitPayments) en el caso de la utilización de esta modalidad. Una petición de modificación podrá modificar y/o añadir nuevos slices y/o splitPayments, teniendo en cuenta que los que deben ser modificado serán reconocibles por la presencia de su id asociado. En ningún caso una petición de modificación eliminiará slices o splitPayments que no estén incluidos en las respectivas listas. Su eliminación debe realizarse de forma individual a través de los end-points para la eliminación de slices y la eliminación de splitPayments

No se pueden realizar modificaciones en un agrupado ya iniciado, finalizado o cancelado.

# 4.4.4 Acciones sobre cobros creados

La información extra permite configurar acciones que se efectuarán sobre los cobros creados en la ejecución del proceso de inicialización. Las acciones configurables son las siguientes:

• sendAuto: el cobro generado será compartido automáticamente (requiere la definición del email y/o el teléfono del cliente en la definición del cobro).
• rtpFirst: tras la generación del cobro se intentará enviar el cobro por RTP (Request To Pay) al teléfono definido (requerido). Si no es posible y sendAuto esta activo, se compartirá el cobro, en caso contrario no se actuará sobre el cobro generado.

Si no se activa ninguna de estas siguientes características, los cobros serán generados a partir de las definiciones y no se realizará ninguna acción sobre ellos.

# 4.4.5 Acciones sobre el expediente agrupado

Las acciones que se pueden ejecutar sobre un expediente agrupado son:

• initialize: con un expediente agrupado creado y configurado correctamente, invocar a la acción initialize para ponerlo en proceso.
• cancel: permite cancelar un expediente agrupado en proceso, los cobros que hayan sido pagados serán reembolsados y los que no, serán cancelados.

Agrupado: Objeto merge-payment

{
  "partnerId": "string",
  "checksum": "string",
  "amount": 0,
  "description": "string",
  "expirationDate": "2022-06-13T08:46:29.714Z",
  "usersGroup": "string",
  "notificationURL": "string",
  "documentId": "string",
  "partnerReference1": "string",
  "partnerReference2": "string",
  "customField1": "string",
  "customField2": "string",
  "customField3": "string",
  "customField4": "string",
  "customField5": "string",
  "customField6": "string",
  "customer": {
    "documentType": 4,
    "document": "string",
    "firstName": "string",
    "lastName1": "string",
    "lastName2": "string",
    "viaType": 34,
    "address": "string",
    "floorStairsDoor": "string",
    "postalCode": "string",
    "location": "string",
    "provinceType": 52,
    "countryType": 237,
    "mobilePhone": "string",
    "mobilePhone2": "string",
    "mobilePhone3": "string",
    "email": "string",
    "email2": "string",
    "email3": "string"
  },
  "slices": [
    {
      //"STANDARD_PAYMENT" || "SPLIT_PAYMENT"
      "type": "string",
      "amount": 0,
      "description": "string",
      "notificationURL": "string",
      "customer": {
        "documentType": 4,
        "document": "string",
        "firstName": "string",
        "lastName1": "string",
        "lastName2": "string",
        "viaType": 34,
        "address": "string",
        "floorStairsDoor": "string",
        "postalCode": "string",
        "location": "string",
        "provinceType": 52,
        "countryType": 237,
        "mobilePhone": "string",
        "mobilePhone2": "string",
        "mobilePhone3": "string",
        "email": "string",
        "email2": "string",
        "email3": "string"
      },
      "splitPayments": [
        {
          "splitPartnerId": "string",
          "reference": "string",
          "description": "string",
          //"PERCENTAGE" || "FIXED"
          "splitPaymentType": "string",
          "amount": 0
        }
      ]
    }
  ],
  "extra": {
    "sendAuto": true,
    "rtpFirst": true
  }
}

# 4.5. Gestión de merchants

Ponemos a disposición de los desarrolladores diversos métodos para la creación y manipulación de Merchants en el sistema WANNME. Se pueden crear y actualizar los Merchants, así como recuperar la información asociada a los mismos. Los Merchants permiten también la gestión de los métodos de pago, como es el caso de Redsys o PayIn7. Un método de pago se pude inicializar, actualizar y desactivar. Al momento de inicializar un método de pago hay que pasar una URL de notificación, tal y como se indica en la sección 3.9. Sumado a lo ya mencionado, también es posible la personalización de la página web del PayCheckout, como es el cambio de textos, tipos de letras e imágenes, por mencionar algunos de los cambios disponibles.

La asignación de un documento a un merchant, se explica en la sección 4.5.

# 4.5.1 Configuración del proceso de checkout

Existe la posibilidad de activar o desactivar la personalización del proceso de checkout para los comercios creados. Por defecto, WANNME proporciona una imagen y textos para el proceso, pero es posible alterar esta configuración a través del end-point /wannmepay/merchant/{partnerId}/checkout-branding.

{
    "partnerId": "7x53juavzcx_upvh_in8_z2bp",
    "checksum": "62b7134f9b1bd13fcf6237b701025662b7931070",
    
    "checkoutBrandingActive": false,
    
    "headerBackgroundColor": null,
    "titlesTextColor": null,
    "textColor": null,
    "buttonTextColor": null,
    "buttonBackgroundColor": null,
   
    "showReceiptButton": false,
    "showSendReceiptByEmailButton": false,
    "showRequestInvoiceButton": false,
    "hideHeader": false,
    "showLanguageSelection": false,

    "footerOwnWebURL": null,
    "footerPrivacyPolicyURL": null,
    "footerCookiesURL": null,
   
    "logoDocumentId": ""    
}

# 4.5.2 Personalización de textos del proceso de checkout

Es posible la edición de algunos textos presentes en el Paycheckout. Llamando al end-point /wannmepay/masterdata/checkout-branding-translation-types se obtienen la lista de esos textos personalizables con una pequeña explicación de cada uno.

Además de existir esos textos personalizables, también existe la posibilidad de personalizarlos para cada uno de los idiomas disponibles en el sistema. Se pueden obtener los idiomas disponibles en el sistema llamando al end-point /wannmepay/masterdata/languages.

Para saber cuáles son esos textos personalizados en todos los idiomas disponibles asociados al punto de venta que se mostrarán en el Paycheckout, se debe llamar al end-point /wannmepay/merchant/{partnerId}/checkout-branding/translations/list. En esta llamada recibiremos todos los textos tenga o no activado el punto de venta la personalización del Paycheckout.

Si el punto de venta tiene activada la personalización del Paycheckout y quiere modificar alguno de esos textos, se hará uso del end-point /wannmepay/merchant/{partnerId}/checkout-branding/translations donde se informará para cada uno de los textos que se quiera personalizar, un texto para cada uno idioma.

{
     "partnerId": "7x53juavzcx_upvh_in8_z2bp",
     "checksum": "62b7134f9b1bd13fcf6237b701025662b7931070",
     "translations": [
        {
            "code": "commerce.info.label",
            "values": [
                {
                    "language": "de",
                    "value": "Handelsdaten"
                },
                {
                    "language": "en",
                    "value": "Merchant information"
                },
                {
                    "language": "es",
                    "value": "DATOS DEL COMERCIO"
                },
                {
                    "language": "fr",
                    "value": "DATOS DEL COMERCIO [FR]"
                },
                {
                    "language": "pt",
                    "value": "DATOS DEL COMERCIO [PT]"
                }
            ]
        },
        ................................
        {
            "code": "viacash.title",
            "values": [
                {
                    "language": "de",
                    "value": "Barzahlung "
                },
                {
                    "language": "en",
                    "value": "Cash payment"
                },
                {
                    "language": "es",
                    "value": "Pagar en efectivo"
                },
                {
                    "language": "fr",
                    "value": "Payer en espces"
                },
                {
                    "language": "pt",
                    "value": "Payer en PT"
                }
            ]
        }
    ]
}

Solo deben indicarse los que se quieran crear o modificar en cada llamada, no afectando a los creados o modificados anteriormente. Para eliminar una personalización, se debe enviar el idioma sin indicar el valor del texto personalizado.

Por ejemplo: Se quiere borrar el texto personalizado return.store.text en alemán y añadir o modificar la personalización del texto en español.

{
    "partnerId": "7x53juavzcx_upvh_in8_z2bp",
    "checksum": "62b7134f9b1bd13fcf6237b701025662b7931070",
    "translations": [
        {
            "code": "return.store.text",
            "values": [
                {
                    "language": "de"
                },
                {
                    "language": "es",
                    "value": "Volver a la tienda"
                }
            ]
        }
    ]
}

# 4.6. Gestión de documentos

Ponemos a disposición de los desarrolladores diversos métodos para la creación y manipulación de Documentos en el sistema WANNME. Se puede subir documentos, obtener el documento subido y eliminar el documento.

El documento se sube en Base64, y los tipos válidos son los siguientes:

• PNG
• PDF
• GIF
• JPG
• JPEG
• CSV

En caso que todo haya salido correctamente la respuesta será la siguiente:

{
    "partnerId": "7x53juavzcx_upvh_in8_z2bp",
    "checksum": "62b7134f9b1bd13fcf6237b701025662b7931070",
    "documentType": "MERCHANT_COMPANY_SHAREHOLDER_IDENTIFICATION_CARD",
    "content": null,
    "fileName": "genericDNI.pdf",
    "contentType": "application/pdf",
    "id": "7a1e968c17d83d5557a99d80184304534acb358b3f5ec4637f9c25877a6d6610"
}

Para asignar un documento a un punto de venta (merchant) nuevo o ya existente, se debe primero subir el documento y luego asignarlo a la propiedad correspondiente. En el ejemplo, el Id del documento fue asignado al campo: registrationDocumentId.

 "documents": 
 {
    "registrationDocumentId": "7a1e968c17d83d5557a99d80184304534acb358b3f5ec4637f9c25877a6d6610",
    "taxIdDocumentId": "0",
    "bankAccountOwnershipVerificationId": "0",
    "shareholderIdentificationCardId": "0",
    "realOwnershipDocumentId": "0"
}

# 4.7. Gestión de datos maestros

A continuación presentamos algunos datos maestros que estan disponibles a través de los end-point de maestros en el api.

# Tipos de documento

Los documentos pueden ser de los siguientes tipos:

URL de consulta: integration/v2/wannmepay/masterdata/document-types

Es importante señalar que el tipo de documento va siempre acompañado del documento identificativo personal en las entidades de WANNME, y ese conjunto de datos tienen una validación en particular. En el caso de proporcionar estos datos, deben proporcionarse los dos. Sino se proporcionan no se debe informar de ninguno. Si se proporcionan deben de ser una combinación válida. El documento tiene que ser válido según el tipo de documento proporcionado, excepto el tipo 5 que no se realiza ninguna validación.

# Tipos de intervalos de recurrencia

Los intervalos pueden ser de los siguientes tipos:

URL de consulta: integration/v2/wannmepay/masterdata/recurrent-interval-types

# Tipos de gestión de recobro

Las gestiones pueden ser de los siguientes tipos:

URL de consulta: integration/v2/wannmepay/masterdata/debt-case-management-types

# Tipos de estados judiciales de un recobro

Los estados judiciales pueden ser de los siguientes tipos:

URL de consulta: integration/v2/wannmepay/masterdata/debt-case-judicial-state-types

# Tipos de punto de venta

Los tipos de punto de venta pueden ser:

URL de consulta: integration/v2/wannmepay/masterdata/merchant-types

# Métodos de pago de un cobro

Cuando se crea un cobro es posible indicar que en el proceso de checkout del cobro únicamente aparezcan algunos métodos de pago, y no todos los que tiene contratado el punto de venta con WANNME. Esto se hace a través del atributo paymentMethods que permite una lista de alguno/s de los siguientes valores. Sino se indica ningún valor, en el checkout aparecerán todos los métodos, si se especifica algun/os valor/es, únicamente aparecerán esos, si están contratados en WANNME.

# Tipos vías

Los tipos de vías pueden ser de los siguientes:

URL de consulta: integration/v2/wannmepay/masterdata/via-types

# Tipos de firma

Los tipos de firma pueden ser de los siguientes:

# Provincias

Las provincias pueden ser de los siguientes:

URL de consulta: integration/v2/wannmepay/masterdata/provinces

# Países

Los países pueden ser de los siguientes:

URL de consulta: integration/v2/wannmepay/masterdata/countries

El listado completo de países esta disponible en el endpoint descrito anteriormente.

# Estados de facturas de recobro

# Tipos de documento para la gestión documental

Se especifican a continuación los posibles valores para el tipo de documento documentType en la subida física de ficheros al repositorio documental de WANNME:

URL de subida de documentos: integration/v2/wannmepay/document/upload-document

# 4.8. Gestión de errores provocados

En los entornos de desarrollo de WANNME se pueden provocar diferentes situaciones de error para comprobar el funcionamiento de la integración ante situaciones anómalas. El funcionamiento de esta gestión de errores es proporcionar diferentes valores en algunos campos significativos como se detalla a continuación.

# 4.9. Datos de prueba para los medios de pago de un cobro

A continuación presentamos datos de prueba para las diferentes pasarelas de pago.

# 4.9.1 Redsys

https://pagosonline.redsys.es/entornosPruebas.html

# 4.9.2 Cecabank

# 4.9.3 Afterbanks

Credenciales de acceso a los bancos de sandbox

# 4.9.4 PayPal

Solicitar a WANNME las credenciales de acceso al entorno de sandbox

# 4.9.5 Bizum

Para la realización de pruebas de Bizum, se podrán realizar contra la URL de pruebas, pero se tendrá que tener en cuenta que la cuantía de la operación no puede superar los 10€. Para hacer estas pruebas, se puede habilitar un cupón de descuento temporal en la tienda que descuente el 95% del precio para así no pasarnos del importe máximo.

Los datos para realizar las pruebas son:

# 4.9.6 GoCardLess

Para los mandatos SEPA es necesario seleccionar el país Francia y el IBAN FR1420041010050500013M02606

# 4.9.7 Pepper

PIN de pruebas 1111

Tarjeta 1 de pruebas PAN: 4018 8100 0015 0015 Cad: 12/34 CVV: 123 Código OTP (3DS) válido: 0101

Tarjeta 2 de pruebas PAN: 5555 5555 5555 4444 Cad: 03/30 CVV: 737 Código OTP (3DS) válido: 123456

# 4.9.8 Floa

# 4.10. Notas integración APIREST

Cosas que debes tener en cuenta para el correcto funcionamiento de la integración:

1. Formato de fechas: yyyy-MM-dd'T'HH:mm:ss.SSSZ
2. El checksum se calculará como el resumen en SHA512 de la cadena especificada en cada método. (Recuerda que la clave privada debe almacenarse únicamente en tu servidor y generar de forma dinámica el checksum para cada método)
3. Es necesario proporcionar la cabecera Authorization con la APIKEY de las credenciales para el uso del APIREST
4. Ponemos a disposición de los desarrolladores un Swagger para la comprobación de los detalles de los end-point
5. Es posible incluir en las cabeceras de las peticiones la clave Content-Language con un valor ISO de idioma para la obtención de los contenidos localizados en el idioma proporcionado. Los idiomas disponibles de pueden obtener en el end-point /wannmepay/masterdata/languages
6. Los valores de tipo double especificados en los end-point usados para el proceso de firma no deben incoporar los ceros no necesarios a la derecha de la coma. Por ejemplo, el valor 33,5 es un valor distinto a 33,50 para el calculo de la firma. Es decir, los atributos de tipo double deben de ser enviados como tipo numérico y no como cadenas de caracteres, si se pasa a cadena de texto para ser enviado deben de eliminarse los ceros no significativos
7. Algunos ejemplos del API-REST para Postman se pueden descargar aqui Collection Environment
8. En el caso de usar las búsquedas en las entidades a través de los métodos search se puede indicar de forma opcional la paginación deseada en los resultados. Para ello se puede proporcionar el número de página deseado page (comenzando en la página 0) y el número de registros esperados size dentro de esa página.

# 5. Integración comercio electrónico

WANNME disponse de módulos o plugins para su integración en los portales de comercio electrónico o CMS, mostrando WANNME como una opción de pago más dentro del proceso de compra de los sitios web. La lista de CMS actualmente soportada por WANNME es la siguiente:

CMS	Descarga plugin
	Última versión
	Última versión

# 5.1. Prestashop

Versiones soportadas de PrestaShop:

• 1.6
• 1.7

Requisitos obligatorios:

• PHP 7 o superior

Notas:

• Es necesario configurar el plugin para la comprobación de las actualizaciones
• No necesita base de datos adicional

# 5.2. Wordpress - WooCommerce

Requisitos obligatorios:

• WooCommerce instalado
• PHP 7 o superior

Notas:

• Es necesario configurar el plugin para la comprobación de las actualizaciones
• No necesita base de datos adicional