Elige por dónde empezar

Las secciones del documento, en el orden en que hacen falta: primero qué ocurre en un cobro, al final cómo se integra y cómo se opera.

Qué ocurre entre que tu cliente decide pagar y el dinero queda conciliado. Sin código todavía.

Integras una vez con Luka. Detrás hay muchos proveedores, y esa parte deja de ser tu problema.

El problema que evita

Aceptar muchos medios de pago, en varios países y monedas, significa normalmente integrar con muchos proveedores distintos: cada uno con su API, su forma de autenticar, su formato de respuesta y sus caídas. Ese trabajo no se hace una vez: se mantiene para siempre, y crece con cada medio que añades.

Con Luka integras una vez. Añadir o quitar un medio de pago pasa a ser una cuestión de configuración de tu comercio, no un proyecto de desarrollo.

Qué significa para tu equipo

• Un solo contrato técnico: token, cobro, webhook. El mismo para todos los medios.
• Un solo sitio donde conciliar, en vez de un reporte por proveedor.
• Luka administra la conexión con los proveedores y reduce el impacto que sus cambios producen sobre la integración del comercio.

La pasarela de pagos Luka permite gestionar transacciones financieras de forma segura y eficiente, facilitando el procesamiento de pagos con múltiples métodos, como tarjetas de crédito o débito, en diversas monedas. Los usuarios finales interactúan directamente con la pasarela desde el sitio web del comercio, donde seleccionan productos o servicios y completan el proceso de pago sin salir del entorno del comercio.

El ingreso de los datos de pago, como la información de la tarjeta y el correo electrónico, se realiza a través de Luka JS, que valida y procesa la transacción de manera segura mediante nuestra API. Cada comercio que utiliza la pasarela de pagos Luka se identifica mediante un token de autenticación único, garantizando la integridad y trazabilidad de las transacciones.

La pasarela también permite personalizar su apariencia para que coincida con la identidad visual del comercio, asegurando una experiencia de usuario consistente y alineada con la marca. Además, puedes gestionar las transacciones fácilmente con nuestro panel de control.

Luka proporciona herramientas diseñadas para adaptarse a las necesidades específicas de cada negocio, destacándose por:

• Una API flexible, fácil de integrar en diversas plataformas.
• Compatibilidad con múltiples métodos de pago, incluyendo tarjetas y métodos alternativos.
• Soporte para transacciones en varias monedas, con conversión automática.

¿Cómo funciona?

1. El usuario accede a la página web del comercio.
2. La página carga el script de la librería Luka JS.
3. El comercio inicializa el objeto Luka JS con el token de autenticación y la configuración necesaria.
4. Luka JS valida el token enviando una petición HTTPS a la API de Luka.
5. La API confirma que el token es válido.
6. Luka JS renderiza los métodos de pago disponibles en la página.
7. El usuario ingresa la información de pago (por ejemplo, datos de la tarjeta).
8. Luka JS valida el correo electrónico del usuario mediante la API.
9. La API confirma la validez del correo electrónico.
10. Luka JS procesa el pago con los datos proporcionados y envía la información a la API de Luka.
11. Exitoso: true no confirma por sí solo la aprobación. Valida InfoProceso.EstatusProcesamiento; si está pendiente, espera el webhook o consulta la transacción.
12. Luka JS retorna los detalles de la transacción al comercio mediante una función callback.
13. El comercio muestra el resultado según InfoProceso.EstatusProcesamiento: confirma la compra si es success; si es pending, informa que el pago está en revisión.

Para detalles técnicos, consulta nuestra documentación de API.

¿Cómo pago el usuario?

• Bolívares: 1 artículo
• Dólares: 1 artículo

Por dónde entra la transacción. Es la primera decisión: el canal define la experiencia de tu cliente y el trabajo de integración.

El cobro embebido dentro de tu propia web o aplicación. El cliente no sale de tu sitio.

Qué resuelve

Tu cliente ya decidió comprar y está en tu web o en tu app. Cada paso extra que le pongas entre esa decisión y el pago es una oportunidad de que abandone. El Checkout embebe la ventana de pago dentro de tu página: el cliente elige el medio y paga sin ir a ningún otro sitio.

Es el canal donde Luka pone su diferencial: el checkout es dinámico, es decir, los medios de pago, el financiamiento y las promociones que ve cada cliente dependen de la configuración de tu comercio, no de una lista fija.

Cuándo elegirlo

• Tienes web o app propia y control sobre su código.
• El volumen justifica el trabajo de integración: es el canal que más pide de tu equipo técnico, y el único donde el cliente no sale de tu sitio en ningún momento.
• Quieres que la marca sea la tuya de principio a fin del pago.

Si no tienes desarrollo disponible, o necesitas cobrar esta semana, empieza por el Link de Pago y migra al Checkout cuando tengas el equipo. El contrato es el mismo, así que no se tira trabajo.

Qué necesitas de tu lado

• Una página donde exista un contenedor en el DOM: la ventana de pago se dibuja dentro de él.
• Un backend que guarde tus credenciales y pida el token. Las credenciales nunca van en el navegador.
• Un endpoint público que reciba el webhook, que es con lo que concilias.

Cómo se integra

Todos los canales de Luka corren sobre el mismo contrato: tu backend pide un token con tus credenciales, crea el cobro, y el resultado te vuelve por webhook. En el Checkout, el cobro se dibuja con la librería JavaScript, que recibe el token y el contenedor donde debe renderizarse.

Eso significa que cambiar de canal, o añadir uno, no te obliga a reescribir la integración: cambia por dónde entra la transacción, no cómo la concilias.

El contrato completo de la librería, con sus parámetros de entrada y de salida, está en Checkout con Luka JS, en la sección Integrar.

Solución diseñada para integrar sistemas de cobro y desembolso electrónico en entornos B2B. A través de su arquitectura flexible, permite generar enlaces de pago compatibles con diversos métodos y proveedores, tanto locales como internacionales.

• Habilita métodos y proveedores de pago locales e internacionales.
• Utiliza cualquier canal de mensajería: SMS, WhatsApp, correo electrónico, redes sociales o tu aplicación.
• Simplifica las experiencias de pago para tus clientes.
• Gestiona todos los enlaces de pago desde un panel de control intuitivo.

¿Cómo funciona?

Para el comercio:

1. El comercio proporciona los datos del cliente pagador (correo electrónico o número de teléfono y monto) a nuestra API. Este proceso puede realizarse desde el panel de control o directamente vía API.
2. Nuestro sistema envía al cliente una notificación por correo electrónico o SMS con el Link de Pago generado.
3. El comercio recibe una confirmación exitosa junto con la URL del Link de Pago.

Para el cliente:

1. Recibe una notificación por correo electrónico o SMS con el Link de Pago.
2. Abre el Link de Pago recibido.
3. Completa el proceso siguiendo los pasos descritos en la pasarela de pagos a partir del paso 6.

Uno a uno o en lote

Un enlace se genera desde el panel para un cliente, con su correo o su teléfono, la moneda y el monto. Si son muchos, se cargan en lote: descargas la plantilla, la completas sin tocar la primera fila y la subes en CSV con todos tus clientes. El panel valida cada registro antes de enviar y te confirma por correo cuando salieron.

Referencias personalizadas

Cada enlace lleva la referencia de tu sistema (el campo ReferenciaServicio cuando lo generas por API, o el concepto en comentarios cuando lo haces desde el panel) y esa referencia vuelve con el resultado de la transacción. Así el pago llega ya atado a la factura, el pedido o el cliente con el que lo concilias, sin cruzar listas a mano.

Vigencia

Cada enlace se usa una sola vez y expira entre 15 y 30 días hábiles, según lo que pidas. El estado de cada solicitud (exitosa, pendiente, expirada) se sigue en Reportes.

Cuando quieras generarlos desde tu propio sistema, el contrato está en Link de Pago (API).

Un botón junto a lo que vendes: el trabajo se reduce a colocarlo en tu página.

Qué resuelve

No todo el que vende en línea tiene equipo de desarrollo, y no todo el que vende en línea lo necesita. El Botón de Pago es un cobro que se coloca al lado de lo que vendes: el cliente pulsa y paga sin que tú montes un checkout.

Frente al Checkout Dinámico, que dibuja la ventana de pago dentro de tu web y pide que tu equipo construya el contenedor y el flujo alrededor, aquí lo único que se hace en tu página es colocar el botón y cargar el script de Luka. Lo demás (la ventana, la captura de la tarjeta, la conexión con cada medio) viene hecho.

Cuándo elegirlo

• Tienes web pero no equipo de desarrollo: basta con quien pueda editarla una vez.
• Vendes pocos artículos o un catálogo estable, y cada uno puede llevar su botón.
• Quieres el trabajo más corto que existe sin renunciar a cobrar desde tu sitio.

Si no puedes tocar tu página en absoluto, o si necesitas cobrar dentro de una conversación (WhatsApp, Instagram, correo), el canal es el Link de Pago: ese sí arranca sin integración, desde el panel.

Cómo se integra

Todos los canales de Luka corren sobre el mismo contrato: tu backend pide un token con tus credenciales, crea el cobro, y el resultado te vuelve por webhook. En el Botón de Pago la parte que te toca es la más corta de todos los canales: el script y el botón.

Eso significa que cambiar de canal, o añadir uno, no te obliga a reescribir la integración: cambia por dónde entra la transacción, no cómo la concilias.

Un sitio de cobro propio y personalizado, sin que tengas que construirlo.

Qué resuelve

No todos los cobros nacen de una compra. Hay negocios que cobran facturas, mensualidades, servicios o cuotas, y lo que necesitan no es un checkout dentro de una tienda: es un sitio donde su cliente entre, se identifique y pague lo que debe.

El Portal de Pagos es ese sitio, con tu marca, sin que tengas que construirlo ni mantenerlo. Los cobros que entran por ahí se gestionan de forma centralizada junto con los del resto de canales.

Cuándo elegirlo

• Cobras de forma recurrente a clientes identificados: servicios, colegiaturas, condominios, seguros, suscripciones fuera de una tienda.
• No tienes ni quieres mantener una web de cobro propia.
• Tu cliente necesita consultar qué debe antes de pagar, no solo pagar un monto que le pasas.

Qué necesitas de tu lado

• Tu identidad de marca: logo y colores.
• La definición de qué consulta tu cliente para saber qué debe, y con qué dato se identifica.
• Un endpoint de webhook si vas a conciliar automáticamente contra tu sistema.

Cómo se integra

Todos los canales de Luka corren sobre el mismo contrato: tu backend pide un token con tus credenciales, crea el cobro, y el resultado te vuelve por webhook. En el Portal, buena parte del trabajo lo hace Luka: tu integración se concentra en el webhook y, si aplica, en la consulta de deuda.

Eso significa que cambiar de canal, o añadir uno, no te obliga a reescribir la integración: cambia por dónde entra la transacción, no cómo la concilias.

El cobro dentro del sistema con el que ya trabaja tu empresa, sin cambiar de herramienta.

Qué resuelve

Cuando una empresa ya opera sobre un ERP, meter un canal de cobro por fuera significa duplicar trabajo: alguien tiene que pasar los pagos de un sistema al otro, y ahí es donde aparecen los descuadres. Este canal lleva el cobro dentro del software que ya usas, de modo que la transacción y su registro contable son el mismo hecho.

Cuándo elegirlo

• Tu operación vive en un ERP y el cobro es hoy un paso manual fuera de él.
• Te descuadra la conciliación entre lo cobrado y lo registrado.
• Tienes equipo técnico o un partner que pueda tocar el ERP.

Cómo se integra

Todos los canales de Luka corren sobre el mismo contrato: tu backend pide un token con tus credenciales, crea el cobro, y el resultado te vuelve por webhook. Aquí el contrato se consume desde tu ERP en vez de desde una web: mismo token, mismo cobro, mismo webhook.

Eso significa que cambiar de canal, o añadir uno, no te obliga a reescribir la integración: cambia por dónde entra la transacción, no cómo la concilias.

En qué monedas cobras y con qué medios. Los habilitados en tu cuenta dependen de tu mercado, tu contrato y tu configuración.

Lo que Luka resuelve y no es un simple cobro: cuotas, financiamiento, recurrencia y fidelización.

Pago de Solicitud en Cuotas

1. Recibirás una solicitud de pago por correo electrónico (desde la dirección de notificaciones configurada en Luka) o SMS con el nombre de la empresa solicitante y el monto a pagar.
2. Ingresa al correo y haz clic en Pagar.
3. Selecciona la opción de Tarjeta de Pago en Cuotas como método de pago.
4. Selecciona el método de pago que utilizarás.
5. En el siguiente cuadro podrás ver la información correspondiente a las cuotas: la cantidad de cuotas, los días a pagar y el monto a pagar en cada cuota. Para seguir, haz clic en Continuar.
6. Dependiendo del método de pago que seleccionaste en el cuarto paso, deberás seguir los pasos correspondientes. Puedes ver cómo pagar con los diferentes métodos de pago disponibles en Luka en los siguientes manuales:
   Pagar en dólares con Luka
   Pagar en bolívares con Luka
