Integración API Rappi
1. INTRODUCCIÓN
1.1 Propósito del Documento
Este documento describe los flujos técnicos de integración de Retailers con la plataforma Rappi, incluyendo
gestión de catálogo, tiendas, inventario y pagos. Define los endpoints necesarios, los parámetros esperados,
las respuestas y el flujo secuencial de operaciones.
1.2 Alcance
- Gestión de productos y catálogo
- Creación y actualización de tiendas
- Control de inventario (stock, precio, descuentos)
- Integración con Rappi Payless para autorizaciones de pago, cancelaciones y reembolsos
1.3 Consideraciones Técnicas Generales
• Protocolo: HTTPS TLS 1.2+
• Autenticación: JWT (JSON Web Tokens)
• Validez del Token: 12 horas
• Formato de fechas: ISO 8601 (GMT 0)
• Timeout recomendado: 20 segundos
• Reintentos automáticos: Hasta 5 intentos dentro del TTL del barcode
2. FLUJOS DE INTEGRACIÓN
2.1 Gestión de Catálogo
Objetivo: Permitir la creación, actualización, consulta y estructuración de productos dentro de Rappi.
Esto incluye la definición de categorías, atributos de producto y variaciones.
Componentes clave:
• Categorías y Subcategorías: Jerarquía de categorías que simula la experiencia de navegación
en tienda.
• Atributos de Producto: Características físicas y no físicas que definen la identidad de un
producto (ej. Marca, Modelo, Tamaño, EAN).
Consideraciones técnicas:
• Cada producto debe asociarse a la categoría más granular disponible (nivel más bajo).
• Los atributos obligatorios dependen de la categoría y del tipo de producto.
2.2 Gestión de Tiendas
Objetivo: Registrar y gestionar tiendas físicas y virtuales del retailer, asegurando que los productos se
asocien correctamente con la disponibilidad de cada ubicación.
Conceptos clave:
• Tienda Física: Representa la ubicación real del retailer.
• Tienda Virtual: Una versión digital de la tienda física en Rappi. Cada tienda virtual refleja la
tienda física, pero puede mostrar solo un subconjunto de productos según la categoría o tipo de
producto
Consideraciones técnicas:
• Los IDs de las tiendas (tanto físicas como virtuales) son obligatorios para asociar inventario y
procesar pedidos.
• Cada tienda puede tener productos exclusivos según vertical o disponibilidad.
2.3 Gestión de Inventario
Objetivo: Permitir la actualización y control del stock, precios y descuentos de productos por tienda,
garantizando la disponibilidad y precisión de la información mostrada a los usuarios.
Operaciones principales:
• Publicación de productos en tienda: Asociar un producto a una tienda específica.
• Actualización de inventario: Modificar stock, precio y precio con descuento.
• Eliminar producto de tienda: Retirar un producto de la oferta activa de una tienda.
Consideraciones técnicas:
• Stock > 0: Producto disponible para compra.
• Stock = 0: Producto temporalmente no disponible.
• La actualización debe reflejar cambios en tiempo real desde ERP o POS del retailer.
2.4 Integración de Pagos – Rappi Payless
Objetivo: Gestionar la autorización, validación, cancelación y reembolso de pagos realizados mediante
Rappi Payless, asegurando trazabilidad y consistencia con las ventas en POS.
Componentes clave:
• Autenticación: Generación de JWT para todas las solicitudes de pago.
• Autorización de pago: Solicitud de autorización usando el código de pago (barcode) generado
por el recolector (RT/Shopper).
• Validación de transacción: Consulta del estado de una orden cuando se requiere verificación
posterior.
• Cancelación y reembolso: Procesos de reversión o devolución de pagos dentro de los límites
definidos (mismo día calendario, reembolsos completos).
Consideraciones técnicas:
• Los códigos de pago (barcode) tienen un TTL de 10 minutos y deben generarse de manera única
por sesión.
• Todos los parámetros de la transacción (basket, store_id, terminal_id, terminal_transaction_id)
deben ser consistentes entre autorización, cancelación y reembolso.
3. GESTIÓN DE TIENDAS
3.1 Descripción
Garantizar que todas las tiendas físicas del comercio estén correctamente registradas en la plataforma Rappi
y que cada una de ellas tenga una representación adecuada dentro de la aplicación, permitiendo que los
usuarios visualicen el catálogo disponible según su ubicación.
La correcta gestión de tiendas es fundamental, ya que todas las operaciones posteriores: productos,
inventario, precios y pagos se realizan siempre a nivel de tienda.
3.2 Concepto de Tienda en Rappi
Una tienda en Rappi representa una ubicación física específica desde la cual se despachan pedidos a los
usuarios.
Cada tienda cuenta con:
• Un identificador único (store_id)
• Una dirección física
• Coordenadas geográficas
• Un estado de publicación
Este identificador es el elemento clave que se utiliza en toda la integración técnica.
3.3 Obtención de Tiendas
Para conocer las tiendas disponibles, se debe consultar el siguiente endpoint:
GET /api/open-api/v1/catalog/stores
Authorization: Bearer {token}
Este servicio retorna el listado de tiendas asociadas al comercio que están habilitadas
para operar.
Información relevante de la respuesta
De cada tienda, se debe almacenar:
• id: Identificador de la tienda (store_id)
• name: Nombre de referencia de la tienda
• address: Dirección física
• status: Estado de disponibilidad
3.4 Uso del Identificador de Tienda
El store_id obtenido debe utilizarse obligatoriamente para:
• Asociar productos a una tienda
• Informar stock y precios
• Aplicar descuentos
• Procesar autorizaciones de pago
Cada tienda se gestiona de manera independiente.
3.5 Consideraciones Importantes
• Las tiendas no se crean ni se modifican mediante la integración técnica.
• El listado de tiendas es proporcionado por Rappi y debe ser consultado vía API.
• Solo las tiendas con estado published deben utilizarse para operaciones.
• Si una tienda no aparece o presenta inconsistencias, debe revisarse por los
canales de soporte correspondientes.
• El comercio es responsable de mantener la correcta relación entre sus tiendas
internas y los store_id de Rappi.
3.6 Paginación del Listado de Tiendas
Cuando el comercio cuenta con un número elevado de tiendas, el endpoint de obtención
de tiendas utiliza un mecanismo de paginación para optimizar la respuesta.
Para ello, se pueden utilizar los parámetros opcionales:
• limit: número máximo de tiendas a retornar por solicitud
• offset: posición desde la cual iniciar la consulta
Ejemplo de solicitud paginada
[Link]
Authorization: Bearer {token}
4 Géstion de Catálogo y Productos
4.1 Objetivo
Permitir que los productos del comercio estén correctamente registrados en Rappi, con información
estandarizada, imágenes, atributos y estructura adecuada para su visualización en la aplicación.
Esta etapa es obligatoria antes de configurar inventario (precio y stock) y es independiente de las tiendas.
4.2 Modelo de Productos en Rappi
Rappi maneja el catálogo a través de distintos niveles lógicos de producto:
• Producto Maestro
Catálogo de referencia global administrado por Rappi.
Se utiliza para curaduría, estandarización y agrupación de productos similares.
• Producto del Comercio
Representa un producto propio del comercio dentro de Rappi.
Cada producto tiene un identificador único generado por Rappi y se relaciona con el SKU
interno del comercio.
• Producto por Tienda
Es la asociación del producto del comercio con una tienda específica, incluyendo:
- Precio
- Precio con descuento
- Stock disponible
4.3 Requisitos Previos
Antes de crear un producto es necesario contar con:
• Identificador de categoría válido (category_id)
• SKU interno del producto
• Código EAN válido
• Imágenes públicas y accesibles vía HTTPS
• Definición del tipo de venta (unidad o pesable)
• Definición de atributos según la categoría
4.4 Creación de Productos (Producto del Comercio)
La creación de productos se realiza mediante el siguiente endpoint:
Endpoint
POST /api/open-api/v1/catalog/products
Este endpoint permite crear:
• Productos unitarios
• Productos con variaciones (color, talla, capacidad, etc.)
Consideraciones Clave
• Cada SKU enviado genera un product_id único en Rappi
• Este product_id debe ser almacenado, ya que será requerido posteriormente para
inventario
• En productos con variaciones:
o Cada variación tiene su propio id
o Todas comparten un parent_id común
4.5 Productos con Variaciones
Las variaciones permiten agrupar múltiples versiones del mismo producto bajo una sola
visualización en la app.
Ejemplos comunes:
• Colores
• Tallas
• Capacidades
• Memoria interna
Reglas importantes:
• Las variaciones se crean al mismo tiempo que el producto
• No es posible agregar nuevas variaciones a un producto ya creado
• Los atributos que generan variaciones dependen de la categoría
4.6 Código EAN
El código EAN se utiliza para:
• Validación del producto
• Asociación con productos maestros
• Mejora de búsqueda y visibilidad en la app
Reglas:
• Longitudes permitidas: 8, 12, 13 o 14 dígitos
• EAN de 12 dígitos debe completarse con un 0 al inicio
4.7 Recuperación de Productos
Para consultar los productos creados en Rappi:
Listado general
GET /api/open-api/v1/catalog/products
Búsqueda por SKU
GET /api/open-api/v1/catalog/products/sku?skus=SKU1,SKU2
Notas:
• Máximo 200 SKUs por solicitud
• La respuesta es un resumen del producto
• El detalle completo se obtiene desde el endpoint principal de productos
4.8 Almacenamiento de Identificadores
Es importante mapear y almacenar la relación entre el id y el código interno sku del
minorista, para que luego, cuando se adminsitre el inventario de ese producto en Rappi,
sepas qué id pasar
Esta relación es crítica para:
• Gestión de inventario
• Autorización de pagos
• Conciliación de ventas
5. Gestión de Inventario por Tienda
5.1 Objetivo
Asociar los productos previamente creados en Rappi con cada tienda física, definiendo
su información comercial y operativa, específicamente:
• Precio de venta
• Precio con descuento (si aplica)
• Stock disponible
Solo los productos que tengan stock mayor a cero y estén correctamente asociados a una
tienda serán visibles y comprables por los usuarios en la aplicación.
5.2 Precondiciones
Antes de ejecutar este flujo, se debe contar con:
• Token de autenticación vigente
• Identificador de la tienda (store_id), obtenido desde el endpoint de consulta de tiendas
• Identificador del producto (product_id), obtenido al crear el producto y almacenado
internamente junto al SKU
5.3 Publicación de Producto en Tienda (Alta de Inventario)
Este paso crea la relación entre un producto y una tienda específica, permitiendo su
venta en Rappi.
Endpoint
POST /api/open-api/v1/catalog/stores/{store_id}/inventory
Request Body
{
"id": 2147484292,
"price": 1335,
"sale_price": 1070,
"stock": 10
}
Descripción de Campos
Campo Descripción
id Identificador del producto en Rappi (product_id)
price Precio regular del producto
sale_price Precio con descuento (opcional)
stock Cantidad disponible para la venta
5.4 Comportamiento del Sistema
• Productos con stock > 0 estarán disponibles en la aplicación.
• Productos con stock = 0 no serán visibles para los usuarios.
• Si se envía sale_price menor a price, el producto se mostrará con descuento.
• La asociación se replica automáticamente en las tiendas virtuales correspondientes.
5.5 Actualización de Inventario
Este endpoint se utiliza para mantener sincronizado el inventario con el sistema del
comercio.
Endpoint
PUT /api/open-api/v1/catalog/stores/{store_id}/inventory/{product_id}
Request Body
{
"price": 1400,
"sale_price": 1000,
"stock": 5
}
Se debe ejecutar este endpoint cuando exista:
• Venta de un producto
• Cambio de precio
• Aplicación o eliminación de descuentos
• Ajustes manuales de stock
5.6 Eliminación de Producto de una Tienda
Permite eliminar definitivamente un producto de una tienda específica.
Endpoint
DELETE /api/open-api/v1/catalog/stores/{store_id}/inventory/{product_id}
Consideración Importante
Una vez eliminado, el producto no puede volver a asociarse a esa tienda.
Este endpoint debe utilizarse únicamente cuando el producto deja de venderse de forma permanente en
esa ubicación.
5.7 Frecuencia de Actualización Recomendada
Para garantizar una correcta experiencia de compra y evitar inconsistencias:
• Stock: actualización inmediata tras cada venta
• Precios y descuentos: actualización cada vez que cambien en el sistema del comercio
5.8 Tipos de Actualización de Inventario
La plataforma permite dos modalidades de sincronización de inventario por tienda: actualización
incremental (Delta) y carga completa (Full). El comportamiento de cada una depende del contenido de
la solicitud y del uso del campo type.
5.8.1 Actualización Incremental (Delta)
Descripción
Las actualizaciones Delta deben incluir únicamente los productos cuyo inventario haya cambiado
desde la última sincronización.
Comportamiento
• Los productos no incluidos en la solicitud conservan su estado actual (stock, precio y
disponibilidad).
• No se afectan productos sin cambios.
• Es la modalidad recomendada para operación diaria.
Requisito
La solicitud DEBE incluir el siguiente campo:
{
"type": "delta"
}
Casos de uso
• Venta de un producto
• Ajuste puntual de stock
• Cambio de precio individual
• Activación o desactivación de descuentos
5.8.2 Carga Completa de Inventario (Full / Lleno)
Descripción
Las cargas completas deben incluir todo el catálogo disponible de la tienda en la solicitud.
Comportamiento
• Cualquier producto no incluido en la solicitud será marcado como no disponible.
• Los productos enviados con stock 0 también se marcarán como no disponibles.
• Permite reconciliar el estado total del inventario de la tienda.
Requisito
• NO es necesario enviar el campo type.
• La ausencia del campo type indica automáticamente una carga completa.
Casos de uso
• Inicialización de la tienda
• Reconciliación programada
• Corrección de inconsistencias
• Recuperación ante fallos operativos
5.8.3 Recomendaciones Operativas
• Utilizar Delta para actualizaciones frecuentes y en tiempo real.
• Reservar Full para procesos controlados (inicio de operación o reconciliaciones).
• No ejecutar cargas completas de forma constante para evitar inconsistencias y consumo
innecesario de recursos.
6. Gestión Api Payless
6.1 Flujo General del proceso
1. Creación del pedido.
El cliente realiza un nuevo pedido a través de la plataforma Rappi.
Dependiendo de la configuración del comercio, el pedido es asignado a un
recolector (picker) o mensajero (RT).
2. Recogida de productos
El recolector recoge los productos del pedido y marca cada ítem como:
• Encontrado
• No encontrado
• Reemplazado
El recolector no puede proceder al pago mientras existan productos pendientes en
la lista.
3. Ingreso a modo de pago.
Una vez completada la recogida, la aplicación del recolector entra en modo de
pago y genera un código de pago Rappi Payless.
4. Generación del código de pago.
El código de pago (QR o código de barras) se genera con una vigencia limitada
de 10 minutos.
El código se renueva automáticamente una vez expirado.
5. Escaneo de productos en el POS.
El cajero escanea los productos en el POS de forma habitual y registra la venta.
6. Escaneo del código de pago
El cajero escanea el código de pago desde el dispositivo del recolector (QR,
código de barras o ingreso manual).
El POS captura y almacena temporalmente este código, el cual será utilizado
posteriormente como parámetro obligatorio en la autorización del pago.
Si el código fue escaneado previamente, debe escanearse nuevamente, ya que
puede haber expirado.
7. Autorización del pago
El POS envía los detalles de la compra al endpoint de autorización de Rappi
Payless.
Si la operación es exitosa, Rappi responde con la autorización del pago y los
identificadores de la transacción.
8. Finalización del proceso
El recolector registra el comprobante de pago y el pedido queda listo para ser
entregado.
6.2. ENDPOINTS
6.2.1 Autenticación
POST /cpgops-integrations/retailers/sign-in
Descripción: Genera un token JWT necesario para autenticar todas las solicitudes
subsiguientes a la API de Rappi Payless.
URL Base:
• Desarrollo: [Link]
• Producción [Link]
"retailer": "nombre-retailer",
"secret": "clave-secreta-proporcionada"
Parámetros:
Campo Tipo Requerido Descripción
retailer string Sí Nombre de usuario único proporcionado por Rappi
secret string Sí Clave secreta proporcionada por Rappi
Response Exitoso (200):
"accessToken": "asdassc",
"expiresIn": 43200
}
Campos de Respuesta:
Campo Tipo Descripción
accessToken string Token JWT para autenticación
expiresIn number Tiempo en segundos antes de expiración (43200 = 12 horas)
6.2.2 Escaneo de código de barras
Proceso Manual (No requiere endpoint)
El código de barras presentado por el RT/Shopper en su aplicación móvil es capturado
por el POS mediante un escáner físico. Este código es un identificador alfanumérico que
se utilizará posteriormente en la solicitud de autorización.
Características del Código:
• Formato: CODE-128
• Longitud: 6 a 13 dígitos (configurable por partner)
• Time-To-Live (TTL): 10 minutos
• Renovación: Automática cada 10 minutos en la app del RT/Shopper
Tipos de Presentación
1. Código de barras lineal (CODE-128)
2. Código QR
3. Entrada manual
Proceso:
1. RT/Shopper genera código en su app Rappi
2. Cajero escanea código con escáner del POS
3. POS almacena código temporalmente en memoria
4. Código se utiliza como parámetro {barcode} en endpoints subsiguientes
IMPORTANTE:
• El código NO contiene información de la orden
• Es únicamente un identificador de sesión
• NO se debe consultar ningún endpoint al escanear el código
• Si el código expira (10 minutos), solicitar al RT que genere uno nuevo
• El código puede escanearse múltiples veces si es necesario (ejemplo: reintentos)
6.2.3 Autorización de pago
POST : /cpgops-integrations/pos/v3/payments/{barcode}/authorize
Descripción: Solicita la autorización de pago a Rappi para una transacción específica.
Este es el endpoint principal del flujo de venta.
Parámetros de Ruta:
Parámetro Tipo Descripción
{barcode} string Código escaneado del RT/Shopper
Parámetros del Body:
Campo Tipo Requerido Descripción
currency string Sí Código de moneda (USD, COP,
etc.)
amount number Sí Monto total en centavos/mínima
denominación
basket array Sí Array de productos escaneados
basket[].sku string Sí SKU del producto (mismo que
integración inventario)
basket[].quantity number Sí Cantidad: unidades o kg para
pesables
basket[].unit_type string Sí UN (unidad), WW (pesable
suelto), WB (pesable empacado)
basket[].unit_price number Sí Precio unitario en centavos
basket[].taxes array Sí Array de impuestos aplicados
basket[].taxes[].tax_code string Sí Código del impuesto (IVA, etc.)
basket[].taxes[].tax_amount number Sí Monto del impuesto en centavos
store_id string Sí ID de tienda (mismo que
integración inventario)
terminal_id string Sí Identificador único de la
caja/terminal
terminal_transaction_id string Sí ID único de transacción (número
factura/pre-orden)
total_discount number Sí Descuentos totales aplicados en
centavos
total_taxes number Sí Impuestos totales en centavos
metadata object No Información adicional relevante
para el partner
Campos Críticos de la Respuesta:
Campo Tipo Descripción ¿Almacenar?
status string Estado de la autorización Sí
authorization_code string Código único de autorización SÍ -
OBLIGATORIO
order_id string Id de la orden SÍ -
OBLIGATORIO
payment_code string Barcode utilizado SÍ -
OBLIGATORIO
amount number Monto autorizado SÍ -
OBLIGATORIO
created_at string Fecha/hora creación (GMT 0) SÍ -
OBLIGATORIO
updated_at string Fecha/hora actualización SÍ -
(GMT 0) OBLIGATORIO
Consideraciones de Implementación:
1. Timeout y Reintentos
2. Validación de Basket:
• Agrupar productos idénticos
• Verificar que SKU coincida con integración de inventario
• Para productos pesables, cantidad debe estar en kilogramos
• Calcular correctamente impuestos por producto
3. Generación de terminal_transaction_id:
• Debe ser único por transacción
• Recomendado: Número de factura o código de pre-orden
• No reutilizar en caso de reintentos
4. Almacenamiento de Datos
6.2.4 Validación de Estado de Pago
GET : /cpgops-integrations/pos/v3/payments/orders/{order_id}/status
Descripción: Consulta el estado actual de una transacción cuando no se recibió respuesta
del endpoint de autorización o para verificar el estado de una orden.
Parámetros de Ruta:
Parámetro Tipo Descripción
{order_id} string ID de la orden Rappi
Cuando Usar Este Endpoint:
1. Timeout en autorización: No se recibió respuesta del POST /authorize
2. Validación post-reintento: Después de múltiples reintentos fallidos
3. Verificación preventiva: Antes de ejecutar cancelación
RESTRICCIONES:
• Solo funciona DESPUÉS de haber intentado autorización
• Retorna error 404 si la orden no tiene autorización previa
• No usar como método principal de autorización
6.2.5 Cancelación de Autorización
POST: /cpgops-integrations/pos/v3/payments/{barcode}/cancel
Descripción: Revierte una autorización de pago previamente aprobada mediante Rappi
Payless. Este endpoint se utiliza cuando la transacción fue autorizada por Rappi, pero no
se completó la venta en el POS o se requiere anular la operación antes de cerrar la venta.
Parámetros de Ruta:
Parámetro Tipo Descripción
{barcode} string Mismo código usado en la autorización original
Reglas del Body
El cuerpo del JSON debe ser idéntico al enviado en la solicitud de autorización.
Debe incluir:
• basket
• store_id
• terminal_id
• terminal_transaction_id
• metadata (si fue enviado)
Restricciones Temporales
• La cancelación solo puede realizarse el mismo día calendario de la autorización.
• Límite horario: hasta las 23:59:59 (GMT 0).
• Después de este horario, la autorización no puede ser cancelada.
Consideraciones Importantes
• La cancelación NO es un reembolso.
• No existe devolución de dinero, ya que el pago no se consolida.
• El order_id generado en la autorización debe ser almacenado por el POS para
trazabilidad.
• Este endpoint solo debe utilizarse cuando la venta no fue completada.
6.2.6 Reembolso de Pago
POST: /cpgops-integrations/pos/v3/payments/{barcode}/refund
Descripción: Permite realizar únicamente el reembolso completo de un pago previamente
autorizado y completado mediante Rappi Payless. Este endpoint se utiliza cuando la venta
ya fue cerrada en el POS y el pedido fue cancelado, quedando los productos en posesión
del repartidor (RT).
Prerrequisitos
• La transacción debe haber sido autorizada exitosamente mediante el endpoint
/authorize.
• El pedido debe encontrarse en estado CANCELLED.
• El barcode debe corresponder a la transacción original.
• El POS debe haber almacenado el order_id generado en la autorización.
Parámetros de Ruta
Parámetro Tipo Descripción
{barcode} string Código utilizado en la autorización original
Reglas del Body
• El cuerpo del JSON debe ser idéntico al enviado en la autorización.
• En reembolsos completos, la cesta (basket) debe enviarse vacía: [].
• store_id, terminal_id y terminal_transaction_id deben coincidir con los usados en
la autorización
Restricciones Temporales
• El reembolso solo puede realizarse el mismo día calendario de la autorización.
• Límite horario: hasta las 23:59:59 (GMT 0).
• Después de este horario, no es posible realizar el reembolso.
Importante: La API de Rappi Payless POS no soporta reembolsos parciales ni diferidos;
únicamente se permiten reembolsos completos el mismo día de la autorización.
7. Gestión de Conciliación de Pagos
La Gestión de Conciliación de Pagos tiene como objetivo permitir al retailer validar, auditar y
reconciliar las transacciones realizadas mediante Rappi Payless, comparando la información operativa
registrada por el POS con los reportes oficiales de liquidación entregados por Rappi.
Este módulo no participa en la autorización del pago en tiempo real, sino que opera posterior al proceso
de pago, con fines financieros y de reportería.
7.1 Alcance
La conciliación de pagos cubre:
• Consulta de transacciones aprobadas mediante Payless.
• Almacenamiento de información clave por transacción.
• Soporte para conciliaciones diarias, semanales o por rango de fechas.
• Validación contra el reporte oficial de conciliación de Rappi.
7.2 Fuentes de Información para Conciliación
Existen dos mecanismos complementarios para obtener la información necesaria:
a) Consulta por listado de pagos (Payment List)
Se realiza mediante el endpoint:
GET /pos/v3/payments
Características principales:
• Retorna pagos aprobados mediante Payless.
• Incluye hasta 500 transacciones por solicitud.
• La información se encuentra disponible en modalidad T+1 (los pagos del día actual se consultan
al día siguiente).
• Permite filtrar por rango de fechas (start_date, end_date).
• Se utiliza principalmente para procesos batch (diarios o semanales).
Este endpoint es de carácter informativo y no reemplaza el reporte oficial de conciliación.
b) Consulta por orden individual (Order Details)
Se realiza mediante el endpoint:
GET /pos/v3/payments/{barcode}/order
Características principales:
• Se ejecuta por cada orden, previo a la autorización del pago.
• Permite obtener información detallada del pedido, incluyendo:
o order_id
o store_id
o Monto total
o Productos
• La información obtenida debe ser almacenada inmediatamente por el partner.
Este mecanismo permite contar con trazabilidad en tiempo real de cada transacción.
7.3 Información Obligatoria a Almacenar
Para garantizar una conciliación correcta, el partner debe almacenar, como mínimo, los siguientes campos
por transacción:
• order_id: Identificador único de la orden en Rappi.
• store_id: Identificador de la tienda/sucursal en Rappi.
• amount: Monto total autorizado.
• barcode: Código utilizado para la autorización del pago.
• authorization_code: Código único de autorización.
• status: Estado de la transacción (payment_authorization_request_succeeded).
• created_at y updated_at: Fechas en zona horaria GMT 0.
Esta información debe conservarse independientemente del método utilizado para la conciliación.
7.4 Consideraciones Operativas
• El proceso de conciliación no bloquea ni afecta la operación del POS.
• Se recomienda ejecutar los procesos batch fuera de horarios críticos.
• La conciliación es un requisito clave para áreas de finanzas, auditoría y control interno.
8 Plan de implementación
Tarea Estimación (horas)
Configuración Inicial
Creación del proyecto base (framework, estructura, estándares) 6
Configuración de base de datos y perfiles (dev, test, prod) 6
Configuración de autenticación JWT y manejo de tokens 10
Configuración de logging y auditoría básica 6
API Gestión de Tiendas
Consulta y almacenamiento de tiendas disponibles 8
Validación de consistencia de tiendas y estado publicado 6
Implementación de paginación en listados de tiendas 4
API Gestión de Catálogo y Productos
Creación de productos del comercio con validación de atributos 10
Manejo de productos con variaciones 8
Validación de categorías y asociación correcta con productos 6
Recuperación de productos y mapeo con SKU interno 6
API Gestión de Inventario por Tienda
Publicación de productos en tienda (alta de inventario) 8
Actualización de inventario (delta y full) 10
Eliminación de productos de tienda 6
Validaciones de stock, precios y descuentos 6
API Integración de Pagos – Rappi Payless
Autenticación y manejo de tokens para pagos 8
Escaneo y almacenamiento temporal de códigos de pago 6
Autorización de pagos con validación de información 16
Validación del estado de pagos 8
Cancelación de pagos 10
Reembolso de pagos 10
API Gestión de Conciliación de Pagos
Consulta y almacenamiento de listado de pagos 10
Consulta y almacenamiento de información de orden individual 10
Validaciones y conciliación de transacciones 8
Procesos batch de conciliación 8
Pruebas y Validaciones
Pruebas unitarias de servicios de catálogo, inventario y pagos 10
Pruebas de integración de API de pagos 12
Pruebas funcionales del flujo completo 14
Despliegue y Documentación
Preparación de entornos y documentación técnica 10