Bizum

Introducción

Bizum es un método de pago inmediato que asocia el número de teléfono móvil del cliente a su cuenta bancaria. Al integrarlo en tu comercio, podrás aceptar pagos de forma rápida y segura desde el móvil del cliente, sin necesidad de que introduzca los datos de su tarjeta.

El funcionamiento es transparente para ti: recibirás el importe como en cualquier otro método de pago (tarjeta, transferencia, etc.).

Puedes integrar Bizum en tu tienda online fácilmente:

  • Con un CMS (PrestaShop, WooCommerce, etc.) mediante el módulo de pago correspondiente.
  • Con una integración personalizada por Redirección, simplemente añadiendo el parámetro Ds_Merchant_PayMethods=Z en tu petición al TPV Virtual.
  • Con tu integración a medida REST, la integración es más compleja que la de redirección pero ofrece más opciones. Consulta antes con Soporte. 

La configuración es sencilla y solo requiere establecer algunos campos específicos que veremos más adelante.

Consultas frecuentes Bizum

En el siguiente vídeo tienes un resumen sobre el uso de Bizum y las dudas más frecuentes de Bizum en comercios: 

Por tanto, antes de integrar, ten en cuenta estos puntos:

  • Bizum de tu negocio no es lo mismo que el Bizum personal. El cliente selecciona el método de pago Bizum en tu página web, y completa la operación con su aplicación móvil. 

  • No todos los clientes tienen Bizum activado para pagar en Comercios. Aunque tu cliente utilice Bizum personal normalmente, es posible que no lo tenga activo para pagar en comercios. Lo puede saber revisando su app bancaria o contactando con el banco. 

Integraciones disponibles

Puedes integrar Bizum de 3 formas:

  • Módulo de pago: Si tu comercio usa un CMS (por ejemplo, PrestaShop, WooCommerce, etc) puedes instalar el módulo de pago, con Bizum, pago con tarjeta y más. Consulta la sección de módulos para más información. 
  • Integración por redirección: Puedes integrar Bizum en tu integración por Redirección. 
  • Integración REST: Consulta con Soporte antes. La integración REST de Bizum ofrece más funcionalidades que la redirección, pero tiene más pasos en su flujo. 

Integración por Redirección

Para añadir Bizum en tu integración por Redirección tienes que seguir los siguientes pasos:

1. Integra por Redirección.

2. Añade los botones de Bizum: Incluye en tu página web los recursos Bizum para que los clientes sepan que pueden pagar con Bizum. Puedes verlos en la web de Bizum.

3. Haz una ligera modificación en el formulario que envías

El formulario se envía a las siguientes URLs:

EntornoURL
Pruebashttps://sis-t.redsys.es:25443/sis/realizarPago
Producciónhttps://sis.redsys.es/sis/realizarPago

La lógica de creación de formulario, envío, gestión de la respuesta en Bizum es igual que en cualquier otra integración (por ejemplo, si ya tienes redirección con tarjetas, es igual).

  • Integración por redirección, sigue los pasos indicados para enviar el formulario.
  • La única modificación es la siguiente: En los parámetros que incluyes en Ds_MerchantParameters modifica el siguiente campo:
    • DS_MERCHANT_PAYMETHODS = z este parámetro indica (con la z minúscula) que el pago es mediante Bizum. 
ParámetroFormatoRequerido/OpcionalDescripciónEjemplo
DS_MERCHANT_MERCHANTCODE9 caracteres
Numérico		RequeridoCódigo FUC o número de comercio. No cambia entre entornos. 110034987
DS_MERCHANT_TERMINAL3 caracteres
Numérico		RequeridoNúmero de terminal de tu comercio. Puede cambiar entre entornos.99
DS_MERCHANT_AMOUNT12 caracteres
Numérico		RequeridoImporte de la operación. Los últimos 2 dígitos corresponden a los decimales. Por ejemplo, para una operación de 10,50€, se envía 1050.1050
DS_MERCHANT_CURRENCY4 caracteres
Numérico		RequeridoCódigo ISO 4217 de la divisa utilizada en la transacción. Ver códigos ISO divisas.978
DS_MERCHANT_ORDER12 caracteres
Alfanumérico
* (caracteres ASCII: del 48 al 57, del 65 al 90 y del 97 al 122)		RequeridoCódigo de pedido. No se puede repetir un código de pedido hasta pasados 6 meses.

Recomendamos que los 4 primeros dígitos sean numéricos, para evitar problemas en la liquidación.

*Sólo se permiten caracteres ASCII:
– Dígitos (0–9): ASCII 48 a 57.
Letras mayúsculas (A–Z): ASCII 65 a 90.
– Letras minúsculas (a–z): ASCII 97 a 122.
– No se permiten espacios, símbolos ni acentos.		1234ABcd56EF
DS_MERCHANT_TRANSACTIONTYPEValores disponibles:
– 0: Autorización
– 7: Validación de tarjeta		RequeridoTipo de transacción. El número enviado indica el tipo de transacción. 0
DS_MERCHANT_URLOK250 caracteres
Alfanumérico		RequeridoURL a la que se redirige al cliente mediante una petición HTTP GET si la transacción es exitosa (OK). Si no se envía este parámetro, se usará la URL OK configurada en Canales.https://www.example.com/ok
DS_MERCHANT_URLKO250 caracteres
Alfanumérico		RequeridoURL a la que se redirige al cliente mediante una petición HTTP GET si la transacción falla (KO). Si no se envía este parámetro, se usará la URL KO configurada en Canales. https://www.example.com/ko
DS_MERCHANT_MERCHANTURL250 caracteres
Alfanumérico		RequeridoURL a la que se envía la notificación POST con el resultado de la transacción. https://www.example.com/notification
DS_MERCHANT_PAYMETHODSLetra. Valores posibles:
– z (bizum)		RequeridoMétodo de pago que se aplica en la operación. Para mostrar Bizum envía la «z» minúscula. z
DS_MERCHANT_BIZUM_MOBILENUMBERNuméricoOpcional Número de teléfono del cliente (con prefijo). Si lo envías, aparecerá automáticamente en Bizum. +34700000000
DS_MERCHANT_MERCHANTNAME25 caracteres
Alfanumérico		OpcionalIndica el nombre del comercio que se mostrará al cliente durante el proceso de pago. Si no se envía, se mostrará el nombre configurado en Canales.Mi comercio
DS_MERCHANT_PRODUCTDESCRIPTION125 caracteres máximo
Alfanumérico		OpcionalDescripción del producto que está comprando. El cliente lo verá durante el proceso de pago.Monitor de trabajo
DS_MERCHANT_PERSOCODE1 caracter
Numérico		OpcionalNúmero que identifica la configuración de personalización del TPV Virtual que se utilizará en la operación.2
DS_MERCHANT_MERCHANTDESCRIPTOR25 caracteres
Alfanumérico		OpcionalEs un descriptor flexible. Requiere activación por parte de la entidad. Si está activado y no se envía, se enviará por defecto el nombre del comercio.
* Pensado para PSPs		Mi comercio