7. Después de realizar el primer pago, recibirás un correo con un enlace. Al ingresar, podrás ver las cuotas pagadas y las que faltan por pagar, y tendrás la opción de pagar la siguiente o varias cuotas. Para realizar el pago, selecciona las cuotas que desees pagar y haz clic en Pagar. Serás redirigido a un Link de Pago donde podrás seguir los pasos descritos en los manuales mencionados en el paso anterior.

La tecnología para vender a crédito: evaluación y cobranza automatizadas dentro de tu propio cobro. El capital no es de Luka.

Qué resuelve

Financiar una venta hace que se cierre, pero monta un negocio nuevo dentro del tuyo: hay que evaluar a quién se le fía, y hay que perseguir el cobro después. Las dos cosas son trabajo continuo, y son la razón por la que muchos comercios no financian aunque les convendría.

Lo que Luka embebe en tu cobro son esas dos: la evaluación crediticia y la cobranza. Y las reglas de a quién se financia y en qué condiciones quedan bajo tu control, no bajo el de un tercero.

Qué pone Luka y qué no

La distinción no es un detalle contractual: cambia quién asume el riesgo y con quién se negocia.

• Luka pone la tecnología: el motor de evaluación, el motor de reglas, la generación del plan de cuotas, la automatización de la cobranza y el cobro, sobre el mismo contrato de integración que cualquier otro canal.
• Luka no pone el capital y no asume el riesgo de crédito: no presta, no aprueba ni rechaza por su cuenta, y no fija tasas ni plazos.
• El capital y la política de riesgo son tuyos, o de la institución financiera que participe en tu operación. Con quién se estructura se define en tu caso.

Cuándo elegirlo

• Tu ticket es alto y sabes que pierdes ventas por el precio de contado.
• Ya financias a mano y la cobranza te está costando personas.
• Quieres poner tú las reglas de riesgo en vez de aceptar las de un tercero.

El cargo recurrente se ejecuta solo, con la autorización del cliente ya dada.

Qué resuelve

En un cobro recurrente, el enemigo no es el precio: es la fricción de pagar otra vez. Cada mes que tu cliente tiene que acordarse, entrar y autorizar, es un mes en el que puede no hacerlo. La domiciliación invierte el problema: la autorización se da una vez y el cargo se ejecuta después sin intervención.

En qué se diferencia de Suscripciones

Suscripciones gestiona el plan: qué se cobra, cada cuánto, a quién, y qué pasa cuando cambia. La domiciliación es el mecanismo de cobro que puede estar debajo. Se usan juntas a menudo, pero no son lo mismo, y un plan de suscripción puede cobrarse por otros medios.

Cuándo elegirla

• Cobras lo mismo, a los mismos, de forma periódica.
• La morosidad que tienes es por olvido, no por falta de fondos.
• Tu cliente acepta autorizar una vez a cambio de no volver a pensar en ello.

Tu cliente autoriza su tarjeta una vez y tú cobras cada período sin volver a pedírsela.

Qué resuelve

Un cobro que se repite tiene un problema que no tiene un cobro suelto: cada período vuelves a depender de que tu cliente esté, se acuerde y quiera. Las suscripciones cortan esa dependencia. El cliente afilia su tarjeta una vez, queda guardada en bóveda, y a partir de ahí el cargo lo lanzas tú cuando toca, sin pedirle nada otra vez.

Los datos de la tarjeta no pasan por tus servidores: los captura la librería de Luka y se tokenizan contra el procesador. Tú guardas el identificador que Luka te devuelve, lo asocias a tu cliente en tu propia base de datos, y cobras contra ese identificador.

En qué se diferencia de Domiciliación

Suscripciones cobra contra una tarjeta afiliada, y el cargo lo lanza tu sistema cuando decide. La domiciliación es una autorización sobre otros medios, y el mecanismo de cobro es otro. Un mismo plan puede cobrarse por cualquiera de las dos, y por eso están separadas.

Cuándo elegirlo

• Cobras un plan periódico y quieres controlar tú cuándo se lanza cada cargo.
• Tu cliente paga con tarjeta y no quieres volver a pedirle los datos.
• No quieres alcance PCI: la tarjeta la captura y la guarda Luka, no tú.

Tratar distinto a clientes distintos, en el momento del pago y no después.

Qué resuelve

La mayoría de los programas de fidelización actúan después de la compra: se acumulan puntos, se envía un correo, se espera que el cliente vuelva. El momento en el que el cliente está decidiendo, que es el checkout, pasa igual para todos.

Esto lo mueve al checkout: segmentación dinámica e incentivos por nivel que se aplican mientras el cliente paga, no en una campaña posterior.

Cuándo tiene sentido

• Tienes clientes recurrentes y hoy los tratas a todos igual.
• Tu margen aguanta un incentivo a cambio de frecuencia o ticket.
• Sabes distinguir a tus segmentos: sin eso, segmentar no tiene con qué operar.

El contrato técnico: ambientes, autenticación, la librería, el API del link, las transacciones, los webhooks y la conciliación.

De cero a un cobro de prueba conciliado. Cinco pasos, y ninguno exige tocar los medios de pago.

1. Pide tus credenciales. Tu equipo de delivery te entrega usuario y contraseña para calidad y para producción, la URL de la librería y los medios habilitados para tu comercio. Nada de eso se publica aquí.
2. Obtén un token. Tu backend llama al login con las credenciales y recibe un token que se envía en cada cobro. Las credenciales nunca salen de tu servidor.
3. Crea un cobro en calidad. Con la librería si embebes el checkout en tu web, o con el API del Link de Pago si el cobro viaja como enlace. Los dos usan el mismo token.
4. Recibe el webhook. Expón un endpoint público y concilia contra lo que llega ahí, no contra lo que ve el navegador. Es el único camino que no depende de que tu cliente siga en la página.
5. Pasa a producción. Cambia las credenciales y la URL de la librería por las de producción. El contrato es idéntico: no hay código que reescribir.

Qué necesitas antes de empezar

• Una cuenta de comercio activa en Luka, en calidad y en producción.
• Un backend donde guardar las credenciales y pedir el token.
• Un endpoint público para recibir el webhook.
• Una decisión sobre el canal: por dónde va a entrar la transacción. Si aún no la tienes, empieza por la sección Canales de cobro.

Dónde seguir

Si vas a embeber el pago en tu web o tu app, la referencia completa es Checkout con Luka JS. Si el cobro viaja como enlace, es Link de Pago API en Integrar. Y en cualquier caso, Webhooks y pagos asincrónicos explica el único comportamiento que sorprende a todo el mundo la primera vez.

La URL de cada ambiente se especifica a continuación:

• Calidad: https://luka-api-qa.payco.net.ve
• Producción: https://api.lukapay.io

En los documentos estará denotada como URL.

La librería en cada ambiente

El checkout embebido carga una librería distinta según el ambiente. Es la misma versión y el mismo contrato; cambia el origen:

<!-- Calidad -->
<script src="https://cdn.lukapay.io/QA/v2.5/dist/luka.v2.5.min.js"></script>

<!-- Producción -->
<script src="https://cdn.lukapay.io/v2.5/dist/luka.v2.5.min.js"></script>

Credenciales separadas

Calidad y producción son entornos independientes: las credenciales de uno no sirven en el otro, y el token que obtienes en calidad sólo vale contra la URL de calidad. Guarda cada juego en tu backend y nunca en el navegador.

Cómo pasar a producción

Valida el flujo completo en calidad, incluido el webhook, y después cambia tres cosas: la URL base, las credenciales y la URL de la librería. El contrato de los endpoints no cambia entre ambientes.

Para poder utilizar el API, el comercio debe contar con las credenciales asociadas a la configuración del comercio, tanto para calidad como para producción, en relación a: monedas que acepta, medios de pago e interfaz gráfica. Estas credenciales se entregarán una vez iniciado el proceso de delivery.

La autenticación se realiza a través de un token que retorna el método de login con las credenciales proporcionadas por Luka.

La URL está especificada en Ambientes.

Solicitud

POST {URL}/api/v1/servicio/login

Cabeceras

Content-Type: application/json

Cuerpo de la solicitud

{
  "Username": "usuario_comercio",
  "Password": "password-comercio"
}

Respuesta

El token se encuentra en el header de la respuesta de la consulta como se muestra a continuación:

HTTP/1.1 200 OK
Date: Mon, 27 Mar 2023 21:53:05 GMT
Content-Type: text/plain; charset=utf-8
Server: Kestrel
Content-Length: 0
token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
id: 0dd5b4f6-31e7-4251-aa39-d4a6f8bf0509
api-supported-versions: 1.0

Introducción

La librería Luka JS proporciona un objeto llamado luka que tiene tres métodos públicos:

• init()
• updateMonto()
• updateEmail()

La autenticación se realiza a través del token que retorna el método de login con las credenciales proporcionadas por Luka.

init

Función que inicializa y renderiza el componente en el nodo HTML especificado en el parámetro de entrada.

Parámetros de entrada

Propiedades de objetos

montoObj

config

terminos

paypal

extraObj

montoOriginal

cuotasConfig

Parámetros de salida

La librería devuelve el objeto de la respuesta a través de la función que se indica en la propiedad callback proporcionada en el método init.

Propiedades de objetos

CargosAdicionales

Cuotas

Propiedades del objeto contenido en el array Cuotas del objeto Cuotas

InfoProceso

InfoTarjeta

InfoUsuarioPagador

TarjetaHabiente

Ejemplo de uso

luka.init("eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c",
    'container',
    {
        "monto": 16.03,
        "numeroDecimales": null,
        "separadorMiles": "",
        "separadorDecimal": ""
    },
    "demo@example.com",
    "xxxxxxxxxxxxxx",
    {
      formBorde: false,
      moneda: "USD",
      terminos:  {
        "tipo": "1"
      },
      idioma: "esp",
      color: "c41616",
      metodos: "zelle,paypal",
      paypal: {
        color: "gold"
      },
      fuente: "Montserrat",
      seleccion: 2,
      showSkeletonLoading: true,
      fnValidacionEsAsync: true,
      guardarEnBoveda: false,
      horizontal: false,
      estilos: {
        "color": "#0516b1"
      }
    },
    function (result, error) {
        if (error) {
            //código para manejar el error
        } else {
          if (result.Exitoso) {
            //código para transacción exitosa
          } else {
            //código para transacción fallida
          }
        }
      },
    function () {
 	//código de validación interna
    	return true;
    },
    function () {
    	//código con componente cargado
    },
    {
      "nombrePagador": "John Doe",
      "referenciaPago": "151515",
      "lukapayId": "548791",
      "cuotasConfig": {
         "idConfig": "4"
      }
    }
 );

updateMonto

Permite actualizar el monto a pagar en el componente. Esta función puede ser utilizada cuando se desea cambiar el monto de la transacción después de que el componente ha sido inicializado.

Parámetros de entrada

Parámetros de salida

La función devuelve true o false para indicar si se actualizó o no el monto.

Ejemplo de uso

luka.updateMonto(28.14,
"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"
);

updateEmail

Permite actualizar el correo del pagador en el componente. Puede usarse cuando el correo cambia después de que el componente se inicializó.

Parámetros de entrada

Parámetros de salida

La función devuelve true o false para indicar si se actualizó o no el monto.

Ejemplo de uso

luka.updateEmail("cliente@ejemplo.com",
"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"
);

Webhooks para pagos diferidos

Nuestra plataforma valida en línea la referencia de pago registrada por el usuario. Si no se encuentra automáticamente, la transacción se marca como "Pendiente por revisión" y se reintenta hasta 5 veces cada 2 minutos. Si aún no se encuentra, se revisa manualmente. En estos casos, el usuario es notificado por correo. En la integración, el campo Exitoso será true, pero se debe verificar InfoProceso.EstatusProcesamiento para conocer el estatus real del pago: success (exitoso) o pending (pendiente). El estatus final se envía a través de un webhook.

Ver más sobre webhooks.

Demo

El demo de la implementación de la librería está disponible en:

https://qa.lukapay.io/demo.luka.v2

Introducción

Este contiene las especificaciones para implementar el Link de Pago de Luka. Para poder utilizar el API, el comercio debe contar con las credenciales asociadas a la configuración del comercio, tanto para calidad como para producción, en relación a: monedas que acepta, medios de pago e interfaz gráfica. Estas credenciales se entregarán una vez iniciado el proceso de delivery.

La URL está especificada en Ambientes.

La autenticación se realiza a través de un token (JWT) que retorna el método de login con las credenciales proporcionadas por Luka. Ver documentación.

Creación de Link de pago

La creación del Link de Pago se realiza desde la API con las siguientes especificaciones:

Request

POST {URL}/api/v1/link/token

