Ejemplo de como autenticar todas las peticiones a la API.

Este endpoint sirve para obtener los perfiles de la API key que se ha usado en la petición. Si la API key tiene acceso total, se devolverá el perfil all.

Este endpoint sirve para obtener todos los perfiles que puede tener una API key.

• all: Acceso total
• payment: Creación de órdenes, pagos, devoluciones, confirmaciones, cancelaciones, tokenización de tarjetas
• refund: Devolver órdenes.
• readonly: Leer órdenes, clientes, tarjetas, etc,
• card: Tokenizar, listar, modificar y borrar tarjetas
• tokenize: Tokenizar tarjetas
• moto: Lanzar campañas MoTo
• batch_authorization: Lanzar pagos en lote
• batch_refund: Lanzar devoluciones en lote
• keyentry: Procesar pagos manuales

Generar Orden de pago

Este endpoint envía el enlace de la orden de pago por SMS o correo electrónico a su destinatario, según proceda.

Permite generar una orden de cobro, almacenar la tarjeta y realizar el pago en una sola petición. Sólo usable por clientes PCI.

Si el pago es no seguro se realizará un pago directo. En caso de que el antifraude detecte riesgo, se devolverá un enlace para que el usuario finalice el pago tokenizado por 3DS, de lo contrario el pago finalizará normalmente.

Si el pago es seguro se devolverá el enlace al pago tokenizado por 3DS para que el usuario finalice el pago de forma segura.

El usuario es redirigido a la página de pago de Bizum, donde deberá introducir el número de teléfono de la cuenta desde donde desea pagar.

Esta modalidad de pago solo está disponible en REDSYS y será necesario activarlo previamente: póngase en contacto con soporte para activar esta configuración.

En el entorno SANDBOX, se puede simular pagos exitosos o rechazados utilizando los siguientes valores como número de teléfono, cuando se solicite:

• Pago exitoso: 700000000
• Pago rechazado: ko@ko.ko

Mediante esta operativa se libera el saldo retenido por una operación DEFERRED.

Si un intento de cancelación falla, se deberá esperar 1 minuto desde el último intento fallido antes de realizar un nuevo intento. En caso de que una cancelación sea exitosa, no será necesario esperar para realizar otro intento de cancelación. Sin embargo, si el sistema detecta 3 intentos fallidos en total, no se permitirán más intentos hasta el inicio del próximo día.

A partir del tercer intento fallido, solo se permitirá un cancelación fallida al día. Esto significa que después de los tres primeros reintentos fallidos, si el siguiente también falla, deberá esperar hasta el siguiente día para realizar otro intento.

Mediante esta operativa se confirma el saldo retenido por una operación DEFERRED.

Si un intento de confirmación falla, se deberá esperar 1 minuto desde el último intento fallido antes de realizar un nuevo intento. En caso de que una confirmación sea exitosa, no será necesario esperar para realizar otro intento de confirmación. Sin embargo, si el sistema detecta 3 intentos fallidos en total, no se permitirán más intentos hasta el inicio del próximo día.

A partir del tercer intento fallido, solo se permitirá un confirmación fallida al día. Esto significa que después de los tres primeros reintentos fallidos, si el siguiente también falla, deberá esperar hasta el siguiente día para realizar otro intento.

En este método de pago no interviene el usuario. Para ello se necesita el uuid de la orden de pago y el uuid de una tarjeta previamente almacenada en el sistema.

Si el comercio tiene el sistema antifraude activado, podría darse el caso que alguna regla se activase y fuese necesario finalizar el cobro por 3DS. En este caso, la respuesta devuelta contendrá la URL a la que debe redirigirse al usuario para autenticarse y poder finalizar el cobro.

Bajo ningún concepto debe modificarse esta URL, puesto que su formato puede variar en futuras actualizaciones. Su uso se restringe a obtenerla del cuerpo de la petición y redirigir al usuario.

La IP del usuario que solicita el pago debe indicarse en formato IPv4 o IPv6. Si no se indica, no se podrán ejecutar medidas antifraude relacionadas con la IP.

Este método permite realizar el pago de una orden con los datos de pago obtenidos mediante correo o teléfono. Esta operación no requerirá autenticación, ya que es una operación exenta de PSD2. Sólo usable por clientes PCI.

En caso de tener activado el antifraude, las órdenes consideradas de riesgo se procesarán sin ninguna restricción adicional.

