Manteca

Getting Started

Introducción

Autenticación

Webhooks

Dashboard

Onboarding users

Widget

Making a payment

Sintéticos

Países soportados

Blank

API Payments

Process QR code payments across LATAM with a single integration

Docs - API Payments

Production

Sandbox

<p class="slate-p " ><strong class="slate-bold">API Payments</strong> está diseñada para empresas que buscan agilizar el proceso de pagos de sus usuarios sin incurrir en costos elevados y con la ventaja de realizar una única integración para brindar servicios en múltiples países. A través de nuestro servicio, es posible realizar pagos QR, cumpliendo con las normativas vigentes.</p><p class="slate-p " >Nuestro servicio admite:</p><ol class="slate-ol " ><li class="slate-li " ><div style="position:relative">Generación y procesamiento de pagos QR estáticos y dinámicos</div></li><li class="slate-li " ><div style="position:relative">Operaciones en descubierto con liquidación en múltiples monedas</div></li><li class="slate-li " ><div style="position:relative">Una única integración para todos los países soportados</div></li><li class="slate-li " ><div style="position:relative">Actualizaciones de estado en tiempo real</div></li><li class="slate-li " ><div style="position:relative">Seguridad y cumplimiento con estándares regulatorios locales</div></li></ol><p class="slate-p " ></p><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><h3 class="slate-h3 " >Arquitectura y formato de respuesta</h3><p class="slate-p slate-indent-0" style="0px">Manteca está organizada alrededor de la interfaz <a href="https://en.wikipedia.org/wiki/REST" target="_self">REST</a>. Tiene URLs predecibles orientadas a recursos y usa códigos de respuesta HTTP estándar. Todos los valores de retorno son en formato JSON.</p><p class="slate-p slate-indent-0" style="0px">Contamos con un sandbox para que puedas probar el API sin alterar los flujos productivos. Para acceder al mismo, tendrás que usar la URL correspondiente (junto con sus API keys).</p><p class="slate-p slate-indent-0" style="0px">Por otro lado, para todo lo que es notificaciones hacia el lado del cliente, utilizamos webhooks. También contamos con un servicio de websockets para escuchar algunos eventos como los precios.</p><p class="slate-p slate-indent-0" style="0px">El API utiliza el protocolo <a href="https://en.wikipedia.org/wiki/HTTPS" target="_self">HTTPS</a> para exponer los endpoints. No soporta HTTP.</p><p class="slate-p slate-indent-0" style="0px"></p><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><h3 class="slate-h3 " >Entorno de pruebas (sandbox)</h3><p class="slate-p " >Disponemos de un entorno sandbox para que puedas probar la API sin afectar los flujos productivos. Para acceder, es necesario utilizar la base URL https://sandbox.manteca.dev junto con las API keys entregadas.</p><p class="slate-p " ></p><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><h3 class="slate-h3 " >Notificaciones</h3><p class="slate-p slate-indent-0" style="0px">Como medio para las notificaciones utilizamos webhooks con exponential-backoff; es decir, que seguiremos enviando los avisos hasta que nos respondas con un estado 2xx. Para más información, ir a <a href="67cf0a0efa1385d3a3e90a86/67cf3661227ea3738dc2681c" target="">Webhooks</a>.</p><p class="slate-p slate-indent-0-1" style="NaNpx"></p><p class="slate-p slate-indent-0-1-1-1-1" style="NaNpx"></p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p>

 está diseñada para empresas que buscan agilizar el proceso de pagos de sus usuarios sin incurrir en costos elevados y con la ventaja de realizar una única integración para brindar servicios en múltiples países. A través de nuestro servicio, es posible realizar pagos QR, cumpliendo con las normativas vigentes.

Manteca está organizada alrededor de la interfaz 

. Tiene URLs predecibles orientadas a recursos y usa códigos de respuesta HTTP estándar. Todos los valores de retorno son en formato JSON.

Contamos con un sandbox para que puedas probar el API sin alterar los flujos productivos. Para acceder al mismo, tendrás que usar la URL correspondiente (junto con sus API keys).

Por otro lado, para todo lo que es notificaciones hacia el lado del cliente, utilizamos webhooks. También contamos con un servicio de websockets para escuchar algunos eventos como los precios.

 para exponer los endpoints. No soporta HTTP.