Headers

Content-Type: application/json
Authorization: Bearer {token}

Body

Response

Header

Se recibirá un código 201 y encontrará la URL del link de pago en el header Location de la respuesta.

Ejemplos de uso

Request body

{
  "MonedaCodigo": "USD",
  "Monto": 12.2,
  "MetodosPago": [
    "zelle"
  ],
  "Referencia": "",
  "IdTraza": "",
  "Email": "ejemplo@mail.com"
}

Response header

HTTP/1.1 201 Created
Server: nginx/1.16.1
Date: Tue, 09 Aug 2022 20:09:13 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 0
Connection: keep-alive
Location: https://qa.lukapay.me/payco/b262a06e-f073-465c-89e5-5a54934bb4af
id-link: b262a06e-f073-465c-89e5-5a54934bb4af
nro-orden: 3372
api-supported-versions: 1.0

URL de Retorno

El sistema está en la capacidad de redirigir la página una vez finalizado el proceso de pago en el Link de Luka. En este caso, el comercio debe indicar una URL que será configurada en la aplicación para tal fin.

En caso de que se tenga configurada una URL de retorno, se enviará a través de la URL un objeto codificado en base64 con la respuesta exitosa o fallida.

Estructura de la respuesta exitosa

Los atributos de los objetos están especificados en Respuesta de transacción.

Estructura de la respuesta de error

Webhook Transacción exitosa

En caso que sea necesario recibir una respuesta de la transacción exitosa vía webservice, el comercio debe proporcionar el URL del endpoint que se utilizará como webhook donde se enviará el resultado del pago.

Estructura de la Webhook Transacción

Estructura del objeto InfoPago

Estructura del objeto InfoPagador

Introducción

Las suscripciones de Luka le permiten aceptar fácilmente pagos con tarjeta de crédito y débito de manera recurrente. Cuando usa esta biblioteca, Luka afilia los datos de un cliente por medio de una librería en JavaScript sin que necesite tener cumplimiento de PCI, ya que los datos de pago del comprador se tokenizan y se envían directamente a los servidores de los procesadores de pago.

Una vez que el cliente otorga su consentimiento y el método de pago queda tokenizado, la empresa puede iniciar pagos recurrentes mediante la API conforme al calendario y las condiciones previamente aceptadas por el cliente. Este se podrá listar las tarjetas de un suscriptor y eliminarlas en caso que no se desee seguir realizando pagos con esa tarjeta.

Requerimientos

Para poder realizar la afiliación del suscriptor y sus métodos de pago es necesario integrar la librería JavaScript de Luka.

Luego por medio de nuestra API Rest podrá realizar los pagos recurrentes, listar y eliminar las tarjetas de crédito de un cliente.

Métodos disponibles

El proceso de suscripciones se divide en dos partes:

Crear token del suscriptor: Afiliación de tarjetas de crédito/débito y almacenamiento en bóveda vía Luka JS.

Checkout:: Crear una transacción para un comprador existente vía API Rest:

• Autenticación
• Obtener lista de tarjetas del cliente
• Pagar con una tarjeta de crédito de la bóveda
• Eliminar una tarjeta de crédito de la bóveda.

Crear token del suscriptor

A continuación se proporcionan las especificaciones para implementar la librería JavaScript de Luka que se utilizará para la afiliación de los clientes y la tokenización de sus medios de pago.

Métodos de pago

Implementación de Luka JS

Ver documentación de librería Luka JS.

Registrar tarjeta

Dependiendo de la moneda seleccionada, el usuario debe completar el formulario de registro introduciendo los datos de la tarjeta de crédito/débito.

Checkout

Este método se usa para generar un cargo mensual al comprador registrado desde la aplicación del comercio quien controla el flujo de pago de un extremo a otro.
Pasos necesarios para este flujo:

• Generar un token para la autenticación de la aplicación.
• Recopile y envíe información de pago del comprador vía API Rest.
• Obtenga el objeto con la respuesta LukaPaymentResult.
• Complete la transacción en la aplicación del comercio.

La URL está especificada en Ambientes.

La autenticación se realiza a través de un token (JWT) que retorna el método de login con las credenciales proporcionadas por Luka. Ver documentación.

Obtener la lista de tarjetas del cliente.

Este método permitirá obtener el listado de las tarjetas que el cliente tiene registradas en la bóveda. Este paso es necesario para poder indicar cuál tarjeta de crédito se usará para realizar el pago con dólares americanos (USD).

Para obtener las tarjetas del cliente deberá proporcionar el valor del campo LukapayId que se devuelve en al momento de crear el token de la tarjeta y que el comercio debe asociar al usuario en su propia base de datos.

Las especificaciones del método son las siguientes:

Solicitud

GET {URL}/api/v1/tarjetacredito/servicio/{LukapayId}

Cabeceras

Content-Type: application/json
Authorization: Bearer {token}

Respuesta

Cuerpo

Se devuelve una lista de objetos con la siguiente información de la tarjetas de crédito/débito

Ejemplos de uso

Solicitud

GET {URL}/api/v1/tarjetacredito/servicio/560356a272d9

Cuerpo de la respuesta

[
  {
    "Id": 1,
    "UltimosCuatroDigitos": "1111",
    "SubTipoTarjeta": "CREDIT",
    "TipoTarjeta": "VISA",
    "CategoriaTarjeta": "CONSUMER",
    "Bin": "111111",
    "FechaVencimiento": "03/2023",
    "Pais": "US",
    "EstaBoveda": true,
    "Direccion": {
      "Id": 0,
      "Direccion": "Calle 1",
      "Ciudad": "Guatire",
      "Estado": "Miranda",
      "CodigoPostal": "1111"
    },
    "Descripcion": ""
  }
]

Pagar con una tarjeta de crédito de la bóveda

A través de esta función podrá generar una solicitud de pago con la información de la tarjeta registrada previamente por el usuario.

Pagar con USD

Este método requiere la información de la tarjeta de crédito/débito obtenida en el flujo "Obtener lista de tarjetas del cliente" para el objeto.

Las especificaciones del método son las siguientes:

Solicitud

POST {URL}/api/v1/transaccion

Cabeceras

Content-Type: application/json
Authorization: Bearer {token}

Cuerpo

Propiedades del objetos

TarjetaCredito

TarjetaHabiente

Respuesta

Los atributos de los objetos están especificados en Respuesta de transacción.

Ejemplos de uso

{
  "Monto": 100,
  "TarjetaHabiente": {
    "Nombre": "Jhon",
    "Apellido": "Doe",
    "LukapayId": "560356a272d9"
  },
  "TarjetaCredito": {
    "Id": 1,
    "UltimosCuatroDigitos": "1111",
    "SubTipoTarjeta": "CREDIT",
    "TipoTarjeta": "VISA",
    "CategoriaTarjeta": "CONSUMER",
    "Bin": "111111",
    "FechaVencimiento": "03/2023",
    "Pais": "US"
  },
  "IdTraza": "1234567890",
  "Moneda": "USD",
  "EmailTarjetaHabiente": "usuario@mail.com",
  "IdCanal": 2,
  "Referencia": "000265700237"
}

{
  "Monto": 100,
  "MontoUsd": 100,
  "InfoProceso": {
    "EstatusProcesamiento": "success",
    "CodigoRespuestaCvv": "N/D"
  },
  "TarjetaHabiente": {
    "Nombre": "Jhon",
    "Apellido": "Doe",
    "LukapayId": "560356a272d9",
    "NumeroIdentificacionPersonal": null,
    "NumeroTelefono": null
  },
  "InfoUsuarioPagador": {
    "Nombre": "Jhon",
    "Apellido": "Doe",
    "NumeroIdentidad": null,
    "NumeroTelefono": null,
    "Email": "usuario@mail.com"
  },
  "Moneda": "USD",
  "InfoTarjeta": {
    "Id": 1,
    "UltimosCuatroDigitos": "1111",
    "SubTipoTarjeta": "CREDIT",
    "TipoTarjeta": "VISA",
    "CategoriaTarjeta": "CONSUMER",
    "Bin": "111111",
    "FechaVencimiento": "03/2023",
    "Pais": "US"
  },
  "TransaccionId": 102143,
  "TransaccionMerchantId": 1108334200,
  "Descripcion": "success",
  "TrazaId": "1234567890",
  "Exitoso": true,
  "Canal": "Api",
  "MedioDePago": "Débito",
  "MontoOriginal": null,
  "MerchantId": null,
  "FechaOperacion": null,
  "CargosAdicionales": null,
  "Cuotas": null
}

Pagar con CLP

Para pagar con una tarjeta registrada para pesos chilenos no hace falta seleccionar una tarjeta, solamente se necesita enviar el LukapayId.

Las especificaciones del método son las siguientes:

Solicitud

POST {URL}/api/v1/transaccion/transbank.authorize

Cabeceras

Content-Type: application/json
Authorization: Bearer {token}

Cuerpo

Respuesta

Los atributos de los objetos están especificados en Respuesta de transacción.

Ejemplos de uso

Cuerpo de la solicitud

{
  "Moneda": "CLP",
  "Monto": 100,
  "TrazaId": "1234567890",
  "LukapayId": "560356a272d9",
  "Email": "example@mail.com",
  "Referencia": ""
}

Cuerpo de la respuesta

{
  "Monto": 100,
  "MontoUsd": 0,
  "InfoProceso": {
    "EstatusProcesamiento": "success",
    "CodigoRespuestaCvv": null
  },
  "TarjetaHabiente": {
    "Nombre": "John",
    "Apellido": "Doe",
    "NumeroIdentificacionPersonal": "",
    "NumeroTelefono": null,
    "LukapayId": "6353a328-ef92-454d-826b-f59a01ca62d3"
  },
  "InfoUsuarioPagador": {
    "Nombre": "John",
    "Apellido": "Doe",
    "NumeroIdentidad": null,
    "NumeroTelefono": null,
    "Email": "example@mail.com"
  },
  "Moneda": "CLP",
  "InfoTarjeta": null,
  "TransaccionId": 102144,
  "TransaccionMerchantId": 1108334200,
  "Descripcion": "transacción exitosa",
  "TrazaId": "1234567890",
  "Exitoso": true,
  "Canal": "Api",
  "MedioDePago": "Transbank",
  "MontoOriginal": null,
  "MerchantId": null,
  "FechaOperacion": null,
  "CargosAdicionales": null,
  "Cuotas": null
}

Verificar el estado de una transacción

Ver Consulta de transacciones.

Eliminar una tarjeta de crédito de la bóveda

Este método permitirá eliminar una tarjeta de crédito de la bóveda. Se debe enviar el ID de la tarjeta a eliminar y el LukapayId del usuario.

Las especificaciones del método son las siguientes:

Solicitud

• USD:

DELETE {URL}/api/v1/tarjetacredito/{idTarjeta}/user/{LukapayId}

• CLP

DELETE {URL}/api/v1/transaccion/transbank.unsubscribe/{LukapayId}

Cabeceras

Content-Type: application/json
Authorization: Bearer {token}

Respuesta

El método devuelve el código estado de respuesta 202 (Accepted) en caso de que la operación sea exitosa, de lo contrario se devuelve un código de error.

Códigos de errores

Para recuperar el estado de un pago se envía como parámetro el valor del campo TrazaId. Este campo es el mismo que se envía al momento de crear la transacción y corresponde al identificador único de la operación en el sistema del cliente.

Las especificaciones del método son las siguientes:

Solicitud

GET {URL}/api/v1/transaccion?{parameter}={parameterValue}

Cabeceras

Content-Type: application/json

Parámetros

Se puede consultar una transacción por los siguientes campos:

Respuesta

La respuesta tiene la estructura de Respuesta de transacción.

Ejemplo de uso

Solicitud

GET {URL}/api/v1/transaccion?trazaId=e824b569323f

Cuerpo de la respuesta

[
  {
    "Monto": 1.03,
    "MontoUsd": 0,
    "InfoProceso": null,
    "TarjetaHabiente": null,
    "InfoUsuarioPagador": {
      "Nombre": "Jhon",
      "Apellido": "Doe",
      "NumeroIdentidad": null,
      "NumeroTelefono": null,
      "Email": "jhon@example.com"
    },
    "Moneda": "USD",
    "InfoTarjeta": null,
    "TransaccionId": 10130,
    "TransaccionMerchantId": 0,
    "Descripcion": "transacción aprobada",
    "TrazaId": "e824b569323f",
    "Exitoso": true,
    "Canal": "Link de pago",
    "MedioDePago": "Zelle",
    "MontoOriginal": null,
    "MerchantId": null,
    "FechaOperacion": "06/21/2022 17:35:51",
    "CargosAdicionales": null,
    "Cuotas": null
  }
]

La respuesta de transacción viene dada por la siguiente estructura:

Propiedades de objetos

CargosAdicionales

Cuotas

Propiedades del objeto contenido en el array Cuotas del objeto Cuotas