Autorización con Bizum

La autorización es la operativa de pago básica: Realiza un cargo inmediato al cliente. El importe es enviado a la cuenta bancaria de tu comercio.

Una vez tienes activo Bizum en tu integración por Redirección puedes hacer una autorización con dicha solución. Las transacciones son iniciadas por el cliente. Una vez completada, tu comercio recibe el resultado de la operación. 

¿Qué parámetros envío en la petición?

  • Envía la petición con los parámetros indicados en la tabla y al endpoint marcado.

Notificación

Recibirás una notificación en la URL especificada con el resultado de la operación. 

Autenticación + Autorización con Bizum 

La autenticación + autorización es una operativa de doble flujo pago del cliente al comercio. Esta operativa se divide en 2 pasos:

  1. Autenticar la operación: Se autentica la cantidad pero no se retira el importe de la cuenta del cliente. 
  2. Autorizar la operación: El comercio tiene como máximo 30 días para autorizar la operación. Se autoriza la operación, por lo que se retira el importe autenticado de la cuenta del cliente. Esta autorización se realiza mediante REST o mediante Canales. 

¿Qué parámetros envío en la petición de Autenticación?

  • Envía la petición con los parámetros indicados en la tabla y al endpoint marcado. 

¿Cómo hago la petición de autorización?

  • La confirmación de autorización se puede realizar desde Canales.
  • La confirmación de autorización se realiza mediante integración REST. Consulta la sección «Confirmación» para saber cómo.

Notificación

Recibirás una notificación en la URL especificada con el resultado de la operación. 

Devoluciones 

Las devoluciones en Bizum no se pueden realizar por redirección. Para realizar las devoluciones tienes 2 opciones:

  1. Mediante Canales: Consulta la documentación de Canales para hacer una devolución.
  2. Mediante integración REST: Se puede mandar una petición de devolución de una operación Bizum mediante REST. Consulta la sección «Devolución» para saber cómo. 

Ten en cuenta estas características de las devoluciones en Bizum:

  • Entorno de pruebas: Sólo puedes hacer una devolución, ya sea total o parcial. 
  • Entorno de producción: Puedes realizar tantas devoluciones parciales como necesites hasta llegar al importe total, o hasta que la operación no esté disponible (que son los últimos 365 días).

Pruebas Bizum por Redirección

En Redirección puedes hacer pruebas enviando las peticiones a la URL de test:

EntornoURL
Pruebashttps://sis-t.redsys.es:25443/sis/realizarPago
Producciónhttps://sis.redsys.es/sis/realizarPago

También puedes comprobar las operaciones en Canales. 

Datos para pruebas

Utiliza estos datos para realizar pruebas en Bizum:

  • Usuario para autorización exitosa: 700000000
  • Usuario para compra rechazada (error en clave Bizum): ko@ko.ko
  • PIN: 1234
  • Código SMS: 123456
  • Importes: Si es superior a 15€, la operación se rechaza. 

Integración REST

Para usar Bizum en tu integración REST tienes que seguir los siguientes pasos:

1. Integra por REST: La lógica de la integración es la misma que la que se explica en la documentación REST, aunque para Bizum tendrás que modificar las peticiones y lógicas que se indican a continuación. 

2. Añade los botones de Bizum: Incluye en tu página web los recursos Bizum para que los clientes sepan que pueden pagar con Bizum. Puedes descargarlos en la web de Bizum.

3. Asegúrate que el cliente tiene Bizum RTP: Bizum y Request To Pay (RTP) permite que el cliente reciba una notificación en su móvil para aceptar el pago Bizum. Para saber si un cliente tiene Bizum RTP, realiza una consulta RTP antes de lanzar las operaciones Bizum por REST. 

4. Realiza las modificaciones en tu integración que indicamos a continuación en tu integración: 

El formulario se envía a las siguientes URLs:

Tipo de peticiónEntornoURL
Consulta RTPPruebashttps://sis-t.redsys.es:25443/sis/rest/RTP/checkRtpUsuario
Producciónhttps://sis.redsys.es/sis/rest/RTP/checkRtpUsuario
Petición de pagoPruebashttps://sis-t.redsys.es:25443/sis/rest/trataPeticionREST
Producciónhttps://sis.redsys.es/sis/rest/trataPeticionREST

El flujo de operaciones de Bizum en REST es el siguiente:

  1. Consulta RTP, para saber si el cliente puede usar Bizum
  2. Petición de pago, una vez conocemos el status RTP del cliente.

En las siguientes secciones explicamos estas peticiones.  

Consulta RTP

Para solicitar un pago al cliente con Bizum en REST, es necesario que el cliente pueda aceptar RTP.

  • RTP (Request To Pay) consiste en el envío de una notificación al móvil del cliente para que acepte el pago Bizum.