Disponemos de un entorno sandbox para que puedas probar la API sin afectar los flujos productivos. Para acceder, es necesario utilizar la base URL https://sandbox.manteca.dev junto con las API keys entregadas.

Como medio para las notificaciones utilizamos webhooks con exponential-backoff; es decir, que seguiremos enviando los avisos hasta que nos respondas con un estado 2xx. Para más información, ir a 

<p class="slate-p slate-indent-0" style="0px">Manteca utiliza <strong class="slate-bold">API keys</strong> para autenticar los requests. Las mismas son enviadas a través del header md-api-key</p><p class="slate-p slate-indent-0" style="0px">Las credenciales poseen privilegios completos por lo que es imprescindible que sean guardadas de manera segura. La interacción con Manteca debe ser siempre del lado del servidor, especialmente para los llamados autenticados.</p><p class="slate-p slate-indent-0" style="0px">En algunos casos, también proveemos la posibilidad de realizar IP whitelisting o acceder vía una VPN exclusiva para aumentar la seguridad.</p><p class="slate-p slate-indent-0" style="0px">
</p><p class="slate-p " ></p><p class="slate-p " ></p>

 para autenticar los requests. Las mismas son enviadas a través del header md-api-key

Las credenciales poseen privilegios completos por lo que es imprescindible que sean guardadas de manera segura. La interacción con Manteca debe ser siempre del lado del servidor, especialmente para los llamados autenticados.

En algunos casos, también proveemos la posibilidad de realizar IP whitelisting o acceder vía una VPN exclusiva para aumentar la seguridad.

<p class="slate-p slate-indent-0" style="0px">Podés configurar los webhook endpoints a través del API para ser notificado por cada uno de los eventos que ocurran y te sean de interés. Para garantizar la integridad de los datos enviados mediante webhooks, utilizamos un sistema de validación basado en HMAC. Cada webhook se envía con una firma en md-webhook-signature como header que, junto con el secret que tenemos en conjunto, permitirá realizar la verificación de autenticidad de los mensajes. Básicamente, el sigature enviado tiene que ser el mismo que generan de su lado, aplicando HMAC al contenido que llega con el secreto en común.</p><p class="slate-p slate-indent-0" style="0px">Para garantizar que la serialización del JSON sea determinística, es necesario ordenar las claves del objeto de manera alfabética antes de realizar la conversión a string. Esto asegura consistencia en las respuestas y es especialmente útil para firmas criptográficas o validaciones HMAC. En nuestro caso particular, utilizamos la librería fast-json-stable-stringify para hacer la serialización del mismo.</p><p class="slate-p slate-indent-0" style="0px">Los webhooks, tanto en el entorno de desarrollo como en el productivo, llegarán de la IP <a href="https://docs.manteca.dev/cripto/" target="_self">18.229.68.94</a>. La misma se encuentra fija para poder ajustar las políticas de seguridad pertinentes de su lado. Además, tenemos un sistema de reintentos automáticos que operan con exponential backoff; esto significa que se reintentará múltiples veces y cada reintento será después de un intervalo mayor. Realizamos hasta 8 reintentos de cada envío.</p><p class="slate-p " >Además, contamos con un sistema de reintentos automáticos con exponential backoff, lo que significa que:</p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">Si un webhook no se recibe correctamente, el sistema intentará reenviarlo.</div></li><li class="slate-li " ><div style="position:relative">Cada reintento se realizará después de un intervalo de tiempo creciente.</div></li><li class="slate-li " ><div style="position:relative">Se realizarán hasta <strong class="slate-bold">8 intentos</strong> antes de descartar el mensaje.</div></li></ul><p class="slate-p " ></p><p class="slate-p " ></p>

Podés configurar los webhook endpoints a través del API para ser notificado por cada uno de los eventos que ocurran y te sean de interés. Para garantizar la integridad de los datos enviados mediante webhooks, utilizamos un sistema de validación basado en HMAC. Cada webhook se envía con una firma en md-webhook-signature como header que, junto con el secret que tenemos en conjunto, permitirá realizar la verificación de autenticidad de los mensajes. Básicamente, el sigature enviado tiene que ser el mismo que generan de su lado, aplicando HMAC al contenido que llega con el secreto en común.