InfoProceso

InfoTarjeta

InfoUsuarioPagador

TarjetaHabiente

Valores de Canal

Canal viaja como texto, no como número: el identificador numérico vive dentro de Luka y se traduce antes de responderte. Los literales son sensibles a mayúsculas, así que compáralos tal cual:

Introducción

Este documento proporciona las especificaciones para implementar la notificación de pagos en efectivo a través del API de Luka. Este servicio consta de dos partes: la primera es la consulta de la deuda del cliente, la cual nos permite conocer el monto a pagar y el segundo paso que consiste en procesar el pago.

La URL está especificada en Ambientes.

La autenticación se realiza a través de un token (JWT) que retorna el método de login con las credenciales proporcionadas por Luka. Ver documentación.

Consultar una transacción

Permite consultar la información de un pago que está pendiente por confirmación.

Se puede consultar la transacción a través de la referencia de pago enviada por el comercio al momento de registrar el pago. En caso de que el comercio no envíe una referencia, se puede consultar la transacción con el número de la transacción que devuelve Luka o por el código de autorización que devuelve el método de pago.

Las especificaciones del método son las siguientes:

Solicitud

GET {URL}/api/v1/transaccion/pagodiferido

Cabeceras

Content-Type: application/json
Authorization: Bearer <token>

Parámetros

Los siguientes parámetros se envían a través del querystring del a consulta

Respuesta

Los atributos de los objetos están especificados en Respuesta de transacción.

Ejemplo de uso

Solicitud

GET {URL}/api/v1/transaccion/pagodiferido?referenciaPago=6567704

Cuerpo de la respuesta

{
  "Monto": 7.99,
  "MontoUsd": 0,
  "InfoProceso": {
    "EstatusProcesamiento": "pending",
    "CodigoRespuestaCvv": null
  },
  "InfoUsuarioPagador": {
    "Nombre": "Jhon",
    "Apellido": "Doe",
    "NumeroIdentidad": null,
    "NumeroTelefono": null,
    "Email": "example@mail.com"
  },
  "Moneda": "USD",
  "TransaccionId": 96336,
  "TransaccionMerchantId": 0,
  "Descripcion": "transacción en revisión",
  "TrazaId": "e6c28df3ae4f",
  "Exitoso": true,
  "Canal": "Api",
  "MedioDePago": "Efectivo",
  "MontoOriginal": null,
  "MerchantId": "024PeR42",
  "FechaOperacion": "2023-09-29 19:25:11.767791+00:00",
  "CargosAdicionales": null,
  "Cuotas": null
}

Notificar pago

Permite actualizar el estado de una transacción luego de haber recibido el pago correspondiente.

Solicitud

PUT {URL}/api/v1/transaccion/pagodiferido/actualizar

Cabeceras

Content-Type: application/json
Authorization: Bearer <token>

Cuerpo de la solicitud

Respuesta

Ejemplos de uso

Cuerpo de la solicitud

{
  "IdTx": 123456,
  "IdEstatus": 6,
  "Observaciones": "",
  "Terminal": "Agencia CCCT, Taquilla 2",
  "CodigoAutorizacion": "12345"
}

Cuerpo de la respuesta

{
  "Monto": 16.03,
  "Id": 8357,
  "IdTraza": "1234567890",
  "CodigoAutorizacion": "kjfkgds874k",
  "Estatus": {
    "Id": 6,
    "Descripcion": "Tx Exitosa"
  },
  "FechaCreacion": "2022-02-23T18:27:47.1959116Z"
}

Debido a su naturaleza, los pagos a través de Zelle y Pago Móvil se hacen de forma diferida, es decir, el cliente paga directamente en su banco y luego registra el código de autorización en nuestra plataforma.

Luka tiene la capacidad de validar en línea la referencia registrada por el usuario, sin embargo, es posible que se equivoque al momento de escribirla, lo cual podría ocasionar que no la encuentre de forma automática. En este caso, Luka marca la transacción con el estado Pending (pendiente).

Cuando la transacción queda con estado pendiente, se vuelve a revisar automáticamente cada 2 minutos hasta reflejarse la transacción en la cuenta, pero, si de todas formas no se encuentra, se hace una revisión manual. En esta revisión manual, se aprueba o rechaza la transacción indicando el motivo del rechazo. En ambos casos, el cliente recibirá un email con el resultado de la operación.

A efectos de la integración, en la respuesta, el campo Exitoso tendrá el valor true pero también se debe revisar la propiedad InfoProceso.EstatusProcesamiento, la cual indica el estatus real del pago. Las 2 posibilidades son: success (exitoso) o pending (pendiente):

{
  "Monto": 16.03,
  "MontoUsd": 0,
  "InfoProceso": {
    "EstatusProcesamiento": "pending"
  },
  "TarjetaHabiente": {
    "Nombre": "",
    "Apellido": ""
  },
  "Moneda": "USD",
  "InfoTarjeta": {
    "Id": 0,
    "UltimosCuatroDigitos": "",
    "SubTipoTarjeta": "",
    "TipoTarjeta": "",
    "CategoriaTarjeta": "",
    "Bin": "",
    "FechaVencimiento": "",
    "Pais": "",
    "Direccion": "",
    "CodigoPostal": "",
    "Descripcion": ""
  },
  "InfoUsuarioPagador": {
    "Nombre": "Dennis",
    "Apellido": "Castillo",
    "Email": "cliente@ejemplo.com"
  },
  "TransaccionId": 11339,
  "TransaccionMerchantId": 0,
  "Descripcion": "Tx Pendiente",
  "TrazaId": "d225cd97-f3bd-40ad-a92f-ae05f72eb042",
  "Exitoso": true,
  "MedioDePago": "Zelle",
  "Canal": "API",
  "MontoOriginal": {
    "Monto": 16.03,
    "Moneda": "USD",
    "ComisionMerchant": 0.76487
  },
  "MerchantId": null,
  "FechaOperacion": null,
  "CargosAdicionales": null,
  "Cuotas": null
}

En caso de que la transacción quede en estatus Pendiente, se debe mostrar un mensaje al usuario indicando que su pago será revisado y recibirá la respuesta vía correo.

Para recibir el estatus final de la transacción, se envía la respuesta a través de un webhook.

En este caso, el integrador debe crear una función en su API que reciba la respuesta de Luka y actualice el estatus de la transacción en su sistema.

El objeto con la respuesta que se envía a través del método POST y tiene el siguiente formato:

[
  {
    "Monto": 16.03,
    "Id": 8357,
    "IdTraza": "1234567890",
    "CodigoAutorizacion": "kjfkgds874k",
    "Estatus": {
      "Id": 6,
      "Descripcion": "Tx Exitosa"
    },
    "Fecha": "2022-02-23T18:27:47.0170155Z",
    "FechaCreacion": "2022-02-23T18:27:47.1959116Z"
  },
  {
    "Monto": 1,
    "Id": 3547,
    "IdTraza": "1234567890",
    "CodigoAutorizacion": "kljghdfjg45646",
    "Estatus": {
      "Id": 7,
      "Descripcion": "Tx Fallida"
    },
    "Fecha": "2021-04-23T22:10:29.4103Z",
    "FechaCreacion": "2021-04-23T22:10:29.4519723Z"
  }
]

Nota: Una vez creado el endpoint del webhook, se debe enviar esta información al equipo de desarrollo de Luka para proceder a configurarlo en el servicio.

Cómo saber si un pago está realmente cobrado, qué hacer cuando queda pendiente, y con qué identificador se cierra la conciliación.

Los tres estados que hay que leer

Una transacción tiene tres capas de estado, y confundirlas es lo que produce entregas contra pagos que nunca se acreditaron:

Estados que devuelve Luka

Los valores de abajo son los que documenta el contrato. Los nombres técnicos se escriben tal cual llegan: no los traduzcas ni los normalices en tu sistema.

Qué ocurre con un pago pendiente

Cuando el cliente paga en su banco y registra la referencia (el caso típico del pago móvil y de Zelle), Luka intenta validarla en línea. Si no la encuentra, la transacción queda pendiente y se vuelve a revisar automáticamente cada dos minutos hasta que aparezca. Si aun así no aparece, pasa a revisión manual, donde se aprueba o se rechaza indicando el motivo.

Mientras tanto, muéstrale al cliente que su pago está en revisión y que recibirá la respuesta. El desenlace te llega por webhook, no por la pantalla.

Con qué identificador se concilia

• IdTraza: el identificador que pones tú y que viaja de ida y de vuelta. Es el que ata el cobro a tu factura, tu pedido o tu contrato.
• Id: el identificador de la transacción en Luka. Es el que da soporte cuando hay que investigar un caso.
• MerchantId: la referencia de la transacción del lado del comercio, tal como la devuelve la respuesta.

Concilia contra el webhook y contra la consulta de transacciones, no contra la URL de retorno del navegador: esa sólo dice que el cliente volvió a tu sitio.

Si el webhook no llegó

Consulta la transacción por su identificador. La consulta y el webhook cuentan lo mismo, y tener las dos vías es lo que permite cerrar un caso sin depender de que una notificación llegara.

Lo que tu equipo opera cada día sin tocar código.

Preguntas Frecuentes

¿Por qué no me aparecen los pagos de meses anteriores?

Este reporte muestra la información del mes actual, para acceder a meses anteriores debe hacer clic en el filtro del mes y seleccionar el que desea consultar. También puede verificar una fecha según un rango de transacciones en el módulo de reportes.

¿Por qué todo sale en una sola moneda y se refleja un total?

El reporte muestra la moneda según la configuración de recepción de fondos del comercio, es decir, la moneda de abono en cuenta. El monto total es la sumatoria de todas las monedas ya convertidas, según la tasa real al momento de pago.

¿Cómo se calcula la tasa de conversión de mis pagos?

La tasa de cambio se consulta en tiempo real y Luka muestra la tasa utilizada en cada transacción: Luka no cobra ni genera ingresos por diferenciales de tasa. No se realizan conversiones para las monedas controladas por sus gobiernos (como el bolívar de Venezuela o el peso argentino). La disponibilidad de conversión y la tasa aplicada dependen de tu mercado y de la configuración de tu cuenta.

¿Dónde puedo ver todas las transacciones recibidas?

Todas las transacciones pueden ser ubicadas en el módulo de Reportes según país, sucursal y otros filtros.

¿Las ventas brutas incluyen la comisión de Luka?

Sí, están incluidas las comisiones de Luka. Para calcular el desembolso, debe descargarse en el módulo de reportes las transacciones detalladas.

¿Dónde puedo ver la comisión de Luka?

En el módulo de reportes, haga clic en el detalle de la transacción, el cual contiene el campo de referencia al cargo por transacción.

Este documento proporciona una guía paso a paso para la creación de solicitudes de pago individuales y por lote en la plataforma Luka Business.

Sigue las instrucciones a continuación para completar tus solicitudes de pago de manera rápida y efectiva.

Pago Individual

1. Ingresa a business.lukapay.io/access e inicia sesión con tus credenciales.
2. En el menú lateral, selecciona Solicitudes de Pago.
3. Selecciona la Sucursal y el Servicio que deseas cobrar y haz clic en Nueva Solicitud Individual.
4. En Enviar Solicitud, selecciona la opción de correo electrónico o teléfono, ingresa los datos de la persona a la que se le enviará la solicitud, elige el tipo de moneda y el monto a cobrar.
5. Confirma que los datos ingresados sean los correctos y haz clic en Enviar.

En los comentarios puedes colocar el concepto de la solicitud.

Pago por Lote

1. Ingresa a business.lukapay.io/access e inicia sesión con tus credenciales.
2. En el menú lateral, selecciona Solicitudes de Pago.
3. Selecciona la Sucursal y el Servicio que deseas cobrar y haz clic en Nueva Solicitud por Lote.
4. Descarga la plantilla de ejemplo, completa los campos requeridos manteniendo la primera fila del archivo sin cambios y súbelo con la base de datos en formato csv.
5. Una vez subido el archivo, verifica que al final de cada registro exista un check de validación para asegurarte de que el link será enviado. Si observas una "x", regresa al documento y corrige cualquier error que pueda existir antes de subirlo nuevamente. Cuando todos los registros tengan la validación, haz clic en Enviar.
6. Al procesar la solicitud, recibirás un correo de confirmación.

Estado de solicitudes enviadas

1. Ingresa a business.lukapay.io/access e inicia sesión con tus credenciales.
2. Haz clic en Reportes en la barra lateral izquierda.
3. Ingresa al módulo de Solicitudes y selecciona Detalles de Solicitud.

Guía de estatus

• Solicitud exitosa: el pago fue realizado con éxito.
• Solicitud pendiente: el pago aún no se ha realizado.
• Solicitud expirada: se agotó el plazo para realizar el pago.

Preguntas Frecuentes

¿Por qué tengo que seleccionar una sucursal y un servicio?