Por ello, antes de lanzar la operación de pago en REST, mandamos una petición para comprobar si el cliente tiene RTP.

Con la consulta RTP podemos conocer lo siguiente:

  • El cliente tiene Bizum y RTP: En este caso, se podrá solicitar el pago Bizum vía REST como se explica más adelante o vía redirección.
  • El cliente tiene Bizum, pero no RTP: En este caso, sólo se podrá solicitar el pago Bizum por redirección.
  • El cliente no tiene Bizum: En este caso, no se procederá con el pago.
  • Consultar el estado del ID de Transacción de un cliente: Útil para pagos COF, se consulta con el parámetro opcional DS_MERCHANT_COF_TXNID.
  • Consultar las exenciones que soporta un cliente: Se pueden consultar con DS_MERCHANT_EXCEP_SCA y se devuelven en la notificación.

Parámetros de la petición de Consulta RTP

En la petición enviada al endpoint checkRtpUsuario, envía los siguientes parámetros:

  • Recuerda que estos parámetros se envían dentro de Ds_MerchantParameters
ParámetroFormatoRequerido/OpcionalDescripciónEjemplo
DS_MERCHANT_ORDER12 caracteres
Alfanumérico
* (caracteres ASCII: del 48 al 57, del 65 al 90 y del 97 al 122)		RequeridoCódigo de pedido. No se puede repetir un código de pedido hasta pasados 6 meses.

Recomendamos que los 4 primeros dígitos sean numéricos, para evitar problemas en la liquidación.

*Sólo se permiten caracteres ASCII:
– Dígitos (0–9): ASCII 48 a 57.
Letras mayúsculas (A–Z): ASCII 65 a 90.
– Letras minúsculas (a–z): ASCII 97 a 122.
– No se permiten espacios, símbolos ni acentos.		1234ABcd56EF
DS_MERCHANT_MERCHANTCODE9 caracteres
Numérico		RequeridoCódigo FUC o número de comercio. No cambia entre entornos.110034987
DS_MERCHANT_TERMINAL3 caracteres
Numérico		RequeridoNúmero de terminal de tu comercio. Puede cambiar entre entornos.99
DS_MERCHANT_BIZUM_MOBILENUMBERAlfanuméricoRequeridoNúmero de teléfono (con prefijo) del cliente que queremos consultar si tiene Bizum RTP.+34700000000
DS_MERCHANT_COF_TXNID15 caracteres
Alfanumérico		OpcionalIdentificador de la transacción (ID de transacción) sobre la que quieres consultar su validez.
– Si lo envías, en la notificación recibirás este mismo campo con un OK o KO, dependiendo de la la TRX consultada es válida. 		2006031152000
DS_MERCHANT_EXCEP_SCA3 caracteres
Alfanumérico		OpcionalPermite consultar las exenciones permitidas por el cliente.
– Puedes ver las exenciones en esta sección. link
– Si envias este parámetro en la petición Consulta RTP, recibirás las exenciones permitidas en la notificación.
– Podrás enviar la exención en la petición de pago. 		Y

Envío de la petición de Consulta RTP

Envía la petición de Consulta correctamente formateada al endpoint indicado. A continuación tienes un ejemplo de:

  1. Los parámetros que se envían en Ds_MerchantParameters en formato JSON.
  2. Los parámetros del JSON codificados en BASE64. Este es el valor enviado en Ds_MerchantParameters.
  3. El formulario completo que debes enviar. Consulta el resto de campos en la integración REST.
				
					{ 
    "DS_MERCHANT_ORDER": "5821280951", 
    "DS_MERCHANT_MERCHANTCODE": "999008881", 
    "DS_MERCHANT_TERMINAL": "099", 
    "DS_MERCHANT_CURRENCY": "978", 
    "DS_MERCHANT_AMOUNT": "200", 
    "DS_MERCHANT_BIZUM_MOBILENUMBER": "+34700000000" 
}
				
			
				
					ewogICAgIkRTX01FUkNIQU5UX09SREVSIjogIjU4MjEyODA5NTEiLAogICAgIkRTX01FUkNIQU5UX01FUkNIQU5UQ09ERSI6ICI5OTkwMDg4ODEiLAogICAgIkRTX01FUkNIQU5UX1RFUk1JTkFMIjogIjA5OSIsCiAgICAiRFNfTUVSQ0hBTlRfQ1VSUkVOQ1kiOiAiOTc4IiwKICAgICJEU19NRVJDSEFOVF9BTU9VTlQiOiAiMjAwIiwKICAgICJEU19NRVJDSEFOVF9CSVpVTV9NT0JJTEVOVU1CRVIiOiAiKzM0NzAwMDAwMDAwIgp9
				
			
				
					{
    "Ds_Merchant_MerchantParameters": "ewogICAgIkRTX01FUkNIQU5UX09SREVSIjogIjU4MjEyODA5NTEiLAogICAgIkRTX01FUkNIQU5UX01FUkNIQU5UQ09ERSI6ICI5OTkwMDg4ODEiLAogICAgIkRTX01FUkNIQU5UX1RFUk1JTkFMIjogIjA5OSIsCiAgICAiRFNfTUVSQ0hBTlRfQ1VSUkVOQ1kiOiAiOTc4IiwKICAgICJEU19NRVJDSEFOVF9BTU9VTlQiOiAiMjAwIiwKICAgICJEU19NRVJDSEFOVF9CSVpVTV9NT0JJTEVOVU1CRVIiOiAiKzM0NzAwMDAwMDAwIgp9",
    "Ds_Merchant_Signature": "jYKQo8CFY7Pqp+4gi6EvLtWAGyBOZ8TWJd+nTrPl1Ew==",
    "Ds_SignatureVersion": "HMAC_SHA256_V1"
}

Notificación de Consulta RTP