Para garantizar que la serialización del JSON sea determinística, es necesario ordenar las claves del objeto de manera alfabética antes de realizar la conversión a string. Esto asegura consistencia en las respuestas y es especialmente útil para firmas criptográficas o validaciones HMAC. En nuestro caso particular, utilizamos la librería fast-json-stable-stringify para hacer la serialización del mismo.

Los webhooks, tanto en el entorno de desarrollo como en el productivo, llegarán de la IP 

. La misma se encuentra fija para poder ajustar las políticas de seguridad pertinentes de su lado. Además, tenemos un sistema de reintentos automáticos que operan con exponential backoff; esto significa que se reintentará múltiples veces y cada reintento será después de un intervalo mayor. Realizamos hasta 8 reintentos de cada envío.

Además, contamos con un sistema de reintentos automáticos con exponential backoff, lo que significa que:

Crear webhook

events

md-api-key

secret

active

Obtener configuración

<p class="slate-p " ><span style="background-color:rgb(255, 255, 255);color:rgba(20, 23, 25, 0.84)">Contamos con dos tipos de eventos para notificar a través de webhooks. Cada vez que ocurre un cambio de estado relevante en un proceso, se dispara automáticamente un webhook a la URL configurada.</span></p><p class="slate-p " ></p><p class="slate-p " ></p>

Contamos con dos tipos de eventos para notificar a través de webhooks. Cada vez que ocurre un cambio de estado relevante en un proceso, se dispara automáticamente un webhook a la URL configurada.

Eventos de interés

<p class="slate-p " >El <strong class="slate-bold">Dashboard</strong> es una interfaz centralizada que permite a las empresas monitorear y gestionar los procesos integrados a través de nuestra API. Desde esta plataforma, es posible visualizar el estado de los usuarios, analizar la documentación cargada y monitorear las operaciones en tiempo real.</p><p class="slate-p " >Para acceder, bastaría con dirigirse a:</p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative"><strong class="slate-bold">Entorno productivo</strong>: <a href="https://dashboard.manteca.dev/login" target="_new">https://dashboard.manteca.dev/login</a></div></li><li class="slate-li " ><div style="position:relative"><strong class="slate-bold">Entorno sandbox</strong>: <a href="https://dashboard-qa.manteca.dev/login" target="_new">https://dashboard-qa.manteca.dev/login</a></div></li></ul><p class="slate-p " >El acceso a la plataforma requiere autenticación mediante credenciales de usuario y cuenta con un <strong class="slate-bold">segundo factor de autenticación (2FA)</strong> para garantizar un nivel adicional de seguridad en el ingreso.</p><p class="slate-p " ></p><p class="slate-p " ></p>

 es una interfaz centralizada que permite a las empresas monitorear y gestionar los procesos integrados a través de nuestra API. Desde esta plataforma, es posible visualizar el estado de los usuarios, analizar la documentación cargada y monitorear las operaciones en tiempo real.

El acceso a la plataforma requiere autenticación mediante credenciales de usuario y cuenta con un 

 para garantizar un nivel adicional de seguridad en el ingreso.