Las solicitudes van ligadas a la sucursal y el comercio. Para proceder con la solicitud, debe seleccionar al menos una de ellas.

¿Por qué no me aparecen habilitadas todas mis sucursales o servicios?

Para poder realizar una solicitud, debe tener configurada la opción de link de pago. En caso de que no aparezca su sucursal, debe contactar a support@lukapay.io para validar su contrato de servicio.

¿Qué significa solicitud individual y solicitud en lote?

Las solicitudes individuales se realizan en base a un solo cliente, utilizando su teléfono o correo. Las solicitudes en lote deben cargarse mediante un archivo CSV que contenga todos los clientes a los que desea solicitar el pago. Debe incluir el correo o teléfono del cliente.

¿Cuándo me pueden bloquear una solicitud?

Si el sistema detecta un comportamiento irregular en sus solicitudes, la herramienta será bloqueada automáticamente. Deberá contactar a un representante de Luka.

¿Cuándo expira una solicitud y cuántas veces se puede utilizar el enlace?

Todas las solicitudes tienen un tiempo de expiración de 15 a 30 días hábiles, según el requerimiento del cliente, y solo pueden ser utilizadas una vez.

Preguntas Frecuentes

¿Por qué aparece que no me puede procesar el reembolso?

Los reembolsos son procesados según los autorizadores y dependen del período de tiempo desde el inicio del pago hasta la solicitud del reembolso. En este caso, debe contactar a un representante de Luka a través de support@lukapay.io para verificar su caso.

¿Cómo ubico el ID de una transacción?

Todas las transacciones tienen un ID único que las identifica en el reporte de Transacciones.

¿Cómo puedo pedir un reporte específico para mi empresa?

Los reportes pueden ser solicitados a través de support@lukapay.io. Para esto, debe incluir el motivo y un ejemplo del reporte, lo cual pasará por un proceso de validación y cotización según las horas de desarrollo requeridas.

¿Cómo me descargo los reportes en Excel?

Los reportes, una vez realizada la consulta, pueden descargarse a través del enlace de descarga. El único formato disponible actualmente es una hoja de cálculo (Excel).

Perfiles de usuario

Owner

Tiene acceso completo a:

• Perfiles de todas las marcas que su negocio tenga activas en Luka.
• Todos los paneles de control: reportes, solicitudes de pago, pagos diferidos, reembolsos y usuarios.
• Tiene permisos para crear y modificar usuarios de todas las sucursales que pertenezcan a las marcas de su negocio en Luka.

Administrador

Tiene acceso completo a:

• Un solo perfil de marca.
• Todos los paneles de control: reportes, solicitudes de pago, pagos diferidos, reembolsos y usuarios.

Tiene permisos para:

• Visualizar todos los reportes de las sucursales de marca a las que pertenece el usuario
• Enviar solicitudes de pago
• Aprobar/Rechazar pagos diferidos
• Hacer solicitudes de reembolsos (solo aplica para pagos con TDC en USD)
• Crear y modificar la lista de usuarios de la sucursal a la que pertenece
• Resetear la clave de los usuarios

Operador

Acceso limitado a:

• Visualización del panel de control
• Visualización y descarga de reportes de la sucursal a la que pertenece el usuario
• Visualización de pagos diferidos

Operador Ampliado

Acceso limitado a:

• Visualización del panel de control
• Visualización y descarga de reportes de la sucursal a la que pertenece el usuario
• Envío de solicitudes de pago
• Aprobar/Rechazar pagos diferidos

Agregar un usuario

1. Ingresa a business.lukapay.io/access e inicia sesión con tus credenciales.
2. En el menú lateral haz clic en Usuarios.
3. Selecciona el botón Agregar usuario del lado derecho de la pantalla.
4. Completa los datos solicitados y haz clic en Guardar.

Eliminar un usuario

1. Ingresa a business.lukapay.io/access e inicia sesión con tus credenciales.
2. En el menú lateral, selecciona Usuarios.
3. Ubica al usuario que deseas eliminar en el panel de control y selecciona la opción de eliminar (Papelera).
4. Confirma que deseas eliminar al usuario.

Desactivar un usuario

1. Ingresa a business.lukapay.io/access e inicia sesión con tus credenciales.
2. En el menú lateral, selecciona Usuarios.
3. Ubica al usuario que deseas editar en el panel de control y haz clic en el botón de modificar a la derecha (Lápiz).
4. Despliega la lista, selecciona Inactivo y confirma.

¿Cómo recuperar mi contraseña de usuario del dashboard de Luka?

1. Para recuperar su contraseña, lo primero que debe hacer es seleccionar la opción “Forgot your password?” en la página de inicio de sesión del Dashboard.
2. Ingrese el correo asociado a la cuenta y haga clic en “Reset password”.
3. Al terminar, podrá observar un mensaje similar al siguiente:
   Tu contraseña ha sido cambiada.
4. Luego, recibirá un correo que le redirigirá a la página en la cual debe establecer su nueva contraseña.

En caso de tener problemas para ingresar al Dashboard, asegúrese de tener acceso al correo que fue configurado para la sucursal en primera instancia. Si se requiere el uso de otro correo, la solicitud debe venir vía correo de parte de la alta gerencia.

Qué hacer cuando el documento no responde tu pregunta, y qué tener a mano para que la respuesta llegue en una vuelta.

Vera, soporte técnico

Vera es el agente de operaciones y soporte de Luka. Es el primer sitio al que llevar una duda de integración: conoce el contrato, los ambientes y los estados de transacción, y escala a una persona cuando hace falta.

Escríbele a support@lukapay.io.

Qué tener a mano

Una duda de integración se resuelve en una vuelta o en cinco, y la diferencia casi siempre es esta lista:

• El ambiente: calidad o producción. La mitad de los reportes se explican solos al decirlo.
• El idTraza del cobro, si ya llegaste a crear uno. Es lo que permite seguir la transacción de punta a punta.
• El canal por el que entra el cobro: checkout embebido, link de pago, portal, facturación, presencial o ERP.
• La respuesta completa que recibiste, no solo el mensaje de error: el cuerpo entero, tal cual llegó.
• Si el problema es de conciliación, si te llegó el webhook o no. Es la primera bifurcación.

Lo que este documento no publica

Hay cosas que dependen de tu comercio y por eso no están aquí: los medios de pago habilitados para tu cuenta, las claves de configuración de cada método, y las URL y credenciales de tus ambientes. Todo eso lo entrega tu equipo de delivery cuando se abre tu cuenta. Si no lo tienes, pídelo por el mismo canal.

Choose where to start

The sections of this document, in the order you need them: what happens in a charge first, how to integrate and operate it last.

What happens between your customer deciding to pay and the money being reconciled. No code yet.

You integrate once with Luka. Behind it there are many providers, and that part stops being your problem.

The problem it avoids

Accepting many payment methods, across several countries and currencies, usually means integrating with many different providers: each with its own API, its own way of authenticating, its own response format and its own outages. That work is not done once: it is maintained forever, and it grows with every method you add.

With Luka you integrate once. Adding or removing a payment method becomes a matter of your business configuration, not a development project.

What it means for your team

• A single technical contract: token, payment, webhook. The same one for every method.
• A single place to reconcile, instead of one report per provider.
• Luka runs the connection with the providers and reduces the impact their changes have on the merchant's integration.

The Luka payment gateway allows you to manage financial transactions securely and efficiently, facilitating payment processing with multiple methods, such as credit or debit cards, in various currencies. End users interact directly with the gateway from the merchant's website, where they select products or services and complete the payment process without leaving the merchant's environment.

Payment data entry, including card information and email address, is handled through Luka JS, which validates and processes the transaction securely via our API. Each merchant using the Luka payment gateway is identified with a unique authentication token, ensuring the integrity and traceability of transactions.

The gateway also supports appearance customization to match the merchant's visual identity, ensuring a consistent and brand-aligned user experience. Additionally, you can easily manage transactions using our dashboard.

Luka provides tools designed to adapt to the specific needs of each business, standing out for:

• A flexible API, easy to integrate into various platforms.
• Compatibility with multiple payment methods, including cards and alternative methods.
• Support for transactions in multiple currencies, with automatic conversion.

How it Works

1. The user accesses the merchant's website.
2. The website loads the Luka JS library script.
3. The merchant initializes the Luka JS object, providing the authentication token and the necessary configuration.
4. The Luka JS library sends an HTTPS request to the Luka API to validate the provided token.
5. The API responds, indicating that the token is valid.
6. Luka JS renders the available payment methods for the merchant on the website.
7. The user enters their payment information, such as card details and email address.
8. Luka JS sends an HTTPS request to the Luka API to validate the user's entered email.
9. The API responds, indicating that the email is valid.
10. Luka JS sends another HTTPS request to the Luka API to process the payment using the provided user information.
11. Exitoso: true does not confirm approval on its own. Check InfoProceso.EstatusProcesamiento; if it is pending, wait for the webhook or look the transaction up.
12. Luka JS returns in the callback function with the transaction details.
13. The merchant shows the result according to InfoProceso.EstatusProcesamiento: it confirms the purchase if it is success; if it is pending, it tells the customer the payment is under review.

The payment gateway integration is detailed in the API.

How the User Pays

• Bolivar: 1 item
• Dollar: 1 item

Where the transaction comes in. It is the first decision: the channel defines your customer's experience and the integration work.

The payment embedded inside your own site or app. The customer never leaves your site.

What it solves

Your customer has already decided to buy and is on your site or in your app. Every extra step you put between that decision and the payment is a chance to abandon. The Checkout embeds the payment window inside your page: the customer picks the method and pays without going anywhere else.

This is the channel where Luka puts its differentiator: the checkout is dynamic, meaning the payment methods, the financing and the promotions each customer sees depend on your business configuration, not on a fixed list.

When to choose it

• You have your own site or app and control over its code.
• The volume justifies the integration work: it is the channel that asks the most from your technical team, and the only one where the customer never leaves your site.
• You want the brand to be yours from the start of the payment to the end.

If you have no development capacity available, or you need to start collecting this week, start with the Payment Link and move to the Checkout when you have the team. The contract is the same, so no work is thrown away.

What you need on your side

• A page with a container in the DOM: the payment window is drawn inside it.
• A backend that keeps your credentials and requests the token. Credentials never go in the browser.
• A public endpoint that receives the webhook, which is what you reconcile against.

How it is integrated

Every Luka channel runs on the same contract: your backend requests a token with your credentials, creates the payment, and the result comes back to you by webhook. In the Checkout, the payment is drawn with the JavaScript library, which receives the token and the container where it must render.

That means changing channel, or adding one, does not force you to rewrite the integration: what changes is where the transaction comes in, not how you reconcile it.

The full contract of the library, with its input and output parameters, is in Checkout with Luka JS, under Integrate.

A solution designed to integrate payment and disbursement systems in B2B environments. Through its flexible architecture, it enables the generation of payment links compatible with various methods and providers, both local and international.

• Enable local & international payment methods and providers
• Use any messaging channel: SMS, WhatsApp, email, social media, or your app
• Simplify payment experiences for your customers
• Manage all payment links from one intuitive dashboard

How it works

For the merchant:

1. The merchant provides the payer's details (email or phone number and amount) to our API. This can be done either through the dashboard or directly via the API.
2. Our system sends the customer a notification via email or SMS with the generated Payment Link.
3. The merchant receives a successful confirmation along with the Payment Link URL.

For the customer:

1. Receives a notification via email or SMS with the Payment Link.
2. Opens the received Payment Link.
3. Completes the process following the steps outlined in the payment gateway starting from step 6.

One by one or in bulk

A link is created from the panel for one customer, with their email or phone number, the currency and the amount. If there are many, they are loaded in bulk: you download the template, fill it in without touching the first row and upload it as a CSV with all your customers. The panel validates every record before sending and confirms by email when they have gone out.

Custom references

Every link carries your system's reference (the ReferenciaServicio field when you create it through the API, or the concept in the comments when you do it from the panel) and that reference comes back with the result of the transaction. That way the payment arrives already tied to the invoice, the order or the customer you reconcile it with, without cross-checking lists by hand.

Validity

Every link is used once and expires between 15 and 30 business days, depending on what you request. The state of each request (successful, pending, expired) is followed in Reports.

When you want to create them from your own system, the contract is in Payment Link (API).

A button next to what you sell: the work comes down to placing it on your page.

What it solves

Not everyone who sells online has a development team, and not everyone who sells online needs one. The Payment Button is a payment placed next to what you sell: the customer clicks and pays without you building a checkout.

Compared with the Dynamic Checkout, which draws the payment window inside your site and asks your team to build the container and the flow around it, here the only thing done on your page is placing the button and loading the Luka script. Everything else (the window, card capture, the connection to each payment method) comes ready.

When to choose it

• You have a website but no development team: someone who can edit it once is enough.
• You sell few items, or a stable catalog, and each one can carry its own button.
• You want the shortest possible work without giving up charging from your own site.