A continuación tienes un ejemplo de la notificación recibida y decodificada.

				
					{ 
    "Ds_RtpStatus": "OK", 
    "Ds_RtpResponse": "BIZ00000", 
    "Ds_RtpDescription": "Operacion realizada correctamente", 
    "Ds_MerchantCode": "999008881", 
    "Ds_Terminal": "871", 
    "Ds_Order": "1612280505", 
    "Ds_Currency": "978", 
    "Ds_Amount": "145" 
}

Los parámetros de la notificación de una Consulta RTP que tienes que tener en cuenta son los siguientes:

  • Ds_RtpStatus: Indica si el cliente tiene disponible RTP (OK) o si no lo tiene (KO). El código de resultado se indica en el campo Ds_RtpResponse.
  • Ds_RtpResponse: Si es OK, se indicará el código BIZ00000, si es KO, se indicará alguno de los códigos de esta sección. El motivo del error se indica en siguiente campo.
  • Ds_RtpDescription: Indica la descripción del código de error de la operación. 

Tras analizar la notificación, te encontrarás con alguna de estas casuísticas:

1. Cliente con Bizum y RequestToPay habilitado

  • Ds_RtpStatus: OK
  • Ds_RtpResponse: BIZ00000
  • Ds_RtpDescription: Operación realizada correctamente

2. Cliente con Bizum pero sin RequestToPay

  • Ds_RtpStatus: KO
  • Ds_RtpResponse: BIZ00000
  • Ds_RtpDescription: Operación realizada correctamente

3. Cliente sin Bizum ni RequestToPay

  • Ds_RtpStatus: KO
  • Ds_RtpResponse: BIZ00009
  • Ds_RtpDescription: Ordenante no encontrado

4. Error en la operación

  • Ds_RtpStatus: KO
  • Ds_RtpResponse: BIZXXXXX (siendo XXXXX el código de error)
  • Ds_RtpDescription: YYYYY (siendo YYYYY la descripción del error)

Petición de autorización

Una vez verificado que el cliente tiene Bizum y tiene habilitado Request To Pay (mediante la consulta RTP), se puede iniciar el proceso de autorización por REST.

La autorización es una operativa de pago básica: El cliente inicia la operación, la completa y se realiza un cargo en su cuenta a favor de la cuenta de tu comercio. 

El flujo de las peticiones de pago en Bizum con RTP es el siguiente:

  1. Inicio de solicitud de pago RTP: El comercio envía una petición al TPV Virtual para iniciar la solicitud de pago.
  2. Respuesta a la solicitud: Si el cliente tiene RTP activo y la entidad responde correctamente:
    • Ds_RtpResponse = BIZ00000 y Ds_RtpDescription = Operación realizada correctamente
    • En cualquier otro caso: Ds_RtpResponse = BIZXXXXX (código de error) Ds_RtpDescription = YYYYY (descripción del error)
  3. Resultado de la solicitud: Si el inicio fue correcto, cuando el cliente confirme o rechace el pago en su app, el TPV Virtual recibirá una notificación y actuará según el tipo de operación:
    • Confirmación:
      • Tipo 0: se autoriza la operación y se actualiza su estado.
      • Tipo 7: se marca como autenticada y pendiente de autorización (pago Bizum de doble flujo).
    • Denegación: se marca como denegada.

4. Notificación al comercio: El TPV Virtual envía al comercio una notificación con el resultado final de la operación.

Parámetros de la petición de Pago RTP

En la petición enviada al endpoint trataPeticionRest, envía los siguientes parámetros:

  • Recuerda que estos parámetros se envían dentro de Ds_MerchantParameters
ParámetroFormatoRequerido/OpcionalDescripciónEjemplo
DS_MERCHANT_ORDER12 caracteres
Alfanumérico
* (caracteres ASCII: del 48 al 57, del 65 al 90 y del 97 al 122)		RequeridoCódigo de pedido. No se puede repetir un código de pedido hasta pasados 6 meses.

Recomendamos que los 4 primeros dígitos sean numéricos, para evitar problemas en la liquidación.

*Sólo se permiten caracteres ASCII:
– Dígitos (0–9): ASCII 48 a 57.
Letras mayúsculas (A–Z): ASCII 65 a 90.
– Letras minúsculas (a–z): ASCII 97 a 122.
– No se permiten espacios, símbolos ni acentos.		1234ABcd56EF
DS_MERCHANT_MERCHANTCODE9 caracteres
Numérico		RequeridoCódigo FUC o número de comercio. No cambia entre entornos.110034987
DS_MERCHANT_TERMINAL3 caracteres
Numérico		RequeridoNúmero de terminal de tu comercio. Puede cambiar entre entornos.99
DS_MERCHANT_PAYMETHODSValor disponible:
– z 		RequeridoIndica el método de pago que se usará en la operación. z
DS_MERCHANT_CURRENCY4 caracteres
Numérico		RequeridoCódigo ISO 4217 de la divisa utilizada en la transacción. Ver códigos ISO divisas.978
DS_MERCHANT_AMOUNT12 caracteres
Numérico		RequeridoImporte de la operación. Los últimos 2 dígitos corresponden a los decimales. Por ejemplo, para una operación de 10,50€, se envía 1050.1050
DS_MERCHANT_TRANSACTIONTYPEValores disponibles:
– 0: autorización. Cuando se notifique que RTP ha iniciado correctamente, la operación se autorizará.
– 7: Cuando se notifique que RTP ha iniciado correctamente, la operación quedará autenticada pero no autorizada. 		RequeridoTipo de transacción. El número enviado indica el tipo de transacción.0
DS_MERCHANT_BIZUM_MOBILENUMBERAlfanuméricoRequeridoNúmero de teléfono (con prefijo) del cliente.+34700000000
DS_MERCHANT_MERCHANTURL250 caracteres
Alfanumérico		Opcional* URL a la que se envía la notificación con el resultado de la operación.
* Requerido si el comercio NO tiene la URL de notificación configurada en Canales. link		https://www.example.com/notification
DS_MERCHANT_EXCEP_SCA3 caracteres
Alfanumérico		OpcionalPermite solicitar un tipo de exención.
– Puedes saber qué exenciones tiene disponible el cliente si envías este parámetro con valor «Y» (sin comillas) en la petición de consulta REST.
– Exenciones disponibles en esta sección. 		LWV