<p class="slate-p " >El widget es un sistema embebible diseñado para facilitar integraciones sin necesidad de desarrollo front-end. Este feature permite a las plataformas integrar procesos complejos como KYC, compra y venta de criptomonedas de forma trivial, adaptándose incluso a casos en los que normalmente no se requiere KYC en sus operaciones regulares. </p><p class="slate-p slate-indent-0" style="0px">Además, el sistema cuenta con<strong class="slate-bold"> webhooks configurables</strong> que notifican en tiempo real a la URL definida por la plataforma integradora cada vez que ocurre un evento de interés en el widget. Esto incluye eventos clave como la finalización del KYC.</p><p class="slate-p " >El widget sigue un funcionamiento estándar para todos los casos de uso. Los pasos principales son:</p><p class="slate-p " ></p><div class="steps-widget" style="width:100%;
  	min-width:100%;"><div class="steps-wrapper"><div class="steps-content"><h6 class="slate-h6 " >1</h6><h3 class="slate-h3 " >Generación de url</h3><p class="slate-p slate-indent-0" style="0px">Se realiza un POST a nuestras APIs con configuraciones específicas, para lograr el flujo esperado (onboarding, ramp-on, ramp-off). Entre estas configuraciones, se puede enviar un externalId que permitirá identificar al usuario posteriormente y un sessionId que permitirá conocer el historial de actividades que ocurrieron en una misma corrida.</p><p class="slate-p " ></p></div></div><div class="steps-wrapper"><div class="steps-content"><h6 class="slate-h6 " >2</h6><h3 class="slate-h3 " >Redirección del usuario al widget</h3><p class="slate-p slate-indent-0" style="0px">Una vez tenemos la URL, se redirecciona allî al usuario, donde podrá seguir los pasos presentados de manera interactiva. Es importante destacar que el KYC se hace una única vez por usuario; es decir, si el mismo ya se encuentra registrado, el widget se da cuenta de manera automatica y evitar solicitarlo nuevamente.</p><p class="slate-p " ></p></div></div><div class="steps-wrapper"><div class="steps-content"><h6 class="slate-h6 " >3</h6><h3 class="slate-h3 " >Redirección a la successUrl</h3><p class="slate-p slate-indent-0" style="0px">En cuanto el flujo termina, se redirigirá al usuario a la URL que fue configurada como successUrl; es decir, la url en caso de éxito. Si hubiera un error, el mismo sería informado vía esa URL o bien, se puede configurar para que se utilice una failureUrl.</p><p class="slate-p " ></p></div></div></div><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><p class="slate-p " >Flujo del registro</p><p class="slate-p " >Al acceder a la primera pantalla y completar los datos iniciales, la cuenta del usuario será creada. Luego, el usuario debe completar la información necesaria para verificar sus datos e identidad. Estos son todos los pasos que deberá seguir durante el proceso de creación de su cuenta, hasta que quede validado para operar.</p><div style="text-align:left"><img src="https://theneo-prod-public.s3.us-east-1.amazonaws.com/images-1711058861628.png" style="
              width:935px;
	            height:362px;
	            aspect-ratio:935 / 362"
         /></div><div class="slate-hr"><hr contenteditable="false" class="slate-HrElement-hr"/></div><h3 class="slate-h3 " >Identificadores de usuario
</h3><p class="slate-p slate-indent-0" style="0px">Para identificar al usuario y a la operación de onboarding, contamos con distintos tipos de identificadores:</p><p class="slate-p slate-indent-0" style="0px"><strong class="slate-bold">externalId:</strong> Permite identificar al usuario posteriormente.</p><p class="slate-p slate-indent-0" style="0px"><strong class="slate-bold">sessionId:</strong> Facilita el seguimiento del historial de actividades dentro de una misma sesión.</p><p class="slate-p " ></p>

El widget es un sistema embebible diseñado para facilitar integraciones sin necesidad de desarrollo front-end. Este feature permite a las plataformas integrar procesos complejos como KYC, compra y venta de criptomonedas de forma trivial, adaptándose incluso a casos en los que normalmente no se requiere KYC en sus operaciones regulares. 

 que notifican en tiempo real a la URL definida por la plataforma integradora cada vez que ocurre un evento de interés en el widget. Esto incluye eventos clave como la finalización del KYC.

El widget sigue un funcionamiento estándar para todos los casos de uso. Los pasos principales son:

Al acceder a la primera pantalla y completar los datos iniciales, la cuenta del usuario será creada. Luego, el usuario debe completar la información necesaria para verificar sus datos e identidad. Estos son todos los pasos que deberá seguir durante el proceso de creación de su cuenta, hasta que quede validado para operar.

Para identificar al usuario y a la operación de onboarding, contamos con distintos tipos de identificadores:

 Permite identificar al usuario posteriormente.

 Facilita el seguimiento del historial de actividades dentro de una misma sesión.