If you cannot touch your page at all, or you need to charge inside a conversation (WhatsApp, Instagram, email), the channel is the Payment Link: that one really does start with no integration, from the dashboard.

How it is integrated

Every Luka channel runs on the same contract: your backend requests a token with your credentials, creates the payment, and the result comes back to you by webhook. With the Payment Button your share of it is the shortest of any channel: the script and the button.

That means changing channel, or adding one, does not force you to rewrite the integration: what changes is where the transaction comes in, not how you reconcile it.

Your own branded payment site, without having to build it.

What it solves

Not every payment starts with a purchase. Some businesses collect invoices, monthly fees, services or installments, and what they need is not a checkout inside a store: it is a site where their customer signs in, identifies themselves and pays what they owe.

The Payment portal is that site, with your brand, without you having to build it or maintain it. Charges that come in there are managed centrally alongside those from every other channel.

When to choose it

• You collect from identified customers on a recurring basis: services, tuition, building fees, insurance, subscriptions outside a store.
• You do not have, and do not want to maintain, your own payment site.
• Your customer needs to check what they owe before paying, not just pay an amount you send them.

What you need on your side

• Your brand identity: logo and colors.
• The definition of what your customer looks up to know what they owe, and which piece of data identifies them.
• A webhook endpoint if you are going to reconcile automatically against your system.

How it is integrated

Every Luka channel runs on the same contract: your backend requests a token with your credentials, creates the payment, and the result comes back to you by webhook. In the Portal, Luka does much of the work: your integration concentrates on the webhook and, where it applies, on the balance lookup.

That means changing channel, or adding one, does not force you to rewrite the integration: what changes is where the transaction comes in, not how you reconcile it.

The payment inside the system your company already works with, without changing tools.

What it solves

When a company already runs on an ERP, adding a payment channel outside it means duplicating work: someone has to move payments from one system to the other, and that is where the mismatches appear. This channel puts the payment inside the software you already use, so the transaction and its accounting record are the same event.

When to choose it

• Your operation lives in an ERP and the payment is a manual step outside it today.
• Reconciliation does not add up between what was charged and what was recorded.
• You have a technical team or a partner who can work on the ERP.

How it is integrated

Every Luka channel runs on the same contract: your backend requests a token with your credentials, creates the payment, and the result comes back to you by webhook. Here the contract is consumed from your ERP instead of from a website: same token, same charge, same webhook.

That means changing channel, or adding one, does not force you to rewrite the integration: what changes is where the transaction comes in, not how you reconcile it.

Which currencies you collect in and with which methods. The ones enabled on your account depend on your market, your contract and your configuration.

What Luka solves beyond a simple payment: installments, financing, recurrence and loyalty.

Paying a request in installments

1. You receive a payment request by email (from the notification address configured in Luka) or SMS with the name of the requesting company and the amount to pay.
2. Open the email and click Pay.
3. Choose Installment payment card as the payment method.
4. Choose the payment method you will use.
5. The next panel shows the installment details: the number of installments, the payment dates and the amount due in each one. To go on, click Continue.
6. Depending on the payment method you chose in step four, follow the corresponding steps. You can see how to pay with each of the payment methods available at Luka in these manuals:
   Paying in US dollars with Luka
   Paying in bolivars with Luka
7. After the first payment you receive an email with a link. Opening it shows the installments already paid and the ones still due, with the option to pay the next one or several. To pay, select the installments you want and click Pay. You are taken to a Payment Link, where you follow the steps described in the manuals mentioned in the previous step.

The technology for selling on credit: assessment and collections automated inside your own payment flow. The capital is not Luka's.

What it solves

Financing a sale helps close it, but it sets up a new business inside yours: you have to assess who gets credit, and you have to chase the payment afterwards. Both are continuous work, and they are the reason many businesses do not finance even when it would pay off.

What Luka embeds in your payment flow is exactly those two: credit assessment and collections. And the rules about who gets financed and on what terms stay under your control, not a third party's.

What Luka provides, and what it does not

The distinction is not a contractual footnote: it changes who carries the risk and who you negotiate with.

• Luka provides the technology: the assessment engine, the rules engine, the installment plan, the collections automation and the collection itself, on the same integration contract as any other channel.
• Luka does not put up the capital and does not carry the credit risk: it does not lend, it does not approve or decline on its own, and it does not set rates or terms.
• The capital and the risk policy are yours, or those of the financial institution taking part in your operation. Who it is structured with is defined in your case.

When to choose it

• Your ticket is high and you know you lose sales to the up-front price.
• You already finance by hand and collections is costing you people.
• You want to set the risk rules yourself instead of accepting someone else's.

The recurring payment runs on its own, with the customer's authorization already given.

What it solves

In a recurring payment the enemy is not the price: it is the friction of paying again. Every month your customer has to remember, sign in and authorize is a month they might not. Direct debit turns the problem around: authorization is given once and the payment runs afterwards with no intervention.

How it differs from Subscriptions

Subscriptions manages the plan: what is collected, how often, to whom, and what happens when it changes. Direct debit is the collection mechanism that can sit underneath. They are often used together, but they are not the same thing, and a subscription plan can be collected by other means.

When to choose it

• You collect the same amount, from the same people, periodically.
• The arrears you have come from forgetfulness, not from lack of funds.
• Your customer will authorize once in exchange for never thinking about it again.

Your customer authorizes their card once and you charge every period without asking again.

What it solves

A recurring charge has a problem a one-off charge does not: every period you depend again on your customer being there, remembering, and wanting to. Subscriptions cut that dependency. The customer enrolls their card once, it is kept in the vault, and from then on you trigger the charge when it is due, without asking for anything again.

Card data never passes through your servers: the Luka library captures it and it is tokenized against the processor. You store the identifier Luka returns, associate it with your customer in your own database, and charge against that identifier.

How it differs from Direct Debit

Subscriptions charge against an enrolled card, and your system triggers the charge when it decides to. Direct debit is an authorization over other payment methods, and the charging mechanism is a different one. The same plan can be charged through either, which is why they are kept apart.

When to choose it

• You charge a recurring plan and want to control when each charge is triggered.
• Your customer pays by card and you do not want to ask for the details again.
• You do not want PCI scope: Luka captures and stores the card, not you.

Treating different customers differently, at the moment of payment and not afterwards.

What it solves

Most loyalty programs act after the purchase: points accumulate, an email goes out, the customer is expected to come back. The moment the customer is deciding, which is the checkout, passes the same way for everyone.

This moves it to the checkout: dynamic segmentation and tier-based incentives applied while the customer pays, not in a later campaign.

When it makes sense

• You have recurring customers and today you treat them all the same.
• Your margin can carry an incentive in exchange for frequency or ticket size.
• You can tell your segments apart: without that, segmentation has nothing to work with.

The technical contract: environments, authentication, the library, the link API, transactions, webhooks and reconciliation.

From zero to a reconciled test payment. Five steps, and none of them requires touching the payment methods.

1. Request your credentials. Your delivery team gives you a username and password for QA and for production, the library URL and the methods enabled for your business. None of that is published here.
2. Get a token. Your backend calls the login with the credentials and receives a token that is sent with every payment. The credentials never leave your server.
3. Create a test payment in QA. With the library if you embed the checkout in your site, or with the Payment Link API if the payment travels as a link. Both use the same token.
4. Receive the webhook. Expose a public endpoint and reconcile against what arrives there, not against what the browser sees. It is the only path that does not depend on your customer staying on the page.
5. Move to production. Swap the credentials and the library URL for the production ones. The contract is identical: there is no code to rewrite.

What you need before you start

• An active Luka merchant account, in QA and in production.
• A backend where you keep the credentials and request the token.
• A public endpoint to receive the webhook.
• A decision about the channel: where the transaction comes in. If you have not made it yet, start with the Payment channels section.

Where to go next

If you are embedding the payment in your site or app, the full reference is Checkout with Luka JS. If the payment travels as a link, it is Payment Link API under Integrate. And in either case, Webhooks and asynchronous payments explains the one behavior that surprises everyone the first time.

The URL for each environment is specified below:

• Testing: https://luka-api-qa.payco.net.ve
• Production: https://api.lukapay.io

In the documents, it will be referred to as URL.

The library in each environment

The embedded checkout loads a different library depending on the environment. It is the same version and the same contract; what changes is the origin:

<!-- QA -->
<script src="https://cdn.lukapay.io/QA/v2.5/dist/luka.v2.5.min.js"></script>

<!-- Production -->
<script src="https://cdn.lukapay.io/v2.5/dist/luka.v2.5.min.js"></script>

Separate credentials

QA and production are independent environments: the credentials of one do not work in the other, and the token you get in QA is only valid against the QA URL. Keep each set in your backend and never in the browser.

How to move to production

Validate the whole flow in QA, webhook included, and then change three things: the base URL, the credentials and the library URL. The endpoint contract does not change between environments.

To use the API, the merchant must have credentials associated with the merchant's configuration, both for testing and production environments, regarding accepted currencies, payment methods, and graphical interface. These credentials will be provided once the delivery process begins.

Authentication is done via a token returned by the login method using the credentials provided by Luka.

The URL is specified in Environments.

Request

POST {URL}/api/v1/servicio/login

Headers

Content-Type: application/json

Body

{
  "Username": "merchant_user",
  "Password": "merchant_password"
}

Response

The token is located in the response header as shown below:

HTTP/1.1 200 OK
Date: Mon, 27 Mar 2023 21:53:05 GMT
Content-Type: text/plain; charset=utf-8
Server: Kestrel
Content-Length: 0
token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
id: 0dd5b4f6-31e7-4251-aa39-d4a6f8bf0509
api-supported-versions: 1.0

Introduction

The Luka JS library provides an object called luka that has three public methods:

• init()
• updateMonto()
• updateEmail()

Authentication is done through the token returned by the login method using the credentials provided by Luka.

init

Function that initializes and renders the component in the HTML node specified in the input parameter.

Input Parameters

Object Properties

montoObj

config

terminos

paypal

extraObj

montoOriginal

cuotasConfig

Output Parameters

The library returns the response object through the function specified in the callback property provided in the init method.

Object Properties

CargosAdicionales

Cuotas

Object Properties within the Cuotas Array

InfoProceso

InfoTarjeta

InfoUsuarioPagador

TarjetaHabiente

Ejemplo de uso

luka.init("eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c",
    'container',
    {
        "monto": 16.03,
        "numeroDecimales": null,
        "separadorMiles": "",
        "separadorDecimal": ""
    },
    "demo@example.com",
    "xxxxxxxxxxxxxx",
    {
      formBorde: false,
      moneda: "USD",
      terminos:  {
        "tipo": "1"
      },
      idioma: "esp",
      color: "c41616",
      metodos: "zelle,paypal",
      paypal: {
        color: "gold"
      },
      fuente: "Montserrat",
      seleccion: 2,
      showSkeletonLoading: true,
      fnValidacionEsAsync: true,
      guardarEnBoveda: false,
      horizontal: false,
      estilos: {
        "color": "#0516b1"
      }
    },
    function (result, error) {
        if (error) {
            //error handle code
        } else {
          if (result.Exitoso) {
            //success transfer
          } else {
            //failed transfer
          }
        }
      },
    function () {
 	//intern validation code
    	return true;
    },
    function () {
    	//code with loaded component
    },
    {
      "nombrePagador": "John Doe",
      "referenciaPago": "151515",
      "lukapayId": "548791",
      "cuotasConfig": {
         "idConfig": "4"
      }
    }
 );

updateMonto

This function allows you to update the amount to be paid within the component. It can be used when you need to change the transaction amount after the component has been initialized.

Input Parameters

Output Parameters

The function returns true or false to indicate whether the amount was successfully updated.

Usage Example

luka.updateMonto(28.14,
"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"
);

updateEmail

This function allows you to update the email associated with the transaction within the component. It can be used when you need to change the email after the component has been initialized.

Input Parameters

Output Parameters

The function returns true or false to indicate whether the email was successfully updated.

Usage Example

luka.updateEmail("cliente@ejemplo.com",
"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"
);

Webhooks for Asynchronous Payments

Our platform validates the payment reference provided by the user in real-time. If the reference is not automatically found, the transaction is marked as "Pending Review" and retried up to 5 times, with attempts every 2 minutes. If it still cannot be found, the transaction is reviewed manually. In such cases, the user is notified via email. In the integration, the Exitoso field will be marked as true, but you must check InfoProceso.EstatusProcesamiento to determine the actual status of the payment: either success (successful) or pending. The final status is sent through a webhook.

Learn more about webhooks.

Demo

You can access the demo implementation of the library at:

https://qa.lukapay.io/demo.luka.v2

Introduction

This contains the specifications for implementing the Luka Payment Link. In order to use the API, the merchant must have the credentials associated with the merchant configuration, both for quality and production, in relation to: accepted currencies, payment methods and graphical interface. These credentials will be delivered once the delivery process has started.

The URL is specified in Environments.