Envío de la petición de Pago RTP

Envía la petición de pago correctamente formateada al endpoint indicado. A continuación tienes un ejemplo de:

  1. Los parámetros que se envían en Ds_MerchantParameters en formato JSON.
  2. Los parámetros del JSON codificados en BASE64. Este es el valor enviado en Ds_MerchantParameters.
  3. El formulario completo que debes enviar. Consulta el resto de campos en la integración REST.
				
					{
    "DS_MERCHANT_ORDER": "5821280951",
    "DS_MERCHANT_MERCHANTCODE": "999008881",
    "DS_MERCHANT_TERMINAL": "099",
    "DS_MERCHANT_CURRENCY": "978",
    "DS_MERCHANT_AMOUNT": "200",
    "DS_MERCHANT_BIZUM_MOBILENUMBER": "+34700000000",
    "DS_MERCHANT_TRANSACTIONTYPE": "0", 
    "DS_MERCHANT_PAYMETHODS": "z", 
    "DS_MERCHANT_MERCHANTURL": "https://www.example.com/notification"
}
				
			
				
					ewogICAgIkRTX01FUkNIQU5UX09SREVSIjogIjU4MjEyODA5NTEiLAogICAgIkRTX01FUkNIQU5UX01FUkNIQU5UQ09ERSI6ICI5OTkwMDg4ODEiLAogICAgIkRTX01FUkNIQU5UX1RFUk1JTkFMIjogIjA5OSIsCiAgICAiRFNfTUVSQ0hBTlRfQ1VSUkVOQ1kiOiAiOTc4IiwKICAgICJEU19NRVJDSEFOVF9BTU9VTlQiOiAiMjAwIiwKICAgICJEU19NRVJDSEFOVF9CSVpVTV9NT0JJTEVOVU1CRVIiOiAiKzM0NzAwMDAwMDAwIiwKICAgICJEU19NRVJDSEFOVF9UUkFOU0FDVElPTlRZUEUiOiAiMCIsCiAgICAiRFNfTUVSQ0hBTlRfUEFZTUVUSE9EUyI6ICJ6IiwKICAgICJEU19NRVJDSEFOVF9NRVJDSEFOVFVSTCI6ICJodHRwczovL3d3dy5leGFtcGxlLmNvbS9ub3RpZmljYXRpb24iCn0=
				
			
				
					{
    "Ds_Merchant_MerchantParameters": "ewogICAgIkRTX01FUkNIQU5UX09SREVSIjogIjU4MjEyODA5NTEiLAogICAgIkRTX01FUkNIQU5UX01FUkNIQU5UQ09ERSI6ICI5OTkwMDg4ODEiLAogICAgIkRTX01FUkNIQU5UX1RFUk1JTkFMIjogIjA5OSIsCiAgICAiRFNfTUVSQ0hBTlRfQ1VSUkVOQ1kiOiAiOTc4IiwKICAgICJEU19NRVJDSEFOVF9BTU9VTlQiOiAiMjAwIiwKICAgICJEU19NRVJDSEFOVF9CSVpVTV9NT0JJTEVOVU1CRVIiOiAiKzM0NzAwMDAwMDAwIiwKICAgICJEU19NRVJDSEFOVF9UUkFOU0FDVElPTlRZUEUiOiAiMCIsCiAgICAiRFNfTUVSQ0hBTlRfUEFZTUVUSE9EUyI6ICJ6IiwKICAgICJEU19NRVJDSEFOVF9NRVJDSEFOVFVSTCI6ICJodHRwczovL3d3dy5leGFtcGxlLmNvbS9ub3RpZmljYXRpb24iCn0=",
    "Ds_Merchant_Signature": "jYKQo8CFY7Pqp+4gi6EvLtWAGyBOZ8TWJd+nTrPl1Ew==",
    "Ds_SignatureVersion": "HMAC_SHA256_V1"
}

Notificación de Pago RTP

En las operaciones de pago RTP recibes 2 notificaciones:

  • La primera indica si el cliente tiene RTP activo y si la entidad responde correctamente. A continuación tienes un ejemplo de la notificación recibida y decodificada.
  • La segunda indica que el cliente ha confirmado (o rechazado) el pago en su app bancaria. Indica si la operación ha sido autorizada, si ha sido denegada o si es de tipo pago Bizum de doble flujo (Ds_TransactionType = 7).
  • Para más información sobre la notificación de peticiones y su gestión consulta la documentación de REST.
  • Consulta esta sección para más información sobre los códigos de error.

A continuación tienes un ejemplo de las 2 notificaciones recibidas en los Pagos RTP: 

				
					{
  "Ds_Amount": "200",
  "Ds_Currency": "978",
  "Ds_Order": "86834971",
  "Ds_MerchantCode": "999008881",
  "Ds_Terminal": "099",
  "Ds_Response": "9998",
  "Ds_AuthorisationCode": "",
  "Ds_TransactionType": "0",
  "Ds_SecurePayment": "0",
  "Ds_Language": "1",
  "Ds_MerchantData": "",
  "Ds_ProcessedPayMethod": "68",
  "Ds_RtpResponse": "BIZ00000",
  "Ds_RtpDescription": "Operacion realizada correctamente"
}
				
			
				
					{
  "Ds_Date": "12%2F02%2F2024",
  "Ds_Hour": "13%3A34",
  "Ds_SecurePayment": "1",
  "Ds_Card_Number": "9724020150000259",
  "Ds_Amount": "200",
  "Ds_Currency": "978",
  "Ds_Order": "86834971",
  "Ds_MerchantCode": "999008881",
  "Ds_Terminal": "871",
  "Ds_Response": "0000",
  "Ds_MerchantData": "",
  "Ds_TransactionType": "0",
  "Ds_ConsumerLanguage": "1",
  "Ds_AuthorisationCode": "123456",
  "Ds_ProcessedPayMethod": "68"
}

