Customers

INGALCA Pay maneja una capa de customers delgada y deliberadamente no-CRM. Sirve para:

1. Evitar colisiones cross-tenant en los sandboxes compartidos de los proveedores.
2. Tener una vista por cliente en el dashboard (cards, pagos asociados, último contacto).
3. Filtrar pagos y webhooks por cliente.

No reemplaza tu CRM — los datos canónicos de tus clientes viven en tu app.

Capa fina, no fuente de verdad

Cada pago lleva un snapshot inmutable de los datos del cliente al momento del cobro. La fila customer en sí solo persiste el último valor visto en cualquier interacción. Si el cliente cambia su nombre, el pago viejo sigue mostrando el nombre que tenía cuando se creó.

Cómo se identifica un customer

ID	Quién lo conoce	Para qué
external_id	Vos	Tu identificador del cliente en tu app (ej. user_42). String libre.
public_id	INGALCA Pay y proveedores	cust_xxxxxxxx. Nuestro ID interno; lo mandamos a Dinelco/Bancard.
id numérico	Solo nuestro DB	No expuesto.

Cuando pasás customer.customerId al crear un pago o tarjeta, ese es tu external_id. Nosotros resolvemos el public_id correspondiente y se lo mandamos al proveedor.

Auto-create

No hay endpoint para crear customers explícitamente. Se crean automáticamente cuando:

1. Hacés POST /v1/payments con customer.customerId.
2. Hacés POST /v1/cards con customer.customerId.

La primera vez que mandás un external_id nuevo, se crea el customer. Las veces siguientes, se reutiliza y se actualizan los campos last_seen_* (último nombre, email, teléfono que mandaste).

Scoping por entorno

El UNIQUE es (tenant_id, environment, external_id). Esto significa:

• Podés tener user_42 en test y user_42 en live como customers distintos.
• Otros tenants pueden usar user_42 sin colisionar con vos.

Endpoints

GET  /v1/customers                 — listar (cursor pagination, filtro por external_id)
GET  /v1/customers/{public_id}     — detalle

NO hay POST ni PATCH ni DELETE. Los customers son read-only desde la API; los datos se mantienen actualizados automáticamente al crear pagos/cards.

Por qué mandamos public_id a los proveedores

Imaginá: dos comercios distintos del gateway, ambos con un cliente identificado como user_1 en sus respectivos sistemas. Si le mandáramos a Dinelco directamente user_1 como customerId, ambos comercios estarían pisándose en el mismo namespace de Dinelco. Dinelco vería un solo “cliente” con dos historiales mezclados.

Mandando cust_xxxxxxxx (único globalmente), cada cliente de cada comercio tiene su identidad limpia en Dinelco, sin importar qué external_id use el comercio.

Dashboard

En el dashboard tenés:

• Sección /customers con listado y búsqueda.
• Drawer del customer con tabs Pagos y Cards asociados.
• Filtro por customer en /payments, /webhooks y /cards.

El customer aparece con un hint persistente recordando que es capa referencial, no CRM.