Authentication is done via a token (JWT) returned by the login method using the credentials provided by Luka. See documentation.

Payment Link Creation

The Payment Link is created through the API with the following specifications:

Request

POST {URL}/api/v1/link/token

Headers

Content-Type: application/json
Authorization: Bearer {token}

Body

Response

Header

A 201 code will be received, and the payment link URL will be found in the Location header of the response.

Usage examples

Request body

{
  "MonedaCodigo": "USD",
  "Monto": 12.2,
  "MetodosPago": [
    "zelle"
  ],
  "Referencia": "",
  "IdTraza": "",
  "Email": "ejemplo@mail.com"
}

Response header

HTTP/1.1 201 Created
Server: nginx/1.16.1
Date: Tue, 09 Aug 2022 20:09:13 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 0
Connection: keep-alive
Location: https://qa.lukapay.me/payco/b262a06e-f073-465c-89e5-5a54934bb4af
id-link: b262a06e-f073-465c-89e5-5a54934bb4af
nro-orden: 3372
api-supported-versions: 1.0

Return URL

The system can redirect the page once the payment process on the Luka Link is completed. In this case, the merchant must provide a URL that will be configured in the application for this purpose.

If a return URL is configured, an object encoded in base64 with the successful or failed response will be sent through the URL.

Successful Response Structure

The attributes of the objects are specified in Transaction Response.

Error Response Structure

Successful Transaction Webhook

If necessary, the merchant can provide the endpoint URL that will be used as a webhook where the result of the payment will be sent via webservice for successful transactions.

Webhook Transaction Structure

InfoPago Object Structure

InfoPagador Object Structure

Introduction

Luka subscriptions allow you to easily accept recurring credit and debit card payments. When using this library, Luka affiliates a customer’s data through a JavaScript library without needing PCI compliance, as the buyer’s payment data is tokenized and sent directly to payment processors' servers.

After the customer provides consent and the payment method is tokenized, your business can initiate recurring payments through the API according to the schedule and terms previously accepted by the customer. The system allows listing a subscriber’s cards and deleting them if payments with that card are no longer desired.

Requirements

To affiliate the subscriber and their payment methods, it is necessary to integrate the Luka JavaScript library.

Afterward, through our REST API, you can make recurring payments, list, and delete a customer’s credit cards.

Available Methods

The subscription process is divided into two parts:

Create subscriber token: Credit/Debit card affiliation and storage in the vault via Luka JS.

Checkout: Create a transaction for an existing buyer via REST API:

• Authentication
• Retrieve the customer's card list
• Pay with a vault-stored credit card
• Delete a credit card from the vault.

Create Subscriber Token

Below are the specifications for implementing the Luka JavaScript library, which will be used for customer affiliation and tokenization of their payment methods.

Payment Methods

Luka JS Implementation

See Luka JS Library Documentation.

Register Card

Depending on the selected currency, the user must complete the registration form by entering credit/debit card information.

Checkout

This method is used to generate a recurring charge for the registered buyer from the merchant's application, which controls the payment flow from end to end.

Necessary steps for this process:

• Generate a token for application authentication.
• Collect and send the buyer's payment information via REST API.
• Retrieve the response object LukaPaymentResult.
• Complete the transaction within the merchant's application.

The URL is specified in Environments.

Authentication is performed via a token (JWT) returned by the login method using the credentials provided by Luka. See Documentation.

Retrieve Customer Card List

This method allows you to get the list of cards that the customer has registered in the vault. This step is essential to specify which credit card will be used to make payments in US dollars (USD).

To retrieve the customer's cards, you must provide the LukapayId value, which is returned when creating the card token, and the merchant must associate it with the user in their own database.

Request

GET {URL}/api/v1/tarjetacredito/servicio/{LukapayId}

Headers

Content-Type: application/json
Authorization: Bearer {token}

Response

Body

The response returns a list of objects containing the following credit/debit card information:

Example Usage

Request

GET {URL}/api/v1/tarjetacredito/servicio/560356a272d9

Response Body

[
  {
    "Id": 1,
    "UltimosCuatroDigitos": "1111",
    "SubTipoTarjeta": "CREDIT",
    "TipoTarjeta": "VISA",
    "CategoriaTarjeta": "CONSUMER",
    "Bin": "111111",
    "FechaVencimiento": "03/2023",
    "Pais": "US",
    "EstaBoveda": true,
    "Direccion": {
      "Id": 0,
      "Direccion": "Calle 1",
      "Ciudad": "Guatire",
      "Estado": "Miranda",
      "CodigoPostal": "1111"
    },
    "Descripcion": ""
  }
]

Pay with a Credit Card from the Vault

This function allows you to make a payment request using the credit/debit card information previously registered by the user.

Pay in USD

This method requires the credit/debit card information obtained from the "Get Customer Card List" flow to proceed with the payment.

Request

POST {URL}/api/v1/transaccion

Headers

Content-Type: application/json
Authorization: Bearer {token}

Body

Properties of the Objects

TarjetaCredito

TarjetaHabiente

Response

Example Usage

{
  "Monto": 100,
  "TarjetaHabiente": {
    "Nombre": "Jhon",
    "Apellido": "Doe",
    "LukapayId": "560356a272d9"
  },
  "TarjetaCredito": {
    "Id": 1,
    "UltimosCuatroDigitos": "1111",
    "SubTipoTarjeta": "CREDIT",
    "TipoTarjeta": "VISA",
    "CategoriaTarjeta": "CONSUMER",
    "Bin": "111111",
    "FechaVencimiento": "03/2023",
    "Pais": "US"
  },
  "IdTraza": "1234567890",
  "Moneda": "USD",
  "EmailTarjetaHabiente": "usuario@mail.com",
  "IdCanal": 2,
  "Referencia": "000265700237"
}

{
  "Monto": 100,
  "MontoUsd": 100,
  "InfoProceso": {
    "EstatusProcesamiento": "success",
    "CodigoRespuestaCvv": "N/D"
  },
  "TarjetaHabiente": {
    "Nombre": "Jhon",
    "Apellido": "Doe",
    "LukapayId": "560356a272d9",
    "NumeroIdentificacionPersonal": null,
    "NumeroTelefono": null
  },
  "InfoUsuarioPagador": {
    "Nombre": "Jhon",
    "Apellido": "Doe",
    "NumeroIdentidad": null,
    "NumeroTelefono": null,
    "Email": "usuario@mail.com"
  },
  "Moneda": "USD",
  "InfoTarjeta": {
    "Id": 1,
    "UltimosCuatroDigitos": "1111",
    "SubTipoTarjeta": "CREDIT",
    "TipoTarjeta": "VISA",
    "CategoriaTarjeta": "CONSUMER",
    "Bin": "111111",
    "FechaVencimiento": "03/2023",
    "Pais": "US"
  },
  "TransaccionId": 102143,
  "TransaccionMerchantId": 1108334200,
  "Descripcion": "success",
  "TrazaId": "1234567890",
  "Exitoso": true,
  "Canal": "Api",
  "MedioDePago": "Débito",
  "MontoOriginal": null,
  "MerchantId": null,
  "FechaOperacion": null,
  "CargosAdicionales": null,
  "Cuotas": null
}

Pay with CLP

To process a payment in Chilean pesos (CLP) using a previously registered card, you only need to provide the LukapayId along with the transaction details. Below are the method specifications.

Request

POST {URL}/api/v1/transaccion/transbank.authorize

Headers

Content-Type: application/json
Authorization: Bearer {token}

Request Body

Response

For more details on the response objects, see Transaction Response.

Example

Request body

{
  "Moneda": "CLP",
  "Monto": 100,
  "TrazaId": "1234567890",
  "LukapayId": "560356a272d9",
  "Email": "example@mail.com",
  "Referencia": ""
}

Response body

{
  "Monto": 100,
  "MontoUsd": 0,
  "InfoProceso": {
    "EstatusProcesamiento": "success",
    "CodigoRespuestaCvv": null
  },
  "TarjetaHabiente": {
    "Nombre": "John",
    "Apellido": "Doe",
    "NumeroIdentificacionPersonal": "",
    "NumeroTelefono": null,
    "LukapayId": "6353a328-ef92-454d-826b-f59a01ca62d3"
  },
  "InfoUsuarioPagador": {
    "Nombre": "John",
    "Apellido": "Doe",
    "NumeroIdentidad": null,
    "NumeroTelefono": null,
    "Email": "example@mail.com"
  },
  "Moneda": "CLP",
  "InfoTarjeta": null,
  "TransaccionId": 102144,
  "TransaccionMerchantId": 1108334200,
  "Descripcion": "transacción exitosa",
  "TrazaId": "1234567890",
  "Exitoso": true,
  "Canal": "Api",
  "MedioDePago": "Transbank",
  "MontoOriginal": null,
  "MerchantId": null,
  "FechaOperacion": null,
  "CargosAdicionales": null,
  "Cuotas": null
}

Verify the Status of a Transaction

See Transaction Query.

Delete a Credit Card from the Vault

This method allows you to remove a credit card from the vault. You need to provide the card ID to be deleted and the LukapayId of the user.

Request

• For USD:

DELETE {URL}/api/v1/tarjetacredito/{idTarjeta}/user/{LukapayId}

• For CLP:

DELETE {URL}/api/v1/transaccion/transbank.unsubscribe/{LukapayId}

Headers

Content-Type: application/json
Authorization: Bearer {token}

Response

The method returns a status code of 202 (Accepted) if the operation is successful; otherwise, it returns an error code.

Errors Code

To retrieve the status of a payment, the value of the TrazaId field is sent as a parameter. This field is the same as the one sent when creating the transaction and corresponds to the unique identifier of the operation in the client's system.

The method specifications are as follows:

Request

GET {URL}/api/v1/transaccion?{parameter}={parameterValue}

Headers

Content-Type: application/json

Query Params

You can query a transaction using the following fields:

Response

The response structure is described in Transaction Response.

Usage Example

Request

GET {URL}/api/v1/transaccion?trazaId=e824b569323f

Response Body

[
  {
    "Monto": 1.03,
    "MontoUsd": 0,
    "InfoProceso": null,
    "TarjetaHabiente": null,
    "InfoUsuarioPagador": {
      "Nombre": "Jhon",
      "Apellido": "Doe",
      "NumeroIdentidad": null,
      "NumeroTelefono": null,
      "Email": "jhon@example.com"
    },
    "Moneda": "USD",
    "InfoTarjeta": null,
    "TransaccionId": 10130,
    "TransaccionMerchantId": 0,
    "Descripcion": "transacción aprobada",
    "TrazaId": "e824b569323f",
    "Exitoso": true,
    "Canal": "Link de pago",
    "MedioDePago": "Zelle",
    "MontoOriginal": null,
    "MerchantId": null,
    "FechaOperacion": "06/21/2022 17:35:51",
    "CargosAdicionales": null,
    "Cuotas": null
  }
]

The transaction response is structured as follows:

Object Properties

CargosAdicionales

Cuotas

Object Properties within the Cuotas Array

InfoProceso

InfoTarjeta

InfoUsuarioPagador

TarjetaHabiente

Canal values

Canal travels as text, not as a number: the numeric identifier lives inside Luka and is translated before you get the response. The literals are case-sensitive, so compare them exactly as they are:

Introduction

This document provides the specifications for implementing cash payment notifications through the Luka API. This service consists of two parts: the first is the customer debt query, which allows us to know the amount to be paid, and the second step is to process the payment.

The URL is specified in Environments.

Authentication is done via a token (JWT) returned by the login method using the credentials provided by Luka. See documentation.

Consult a Transaction

Allows you to query the information of a payment that is pending confirmation.

You can query the transaction through the payment reference sent by the merchant at the time of registering the payment. If the merchant does not send a reference, you can query the transaction using the transaction number returned by Luka or the authorization code returned by the payment method.

Request

GET {URL}/api/v1/transaccion/pagodiferido

Headers

Content-Type: application/json
Authorization: Bearer <token>

Query Params

The following parameters are sent via the query string of the request:

Response

The attributes of the objects are specified in Transaction Response.

Example Usage

Request

GET {URL}/api/v1/transaccion/pagodiferido?referenciaPago=6567704

Response body

{
  "Monto": 7.99,
  "MontoUsd": 0,
  "InfoProceso": {
    "EstatusProcesamiento": "pending",
    "CodigoRespuestaCvv": null
  },
  "InfoUsuarioPagador": {
    "Nombre": "Jhon",
    "Apellido": "Doe",
    "NumeroIdentidad": null,
    "NumeroTelefono": null,
    "Email": "example@mail.com"
  },
  "Moneda": "USD",
  "TransaccionId": 96336,
  "TransaccionMerchantId": 0,
  "Descripcion": "transacción en revisión",
  "TrazaId": "e6c28df3ae4f",
  "Exitoso": true,
  "Canal": "Api",
  "MedioDePago": "Efectivo",
  "MontoOriginal": null,
  "MerchantId": "024PeR42",
  "FechaOperacion": "2023-09-29 19:25:11.767791+00:00",
  "CargosAdicionales": null,
  "Cuotas": null
}