Devoluciones

Las devoluciones en Bizum REST se pueden realizar de 2 formas:

  1. Mediante Canales: Consulta la documentación de Canales para hacer una devolución.
  2. Mediante integración REST: Se puede mandar una petición de devolución de una operación Bizum mediante REST. Consulta la sección «Devolución» para saber cómo.

Ten en cuenta estas características de las devoluciones en Bizum:

  • Entorno de pruebas: Sólo puedes hacer una devolución, ya sea total o parcial. 
  • Entorno de producción: Puedes realizar tantas devoluciones parciales como necesites hasta llegar al importe total, o hasta que la operación no esté disponible (que son los últimos 365 días).

Otras funcionalidades: Devolución sin original

En Bizum REST es posible realizar una devolución sin operación original. Esto implica que no es necesario que exista una autorización previa del cliente. Alguno de los casos de uso para esta operación puede ser:

  • El pago de un premio o bonificación.
  • El plazo de devolución de la autorización original ha pasado. 

Parámetros de la petición de devolución

En la petición enviada al endpoint trataPeticionRest, envía los siguientes parámetros:

  • Recuerda que estos parámetros se envían dentro de Ds_MerchantParameters
ParámetroFormatoRequerido/OpcionalDescripciónEjemplo
DS_MERCHANT_ORDER12 caracteres
Alfanumérico
* (caracteres ASCII: del 48 al 57, del 65 al 90 y del 97 al 122)		RequeridoCódigo de pedido. No se puede repetir un código de pedido hasta pasados 6 meses.

Recomendamos que los 4 primeros dígitos sean numéricos, para evitar problemas en la liquidación.

*Sólo se permiten caracteres ASCII:
– Dígitos (0–9): ASCII 48 a 57.
Letras mayúsculas (A–Z): ASCII 65 a 90.
– Letras minúsculas (a–z): ASCII 97 a 122.
– No se permiten espacios, símbolos ni acentos.		1234ABcd56EF
DS_MERCHANT_MERCHANTCODE9 caracteres
Numérico		RequeridoCódigo FUC o número de comercio. No cambia entre entornos.110034987
DS_MERCHANT_TERMINAL3 caracteres
Numérico		RequeridoNúmero de terminal de tu comercio. Puede cambiar entre entornos.99
DS_MERCHANT_PAYMETHODSValor disponible:
– z 		RequeridoIndica el método de pago que se usará en la operación. z
DS_MERCHANT_CURRENCY4 caracteres
Numérico		RequeridoCódigo ISO 4217 de la divisa utilizada en la transacción. Ver códigos ISO divisas.978
DS_MERCHANT_AMOUNT12 caracteres
Numérico		RequeridoImporte de la operación. Los últimos 2 dígitos corresponden a los decimales. Por ejemplo, para una operación de 10,50€, se envía 1050.1050
DS_MERCHANT_TRANSACTIONTYPEValores disponibles:
– 34		RequeridoTipo de transacción. El número enviado indica el tipo de transacción.34
DS_MERCHANT_BIZUM_MOBILENUMBERAlfanuméricoRequeridoNúmero de teléfono (con prefijo) del cliente que queremos consultar si tiene Bizum RTP.+34700000000

Envío de la petición de devolución sin original

Envía la petición de devolución sin original correctamente formateada al endpoint indicado. A continuación tienes un ejemplo de:

  1. Los parámetros que se envían en Ds_MerchantParameters en formato JSON.
  2. Los parámetros del JSON codificados en BASE64. Este es el valor enviado en Ds_MerchantParameters.
  3. El formulario completo que debes enviar. Consulta el resto de campos en la integración REST.
				
					{ 
    "DS_MERCHANT_ORDER": "62732812", 
    "DS_MERCHANT_MERCHANTCODE":"999008881", 
    "DS_MERCHANT_TERMINAL":"099", 
    "DS_MERCHANT_CURRENCY":"978", 
    "DS_MERCHANT_TRANSACTIONTYPE":"34", 
    "DS_MERCHANT_AMOUNT":"200", 
    "DS_MERCHANT_PAYMETHODS":"z", 
    "DS_MERCHANT_BIZUM_MOBILENUMBER":"34700000000" 
}
				
			
				
					ewogICAgIkRTX01FUkNIQU5UX09SREVSIjogIjYyNzMyODEyIiwKICAgICJEU19NRVJDSEFOVF9NRVJDSEFOVENPREUiOiI5OTkwMDg4ODEiLAogICAgIkRTX01FUkNIQU5UX1RFUk1JTkFMIjoiMDk5IiwKICAgICJEU19NRVJDSEFOVF9DVVJSRU5DWSI6Ijk3OCIsCiAgICAiRFNfTUVSQ0hBTlRfVFJBTlNBQ1RJT05UWVBFIjoiMzQiLAogICAgIkRTX01FUkNIQU5UX0FNT1VOVCI6IjIwMCIsCiAgICAiRFNfTUVSQ0hBTlRfUEFZTUVUSE9EUyI6InoiLAogICAgIkRTX01FUkNIQU5UX0JJWlVNX01PQklMRU5VTUJFUiI6IjM0NzAwMDAwMDAwIgp9
				
			
				
					{
    "Ds_Merchant_MerchantParameters": "ewogICAgIkRTX01FUkNIQU5UX09SREVSIjogIjYyNzMyODEyIiwKICAgICJEU19NRVJDSEFOVF9NRVJDSEFOVENPREUiOiI5OTkwMDg4ODEiLAogICAgIkRTX01FUkNIQU5UX1RFUk1JTkFMIjoiMDk5IiwKICAgICJEU19NRVJDSEFOVF9DVVJSRU5DWSI6Ijk3OCIsCiAgICAiRFNfTUVSQ0hBTlRfVFJBTlNBQ1RJT05UWVBFIjoiMzQiLAogICAgIkRTX01FUkNIQU5UX0FNT1VOVCI6IjIwMCIsCiAgICAiRFNfTUVSQ0hBTlRfUEFZTUVUSE9EUyI6InoiLAogICAgIkRTX01FUkNIQU5UX0JJWlVNX01PQklMRU5VTUJFUiI6IjM0NzAwMDAwMDAwIgp9",
    "Ds_Merchant_Signature": "jYKQo8CFY7Pqp+4gi6EvLtWAGyBOZ8TWJd+nTrPl1Ew==",
    "Ds_SignatureVersion": "HMAC_SHA256_V1"
}

