#

Conciliación

El campo conciliationType define cómo ChytaPay sabe qué pago corresponde a qué cobro: por el CVU al que se transfirió, o por el CUIL del pagador.

#

Los dos modos

cvu (default)

El pagador transfiere al CVU del cobro y se concilia por esa transferencia entrante. Funciona cuando cada cobro tiene su propio CVU.

cuil

Se concilia por el CUIL/DNI del pagador. En este modo customer.taxDocument es obligatorio (CUIL de 11 dígitos o DNI de 7-8). Si enviás un DNI, el sistema genera automáticamente los candidatos CUIL posibles y registra los válidos; la respuesta devuelve el taxDocument tal cual lo mandaste.

Ver ejemplo: modo CUIL
curl
curl -X POST {{integration-url}}/payment-request \
  -H "Authorization: Bearer {user_id_token}" \
  -d '{
    "referenceId": "factura-cuil-001",
    "amount": 5000,
    "description": "Cuota con conciliación por CUIL",
    "dueDates": ["2026-02-15"],
    "conciliationType": "cuil",
    "sendWhatsappNotification": false,
    "sendEmailNotification": false,
    "customer": { "name": "María García", "taxDocument": "27304050604" }
  }'
#

Cuándo usar cada uno

Usá CVU cuando podés garantizar un CVU único por cobro. Usá CUIL cuando varios cobros comparten un mismo CVU (por ejemplo en el endpoint bulk, donde todo el lote comparte un sharedCvu), porque ahí no se puede distinguir al pagador por el CVU, pero sí por su CUIL.

El modo CVU tiene un límite práctico de CVUs activos en simultáneo por cuenta de comercio. No es un número fijo garantizado ni un tope fijado por código: es una restricción operativa del PSP, que puede estar en el orden de las decenas y varía según el tipo de cuenta. Si se agota el pool de CVUs activos disponibles, crear un cobro devuelve HTTP 400.
Recomendación: usá CUIL. Como reutiliza el mismo CVU en simultáneo, no choca con ese techo de concurrencia: es más escalable, sin techo de concurrencia y con menos CVUs abiertos. Reservá CVU para cuando pedirle el DNI/CUIL al pagador no sea viable.
#

Cuándo se asigna el CVU

En los dos modos de arriba el CVU se asigna al crear el cobro. En un cobro type "checkout" no: se asigna cuando el pagador ingresa su documento en el widget. Es la misma conciliación por CUIL, con la asignación corrida al momento en que el CUIL existe.

Por eso hereda la ventaja del modo CUIL: varios checkouts comparten una misma cuenta y se distinguen por el documento de quien paga, así que no chocan con el techo de CVUs activos en simultáneo.
#

Validar el documento antes de cobrar

En modo CUIL el cobro se identifica por el documento del pagador, así que un documento mal tipeado hace que el pago no se concilie. Podés confirmar la identidad contra el padrón de ARCA antes de crear el cobro.

1
El pagador ingresa su CUIL/CUIT o DNI.✓
2
Consultás GET /payer-lookup?document=... y obtenés el nombre registrado en ARCA.✓
3
Le mostrás "¿Sos Juan Pérez?" y confirma.✓
4
Recién ahí creás el cobro con POST /payment-request, con el documento ya validado.✓

Los dos casos sin nombre piden decisiones opuestas

200 con name: null. ARCA respondió y no hay titular para ese documento. Casi siempre es un error de tipeo: conviene que el pagador lo corrija antes de seguir.
503: no se pudo consultar a ARCA. La identidad quedó sin verificar, y vos decidís si reintentás o dejás seguir el pago sin validación.

La respuesta trae únicamente name, taxId y taxIdType. Nunca domicilio ni datos fiscales.

Cada consulta descuenta de un cupo diario propio, separado del de creación de cobros. Un CUIL/CUIT cuesta 1 y un DNI cuesta 2, porque el DNI obliga a probar dos CUIL candidatos contra ARCA. Al agotarlo recibís un 429 con availableAtUnixSeconds.

#

Corregir el pagador de un cobro ya creado

Si el cobro se creó con el documento equivocado, PATCH /payment-request/{referenceId}/customer lo reasigna al pagador correcto sin cancelarlo. Solo aplica a cobros en modo cuil que todavía no recibieron pagos. Los campos name, email y phoneNumber son opcionales: si no los enviás, se conservan los que ya tenía esa persona.

Mirá cvuChanged en la respuesta. Es poco frecuente, pero si viene en true significa que el documento nuevo colisionaba en el CVU anterior y el cobro se movió a otro: si ya le comunicaste el CVU al pagador, tenés que avisarle el nuevo.
#

Datos del pagador en el webhook

Cuando se pudo identificar al pagador real, el webhook trae reconciledPayerName, reconciledPayerCbu y reconciledPayerCuil.

reconciledPayerCuil viene vacío cuando el pagador coincide con el comercio (autopago). Para probar la conciliación por CUIL, usá un CUIL de pagador distinto al CUIT del comercio; si coinciden, no vas a ver el CUIL en el evento.