Notify Payment

Allows you to update the status of a transaction after receiving the corresponding payment.

Request

PUT {URL}/api/v1/transaccion/pagodiferido/actualizar

Headers

Content-Type: application/json
Authorization: Bearer <token>

Body

Response

Example Usage

Request body

{
  "IdTx": 123456,
  "IdEstatus": 6,
  "Observaciones": "",
  "Terminal": "Agencia CCCT, Taquilla 2",
  "CodigoAutorizacion": "12345"
}

Response body

{
  "Monto": 16.03,
  "Id": 8357,
  "IdTraza": "1234567890",
  "CodigoAutorizacion": "kjfkgds874k",
  "Estatus": {
    "Id": 6,
    "Descripcion": "Tx Exitosa"
  },
  "FechaCreacion": "2022-02-23T18:27:47.1959116Z"
}

Due to their nature, payments via Zelle and Pago Móvil are made in a asynchronous manner, meaning the customer pays directly through their bank and then records the authorization code in our platform.

Luka has the ability to validate the reference registered by the user online. However, it is possible that the user might enter it incorrectly, which could prevent the system from finding it automatically. In this case, Luka marks the transaction with the status Pending.

When a transaction is marked as pending, it is automatically checked every 2 minutes until the transaction reflects in the account. If it still cannot be found, a manual review is conducted. In this manual review, the transaction is either approved or rejected, with the reason for rejection provided. In both cases, the customer will receive an email with the result of the operation.

For integration purposes, in the response, the field Exitoso will have the value true, but it is also necessary to check the InfoProceso.EstatusProcesamiento property, which indicates the real status of the payment. The two possibilities are: success (successful) or pending (pending).

{
  "Monto": 16.03,
  "MontoUsd": 0,
  "InfoProceso": {
    "EstatusProcesamiento": "pending"
  },
  "TarjetaHabiente": {
    "Nombre": "",
    "Apellido": ""
  },
  "Moneda": "USD",
  "InfoTarjeta": {
    "Id": 0,
    "UltimosCuatroDigitos": "",
    "SubTipoTarjeta": "",
    "TipoTarjeta": "",
    "CategoriaTarjeta": "",
    "Bin": "",
    "FechaVencimiento": "",
    "Pais": "",
    "Direccion": "",
    "CodigoPostal": "",
    "Descripcion": ""
  },
  "InfoUsuarioPagador": {
    "Nombre": "Dennis",
    "Apellido": "Castillo",
    "Email": "cliente@ejemplo.com"
  },
  "TransaccionId": 11339,
  "TransaccionMerchantId": 0,
  "Descripcion": "Tx Pendiente",
  "TrazaId": "d225cd97-f3bd-40ad-a92f-ae05f72eb042",
  "Exitoso": true,
  "MedioDePago": "Zelle",
  "Canal": "API",
  "MontoOriginal": {
    "Monto": 16.03,
    "Moneda": "USD",
    "ComisionMerchant": 0.76487
  },
  "MerchantId": null,
  "FechaOperacion": null,
  "CargosAdicionales": null,
  "Cuotas": null
}

If the transaction remains in Pending status, a message should be displayed to the user, indicating that their payment will be reviewed and they will receive a response via email.

To receive the final transaction status, the response is sent via a webhook.

In this case, the integrator must create a function in their API that receives the response from Luka and updates the transaction status in their system.

The object with the response, sent through the POST method, follows this format:

[
  {
    "Monto": 16.03,
    "Id": 8357,
    "IdTraza": "1234567890",
    "CodigoAutorizacion": "kjfkgds874k",
    "Estatus": {
      "Id": 6,
      "Descripcion": "Tx Exitosa"
    },
    "Fecha": "2022-02-23T18:27:47.0170155Z",
    "FechaCreacion": "2022-02-23T18:27:47.1959116Z"
  },
  {
    "Monto": 1,
    "Id": 3547,
    "IdTraza": "1234567890",
    "CodigoAutorizacion": "kljghdfjg45646",
    "Estatus": {
      "Id": 7,
      "Descripcion": "Tx Fallida"
    },
    "Fecha": "2021-04-23T22:10:29.4103Z",
    "FechaCreacion": "2021-04-23T22:10:29.4519723Z"
  }
]

Note: Once the webhook endpoint is created, this information should be sent to the Luka development team for configuration in the service.

How to know whether a payment is really collected, what to do when it stays pending, and which identifier closes the reconciliation.

The three states you have to read

A transaction has three layers of state, and confusing them is what produces deliveries against payments that were never credited:

States Luka returns

The values below are the ones the contract documents. Technical names are written exactly as they arrive: do not translate them or normalize them in your system.

What happens with a pending payment

When the customer pays at their bank and registers the reference (the typical case of Pago Móvil and Zelle), Luka tries to validate it online. If it does not find it, the transaction stays pending and is checked again automatically every two minutes until it appears. If it still does not appear, it moves to manual review, where it is approved or rejected with a stated reason.

In the meantime, show the customer that their payment is under review and that they will receive the answer. The outcome reaches you by webhook, not on screen.

Which identifier reconciles

• IdTraza: the identifier you set, which travels out and back. It is the one that ties the payment to your invoice, your order or your contract.
• Id: the transaction identifier at Luka. It is the one support uses when a case has to be investigated.
• MerchantId: the transaction reference on the merchant side, exactly as the response returns it.

Reconcile against the webhook and against the transaction lookup, not against the browser return URL: that one only says the customer came back to your site.

If the webhook did not arrive

Look the transaction up by its identifier. The lookup and the webhook tell you the same thing, and having both paths is what lets you close a case without depending on a notification having arrived.

What your team operates every day without touching code.

Frequently Asked Questions

Why don't I see my payments from previous months?

This report shows the information for the current month. To access previous months, you must filter by month and select the one you want to consult. You can also search for a date based on a range of transactions in the reports section.

Why does it show only a single currency and a total reflected?

The report shows the currency according to the configuration of receipt of funds from the merchant, that is, the currency of credit to the account. The total amount is the sum of all the currencies already converted, according to the real rate at the time of payment.

How is the conversion rate of my payments calculated?

The exchange rate is looked up in real time and Luka shows the rate used for each transaction: Luka does not charge for it and does not earn income from rate differentials. Currencies controlled by their governments (such as the Venezuelan bolivar or the Argentine peso) are not converted. Conversion availability and the rate applied depend on your market and your account configuration.

Where can I see all received transactions?

All transactions can be located in the reports section according to country, agency, and other filters.

Are gross sales included in the Luka commission?

Yes, Luka commissions are included. To calculate the disbursement, the detailed transactions must be downloaded in the reports section.

Where can I see the Luka commission?

In the reports section, click on transaction details, which contains the reference field to the transaction fee.

This document provides a step-by-step guide for creating individual and batch payment requests on the Luka Business platform.

Follow the instructions below to complete your payment requests quickly and effectively.

Individual Payment

1. Go to business.lukapay.io/access and log in with your credentials.
2. In the sidebar menu, select Payment Requests.
3. Select the Branch and Service you wish to charge for and click on New Individual Request.
4. In the Send Request section, choose either email or phone, enter the recipient’s details, select the currency type, and the amount to be charged.
5. Confirm that the entered data is correct and click on Send.

You can include the purpose of the request in the comments.

Batch Payment

1. Go to business.lukapay.io/access and log in with your credentials.
2. In the sidebar menu, select Payment Requests.
3. Select the Branch and Service you wish to charge for and click on New Batch Request.
4. Download the sample template, complete the required fields while keeping the first row of the file unchanged, and upload it with your database in CSV format.
5. Once the file is uploaded, verify that each record has a validation checkmark at the end to ensure the link will be sent. If you see an "x", go back to the document and fix any errors before uploading it again. When all records are validated, click on Send.
6. After processing the request, you will receive a confirmation email.

Status of Sent Requests

1. Go to business.lukapay.io/access and log in with your credentials.
2. Click on Reports in the left sidebar.
3. Enter the Requests module and select Request Details.

Status Guide

• Successful request: the payment was completed successfully.
• Pending request: the payment has not yet been completed.
• Expired request: the time limit for making the payment has passed.

Frequently Asked Questions

Why do I have to choose a branch and a service?

The requests are linked to the branch and the business, and for that you must select at least one of them and proceed with the request.

Why don't all my branches or services appear enabled?

In order to make a request, you must have the payment link option configured. In case that your branch does not appear, you must contact support@lukapay.io to validate your service contract.

What does individual request and batch request mean?

Individual requests are made based on a single customer, with only their phone or email. Batch requests must be uploaded via a CSV file with all the customers you want to request payment. You should consider placing the customer's email or phone number.

When could a request be blocked?

If the system detects irregular behavior regarding your requests, the tool is automatically blocked and you must contact a Luka representative.

When does a request expire, and how many times can the link be used?

All requests have an expiration time of 15 to 30 business days, according to the client's requirement, and can only be used once.

Frequently Asked Questions

Why does it appear that it cannot process my refund?

Refunds are processed according to the authorizers and depend on the period of time from the beginning of the payment to the moment of requesting the refund. In this sense, you must contact a representative of Luka through support@lukapay.io to verify your case.

How do I find the transaction ID?

All transactions have a unique ID that identifies them in the Transactions report.

Frequently Asked Questions

Why are the Security, Account, and Balance modules disabled?

At the moment we are developing these modules; once they are active, they will be enabled for consultation.

How can I request a specific report for my business?

Reports can be requested through support@lukapay.io. For this, you must include the reason and an example of the report, which will go through a validation and quote process according to the hours of development required.

How do I download the reports in Excel?

The reports can be downloaded through the provided download link. The only format currently available is a spreadsheet (Excel).

User Profiles

Owner

Has full access to:

• Profiles of all brands that their business has active in Luka.
• All control panels: reports, payment requests, deferred payments, refunds, and users.
• Permissions to create and modify users of all branches belonging to the brands of their business in Luka.

Administrator

Has full access to:

• A single brand profile.
• All control panels: reports, payment requests, deferred payments, refunds, and users.

Permissions include:

• Viewing all reports of the brand branches to which the user belongs
• Sending payment requests
• Approving/Rejecting deferred payments
• Requesting refunds (applicable only for credit card payments in USD)
• Creating and modifying the user list of the branch to which they belong
• Resetting user passwords

Operator

Limited access to:

• Viewing the control panel
• Viewing and downloading reports for the branch to which the user belongs
• Viewing deferred payments

Extended Operator

Limited access to:

• Viewing the control panel
• Viewing and downloading reports for the branch to which the user belongs
• Sending payment requests
• Approving/Rejecting deferred payments

Add a User

1. Go to business.lukapay.io/access and log in with your credentials.
2. In the side menu, click on Users.
3. Select the Add User button on the right side of the screen.
4. Fill in the requested information and click Save.

Delete a User

1. Go to business.lukapay.io/access and log in with your credentials.
2. In the side menu, select Users.
3. Locate the user you want to delete in the control panel and select the delete option (Trash can icon).
4. Confirm that you want to delete the user.

Deactivate a User

1. Go to business.lukapay.io/access and log in with your credentials.
2. In the side menu, select Users.
3. Locate the user you want to edit in the control panel and click the edit button on the right (Pencil icon).
4. Expand the list, select Inactive, and confirm.

How to Recover Your User Password for the Luka Dashboard

1. To recover your password, first select the "Forgot your password?" option on the login page of the Dashboard.
2. Enter the email associated with your account and click "Reset password".
3. You will then see a message like the one below:
   Your password has been changed.
4. After that, you will receive an email that will redirect you to the page where you need to set your new password.

If you encounter issues accessing the Dashboard, make sure you have access to the email that was initially configured for the branch. If another email is required, the request must come via email from upper management.

What to do when the document does not answer your question, and what to have at hand so the answer arrives in one round.

Vera, technical support

Vera is Luka's operations and support agent. She is the first place to take an integration question: she knows the contract, the environments and the transaction states, and escalates to a person when it is needed.

Write to her at support@lukapay.io.

What to have at hand

An integration question is resolved in one round or in five, and the difference is almost always this list:

• The environment: QA or production. Half of all reports explain themselves once you say it.
• The idTraza of the payment, if you got as far as creating one. It is what lets the transaction be followed end to end.
• The channel the payment comes in through: embedded checkout, payment link, portal, billing, in-person or ERP.
• The full response you received, not just the error message: the whole body, exactly as it arrived.
• If the problem is reconciliation, whether the webhook reached you or not. It is the first fork in the road.

What this document does not publish

Some things depend on your business and are therefore not here: the payment methods enabled for your account, the configuration keys of each method, and the URLs and credentials of your environments. All of that is handed over by your delivery team when your account opens. If you do not have it, ask through the same channel.