Integrá un POS físico

Dos modelos de integración

Un POS propio del retailer y Qualth POS resuelven necesidades distintas y no comparten el mismo modelo de autenticación. Elegí el patrón según quién controla la experiencia y el backend.

Patrón A — POS propio del retailer

POS / checkout UI
      ↓ HTTPS
Retailer backend / BFF
      ↓ X-API-Key
Qualth Integration API
      ↓
customer → purchase → state

El dispositivo habla con tu backend. Ese backend conserva la X-API-Key y ejecuta el mismo recorrido público que cualquier otro canal: buscar o crear el customer, registrar la purchase y leer su estado.

• Search y state requieren customers.read.
• Create requiere customers.write.
• Purchase requiere purchases.write y Idempotency-Key.
• La API key nunca llega al dispositivo POS.

Patrón B — Qualth POS

Operador
   ↓
Qualth POS
   ↓
POS operator boundary

Qualth POS es una superficie de operador con su propio BFF y autenticación. Sus operaciones no se convierten en Integration API y sus credenciales no deben reutilizarse para llamadas server-to-server del retailer.

Cómo elegir

• Usá el patrón A cuando el retailer controla el POS y puede integrar su backend.
• Usá Qualth POS cuando la operación se realiza en la superficie de operador de Qualth.
• Podés evolucionar desde operación asistida hacia integración server-to-server sin mezclar ambos modelos en una misma llamada.

Antes de producción

Para un POS propio, aplicá las mismas reglas de seguridad, idempotencia y reconciliación del resto de la Integration API.