Para llevar a cabo este pago será necesario indicar la tarjeta que se va a emplear. Hay dos formas para ello: indicando los datos de tarjeta por separado (card_holder, card_pan, card_expire_month, card_expire_year, y opcionalmente, con card_cvv y card_additional) o, si la tarjeta ya fue tokenizada previamente, indicando su uuid en el campo source_uuid únicamente.

Este método permite redirigir al usuario a una pantalla de pago en la cual se le solicitarán los datos de su método de pago, el cual puede ser una tarjeta o un APM (método de pago alternativo). El token solicitado es el que se devuelve al generar una orden de pago.

Alternativamente, si se ha indicado el UUID de un checkout en el momento de generar la orden de pago, este método redirigirá el usuario al checkout para que seleccione qué método de pago quiere utilizar para pagar, y se le guiará hasta que el proceso de pago finalice.

Este endpoint se utiliza para devolver un importe a la tarjeta con la que se hizo el pago. Si no se envía el campo amount, la devolución será total. Si se envía este campo, la devolución será del importe enviado (siempre y cuando sea válido).

Cuando la devolución se haga a través de un marketplace. Se debe incluir el campo extra_data, indicando dentro marketplace_refundsy los datos pertinentes a cada comercio y el importe devuelto por cada uno.

En el campo amount, del comercio que efectúa la devolución, será igual al amount indicado fuera del extra_data y en el net_amount se indicará el importe que devolverá cada una de las partes involucradas en la devolución.

Si un intento de devolución falla, se deberá esperar 1 minuto desde el último intento fallido antes de realizar un nuevo intento. En caso de que una devolución sea exitosa, no será necesario esperar para realizar otro intento de devolución. Sin embargo, si el sistema detecta 3 intentos fallidos en total, no se permitirán más intentos hasta el inicio del próximo día.

A partir del tercer intento fallido, solo se permitirá un devolución fallida al día. Esto significa que después de los tres primeros reintentos fallidos, si el siguiente también falla, deberá esperar hasta el siguiente día para realizar otro intento.

Este método de pago es similar al pago por webservice, con la diferencia que en este caso al usuario se le mostrará la pantalla de 3DS antes de finalizarlo.

Este método permite iniciar pagos alternativos sin que el usuario tenga que estar presente durante el proceso delante de un navegador web. En algunos métodos de pago como Bizum, la llamada a este método enviará la notificación PUSH al teléfono móvil del usuario para que lleve a cabo el pago. En otros, devolverá la información necesaria para que se pueda llevar a cabo el pago.

Si un servicio de pago soporta más de un APM (método alternativo de pago), deberá indicarse el APM a utilizar en el cuerpo de la petición.

Si se quiere integrar directamente Google Pay o Apple Pay, se puede proceder al pago indicando la orden a pagar y el Payload devuelto por cualquiera de estos wallet. Este flujo es necesario en pagos a través de APP ya que no es posible mostrar el botón de Google Pay o Apple Pay en un webview desde un dispositivo móvil.

Si el wallet es Google Pay, es posible que sea necesario finalizar el cobro mediante 3DS. En este caso, la respuesta devuelta contendrá la URL a la que debe redirigirse al usuario para autenticarse y poder finalizar el cobro. Si el wallet es Apple Pay, la orden se considerará pagada como 3DS porque Apple Pay se considera un método de pago seguro.

Transfiere fondos al source_uuid indicado del usuario. Para enviar dinero a una tarjeta, es necesario que ésta haya realizado alguna operación de cobro previa en el terminal. Si no se indica source_uuid, se seleccionará la última tarjeta que haya realizado un pago exitoso y esté asociada al customer_ext_id indicado al generar la orden.

También existen otras formas de transferir fondos a un usuario. Algunos servicios soportan métodos de pago alternativos como Bizum, PIX o transferencias bancarias. Si se utiliza un servicio con más de una forma de transferir fondos, es obligatorio indicar el campo apm para especificar cuál de ellos se utilizará. Podrá encontrar más información al respecto de estos métodos de pago en la Documentación. No todos los APM soportan abonos.

Este método devuelve la información asociada a una orden, pudiendo ver el estado en el que se encuentra y sus transacciones. Si el pago de la transacción se realizo mediante un dispositivo físico, también aparecerá un campo "pos" dentro de cada transacción con los datos del mismo.