Notificación de la devolución sin original 

En las devoluciones sin original por Bizum recibes una notificación con el resultado de la operación. 

Este es un ejemplo de notificación decodificada a una devolución sin original:

				
					{
  "Ds_Amount": "200",
  "Ds_Currency": "978",
  "Ds_Order": "62732812",
  "Ds_MerchantCode": "999008881",
  "Ds_Terminal": "871",
  "Ds_Response": "0900",
  "Ds_AuthorisationCode": "",
  "Ds_TransactionType": "Y",
  "Ds_SecurePayment": "1",
  "Ds_Language": "1",
  "Ds_MerchantData": "",
  "Ds_Bizum_IdOper": "66569849-91c9-41b2-97b2-83cb96718bf",
  "Ds_ProcessedPayMethod": "68",
  "Ds_Control_1724928579058": "1724928579058",
  "Ds_RtpResponse": "BIZ00000",
  "Ds_RtpDescription": "Operacion realizada correctamente"
}

Pruebas Bizum REST

Para las pruebas de Bizum en tu integración REST utiliza el siguiente número de teléfono:

  • +34700000000

Además, puedes probar distintas casuísticas con distintos importes, como ves en la siguiente tabla: 

ImporteCliente con BizumCliente con RTPResultado operaciónDescripción en consulta de RTPDescripción en pago REST
Inferior a 5 €

OK

OK

OK

Recibimos que el teléfono usuario tiene activo RTP. En este rango, el cliente tiene exenciones y todos los TIDs válidos.En la petición inicial, recibimos respuesta de que ha ido OK. Al revisar la operación, veremos que se autentica.
Entre 5 € y 10 €

OK

OK

KO

Recibimos que el teléfono usuario tiene activo RTP. En este rango, el cliente no tiene exenciones y todos los TIDs son inválidos.En la petición inicial, recibimos respuesta de que ha ido OK. Al revisar la operación, veremos que se deniega.
Entre 10 € y 15 €

OK

KO

–Recibimos que el teléfono usuario no tiene activo RTP.En la petición inicial, recibimos respuesta de que ha ido KO. El motivo de error es BIZ00202.
Superior a 15 €

KO

KO

–Recibimos que el teléfono usuario no tiene activo BIZUM.En la petición inicial, recibimos respuesta de que ha ido KO. El motivo de error es BIZ00009.

Códigos de error Bizum

En esta sección tienes los códigos de error que se pueden recibir en las operaciones Bizum. 

Códigos de error Bizum REST

Estos errores aplican a las operaciones Bizum vía REST:

CódigoDescripción
BIZ00000Operación realizada correctamente.
BIZ00001Parámetro de entrada obligatorio no completado.
BIZ00002El formato de algún parámetro es incorrecto.
BIZ00003No se encontró el elemento.
BIZ00005Error interno del sistema.
BIZ00006Error de seguridad 3DES o MAC X9.19
BIZ00007Operación no permitida.
BIZ00008Beneficiario no encontrado.
BIZ00009Ordenante no encontrado.
BIZ00202Funcionalidad aún no implementada.
BIZ00213Error de autenticación en la petición recibida. Fallo en secuencia de seguridad.
BIZ00224La respuesta de la entidad a la autenticación por RTP es KO.
BIZ00225La autenticación por request to pay no ha finalizado con éxito.

Submotivos errores Bizum

Estos códigos de error pueden recibirse en las notificaciones como submotivos de errores más generales: 