<p class="slate-p " >Contamos también con APIs raw; es decir, APIs REST mediante la cuales se puede procesar las altas de los usuarios. </p><p class="slate-p slate-indent-0" style="0px">El alta de usuario por esta vía consta de dos pasos principales. Los dos pasos son <strong class="slate-bold">obligatorios</strong> para considerar a un usuario como dado de alta correctamente y que el mismo pueda realizar pagos.</p><ol class="slate-ol " ><li class="slate-li " ><div style="position:relative">Crear un usuario: se debe realizar el alta usando el POST de <a href="67d870fdade5b2611e79dda4/67d870fdade5b2611e79dda8/67d870fdade5b2611e79dd49" target="">crear usuario</a>.</div></li><li class="slate-li " ><div style="position:relative">Subir documentación: la subida de documentación consta de dos pasos. Primero, se realiza la generación del link de <a href="67d870fdade5b2611e79dda4/67d870fdade5b2611e79dda8/67d870fdade5b2611e79dd8b" target="">suba de documentación</a>. Una vez obtenida se debe subir a esa URL mediante PUT<span style="color:rgb(75, 133, 232)"> </span>la imagen correspondiente como un <strong class="slate-bold">binario</strong>. Es necesario subirle tanto <code class="slate-code">DNI_FRONT</code> (frente del documento de identidad) como <code class="slate-code">DNI_BACK</code> (dorso del documento de identidad) a un usuario.</div></li></ol><p class="slate-p " ><span style="color:rgb(93, 103, 119)">
</span></p><p class="slate-p " ></p>

Contamos también con APIs raw; es decir, APIs REST mediante la cuales se puede procesar las altas de los usuarios. 

El alta de usuario por esta vía consta de dos pasos principales. Los dos pasos son 

 para considerar a un usuario como dado de alta correctamente y que el mismo pueda realizar pagos.

<p class="slate-p " >Los sintéticos funcionan como una capa de abstracción que permite agrupar múltiples operaciones en una sola. <span style="color:#000000">Básicamente, son una cadena de operaciones unificadas en una entidad.</span></p><p class="slate-p " ><span style="color:#000000">Para poder relacionar todas las operaciones que ocurren dentro de un sintético, se usa el </span><span style="color:#000000"><code class="slate-code">sessionId</code></span><span style="color:#000000"> que no es mas que un identificador opcional que puede enviarse como parte del request y el mismo estará en todas las entidades participantes (depósito, órden, retiro y webhook).</span></p><p class="slate-p " ><span style="color:#000000">Actualmente, un </span><span style="color:#000000"><strong class="slate-bold">pago QR</strong></span><span style="color:#000000"> se compone de tres pasos internamente:</span></p><ol class="slate-ol " ><li class="slate-li " ><div style="position:relative"><span style="color:#000000"><strong class="slate-bold">Depósito:</strong></span><span style="color:#000000"> se pueden configurar los pagos para que salgan una vez se realiza un depósito en una dirección particular. También, se puede configurar al sistema para que opere en descubierto, permitiendo que este paso sea omitido y siempre se genere deuda a favor de Manteca.  </span></div></li><li class="slate-li " ><div style="position:relative"><strong class="slate-bold">Ó</strong><span style="color:#000000"><strong class="slate-bold">rden:</strong></span><span style="color:#000000"> gestiona la operación de venta de la moneda origen a la moneda destino del pago. Esto significa que, si por ejemplo se realiza un pago PIX en reales (BRL) y las liquidaciones son en pesos argentinos (ARS), veremos como en cada sintético, tendremos una operación ARS → BRL. Los ARS de origen se sumaran a la deuda de la entidad con Manteca y los BRL son los que se usarán para hacer el pago per sé.</span></div></li><li class="slate-li " ><div style="position:relative"><span style="color:#000000"><strong class="slate-bold">Pago</strong></span><span style="color:#000000">: gestiona todo lo necesario para realizar un pago QR.</span></div></li></ol><p class="slate-p " ></p>

Los sintéticos funcionan como una capa de abstracción que permite agrupar múltiples operaciones en una sola. 

Básicamente, son una cadena de operaciones unificadas en una entidad.

Para poder relacionar todas las operaciones que ocurren dentro de un sintético, se usa el 

 que no es mas que un identificador opcional que puede enviarse como parte del request y el mismo estará en todas las entidades participantes (depósito, órden, retiro y webhook).

Sections