Código Descripción
CJ00003No se encontró el elemento.
CJ00005Operación no permitida
CJ00007Operación no permitida
CJ00201La entidad no tiene activo el servicio C2eR
CJ00202Funcionalidad aun no implementada.
CJ00204Fallo en la autenticacion de primer factor. Bloqueo tras tres intentos.
CJ00205Fallo en la autenticacion de segundo factor. Superado el maximo numero de intentos.
CJ00207Operacion cancelada en el primer factor. El usuario no desea seguir.
CJ00209Operacion cancelada en el segundo factor. El usuario no desea seguir.
CJ00210Limite de devolucion superado.
CJ00211Fecha de devolucion superada.
CJ00212Fallo en la autenticacion de segundo factor. Error en el envio de la OTP
CJ00213Error de autenticacion en la peticion recibida. Fallo en secuencia de seguridad.
CJ00214El importe a autorizar es superior al maximo permitido con respecto al importe autenticado.
CJ00215El importe a autorizar es inferior al minimo permitido con respecto al importe autenticado.
CJ00216El importe informado a autorizar es superior al maximo permitido.
CJ00217El importe informado a autorizar es inferior al minimo permitido.
CJ00218El importe informado a devolver es superior al maximo permitido.
CJ00219El importe informado a devolver es inferior al minimo permitido.
CJ00220Los datos de la devolucion son inconsistentes con respecto a los datos de la autorizacion. IBAN o elemento virtual han cambiado.
CJ00221Fecha de autorizacion superada.
CJ00222Los datos de la autorizacion son inconsistentes con respecto a los datos de la autenticacion. IBAN o elemento virtual han cambiado.
CJ00223Autenticacion en curso.
CJ00224La respuesta de la entidad a la autenticacion por RTP es KO.
CJ00225La autenticacion por request to pay no ha finalizado con éxito.
CJ00226Error en la comunicación con proxy notificador para RTP.
CJ00300Error de conectividad con el servidor de procesamiento
CJ00301Abono rechazado por beneficiario
CJ00302Cargo rechazado por ordenante
CJ00303Error interno del sistema de procesamiento
CJ00304Saldo insuficiente en la cuenta
CJ00305Elemento Virtual no registrada por el beneficiario
CJ00306Elemento Virtual no registrada por el ordenante
CJ00307El procesador no ha podido realizar la operativa para el beneficiario
CJ00308El procesador no ha podido realizar la operativa para el ordenante
CJ00309No ha sido posible contactar con la entidad beneficiaria
CJ00310No ha sido posible contactar con la entidad ordenante
CJ00311Código de rechazo del procesamiento no contemplado
CJ00312Entidad del beneficiario no disponible
CJ00313Entidad del ordenante no disponible
CJ00314El procesador no puede gestionar la petición
CJ00315El procesador/entidad beneficiaria no puede gestionar la operación (909 – ERROR DEL SISTEMA)
CJ00318La SCT Inst se ha detenido por un error en la entidad receptora
CJ00319Operación duplicada
CJ00320Transferencia de crédito prohibida en este tipo de cuenta
CJ00321IBAN no válido
CJ00322La SCT Inst se ha detenido por un error en la entidad del beneficiario
CJ00323Servicio no implementado
CJ00324La entidad de beneficiario o su asociada esta temporalmente no disponible
CJ00330El procesador no puede gestionar la petición para el beneficiario
CJ00331El procesador no puede gestionar la petición para el ordenante
CJ00333Operación en SD rechazada por error interno CJ00334 El procesador no puede gestionar la petición para el beneficiario
CJ00335Operación en SD rechazada en la comunicación hacia beneficiario
CJ00336El rechazo se ha producido por motivos regulatorios
CJ00337Cuenta bloqueada
CJ00338Formato no válido
CJ00339La SCT Inst se ha detenido por un error en la entidad del beneficiario
CJ00340Tarjeta ordenante no efectiva (125 Cargo)
CJ00341Tarjeta beneficiario no efectiva (125 Abono)
CJ00342Marca no admitida por el ordenante (161 Cargo)
CJ00343Marca no admitida por el benficiario (161 Abono)
CJ00344Denegacion de la tarjeta del ordenante por restricción
CJ00345Denegacion de la tarjeta del beneficiario por restricción
CJ00346Error en autenticacion del ordenante
CJ00347Error en autenticacion del beneficiario
CJ00348Denegacion autenticacion por telefono del ordenante en lista negra
CJ00349Denegacion autenticacion por telefono del beneficiario en lista negra
CJ00371[Servicio Basico IT01] Operacion rechazada por timestamp
CJ00372[Servicio Basico IT29] Operacion rechazada por MsgId
CJ00373[Servicio Basico IT31] Fecha/hora de creación superior a la fecha del sistema
CJ00374[Servicio Basico IT03] El numero de operaciones debe ser igual a 1
CJ00375[Servicio Basico IT05] El total de importes debe coincidir con el importe de la operacion
CJ00376[Servicio Basico IT06] Error en la fecha de liquidacion entregada
CJ00377[Servicio Basico IT09] Codigo para identificar a iberpay erroneo
CJ00378[Servicio Basico FF01] Formato no valido
CJ00379[Servicio Basico IT10] BIC participante no encontrado
CJ00380[Servicio Basico IT33] BIC dado de baja
CJ00381[Servicio Basico IT52] BIC en baja parcial
CJ00382[Servicio Basico IT39] Error en la entidad emisora
CJ00383[Servicio Basico IT16] Tipo de producto especificado en instrId no encontrado
CJ00384[Servicio Basico IT13] El tipo de pago no contiene el valor fijo establecido SEPA
CJ00385[Servicio Basico AM02] El importe de la operacion supera el limite estableido por operacion
CJ00386[Servicio Basico IT97] La entidad emisora ha superado el limite por operación
CJ00387[Servicio Basico IT20] Codigo utilizado para indicar el pais no encontrado
CJ00388[Servicio Basico IT25] CdtTrfTxInf Purpose Code no encontrado
CJ00389[Servicio Basico AB06] El tiempo maximo de intercambio se ha superado en la entidad receptora
CJ00390[Servicio Basico IT28] Algun campo de la operacion no coincide con la SCT Inst original
CJ00391[Servicio Basico IT51] No existe solicitud de retrocesion previa
CJ00392[Servicio Basico AC04] Cuenta cancelada
CJ00393[Servicio Basico IT32] Transferencia ya aceptada/rechazada previamente

Códigos de error

También puedes recibir el parámetro DS_ERRORCODE. Estos son los códigos de error SIS:

Códigos de error y denegaciones
Comparte este documento
Tabla de Contenidos

Consulta la documentación de las distintas secciones de integraciones:

Comienza a integrar

undraw_add_to_cart_re_wrdo 1 (1) (1)

Plugins para CMS

Complementa la integración

SDKs

Métodos de pago

Herramientas

Addon Payments

Consulta la documentación de Addon Payments. Aquí tienes las distintas secciones:

Integraciones

Consultas frecuentes

Portal Backoffice

Cyberpac

Consulta la documentación de Cyberpac. Aquí tienes las distintas secciones:

Canales

Módulos de integración

Integraciones a medida

Pagos integrados en TPV

Crea una solución que te ayudará a automatizar procesos. Incluso, podrás agregar procesos de pago en terminales físicos.

Pago integrado con TPV Android

Pago integrado con Smartphone TPV

Fichas Técnicas TPVs