Cobros

• Se configuran en la emisión de cada producto: proveedor (stripe, mercadopago, rebill o manual) y modalidad: pago único, recurrente o por uso.
• Un producto puede ofrecer varios proveedores en el checkout; el elegido llega en data.payment.provider. Si no está habilitado responde 422 (Este medio de pago no está habilitado para este producto.).
• Las credenciales de cada proveedor se conectan por separado para Sandbox y Producción. Una póliza de sandbox nunca usa credenciales de producción.
• El proveedor elegido queda guardado en la póliza: cambiar la lista después no mueve pólizas ya emitidas.

Nunca se guarda el número completo de tarjeta: solo los últimos 4 dígitos, la marca y el titular. El CVV nunca se pide, guarda ni envía.

• Pago único online: la póliza se emite pending_payment y la respuesta trae payment con kind: payment. Stripe devuelve clientSecret y publishableKey (Payment Element); MercadoPago, redirectUrl (Checkout Pro).
• Recurrente o por uso con proveedor (Stripe, Mercado Pago o Rebill): la póliza se emite pending_payment con payment_method_status: pending y nunca está active antes de cobrarse. Recurrente (monto conocido): payment cobra el primer período y guarda la tarjeta (Stripe: kind: payment con firstCharge: true; Mercado Pago / Rebill: la suscripción, que cobra el primer período al autorizarse); pasa a active al confirmarse ese primer cobro. Por uso (monto desconocido hasta el cierre): solo se valida la tarjeta, sin cobro (Stripe: kind: setup; Mercado Pago: suscripción autorizada con el primer cobro al cierre; Rebill: suscripción con período de prueba, aprobación de $0); pasa a active al validarse. Nunca se hace un cobro simbólico. Un primer cobro rechazado deja la póliza payment_failed (no activa) y se puede reintentar. Si el producto tiene condiciones, primero se resuelven y recién entonces se habilita este paso.
• Un intento rechazado (pago único, primer período o validación de tarjeta) deja la póliza payment_failed con payment_status: failed: aparece como «Pago rechazado» en el portal, en el portal de clientes y en Aprobaciones → Pagos rechazados, y se puede filtrar en el listado de pólizas. Se notifica una vez por intento al intermediario (o a los administradores) y al asegurado con el motivo y el link para reintentar. El mismo link sigue siendo válido y un pago aprobado la activa en ese momento.
• Toda respuesta con payment incluye statusToken para consultar el estado sin clave API.
• Las confirmaciones llegan por los webhooks de cada proveedor, por entorno.

{
  "id": "b2a7…",
  "policy_number_internal": "TEST-POL-0007",
  "status": "pending_payment",
  "payment": {
    "kind": "payment",
    "provider": "mercadopago",
    "environment": "test",
    "redirectUrl": "https://www.mercadopago.com.ar/checkout/…",
    "statusToken": "v1.…"
  }
}

curl -X POST https://api.quore.app/api/integrations/payments/status \
  -H "Content-Type: application/json" \
  -d '{ "token": "STATUS_TOKEN" }'

{
  "policyId": "b2a7…",
  "policyStatus": "active",
  "paymentMethodStatus": null,
  "paymentStatus": "paid"
}

En productos facturados por uso reportas el consumo a medida que ocurre; al cierre de cada período se suma y se calcula la prima. Requiere una clave secreta.

curl -X POST https://api.quore.app/api/policies/POLICY_ID/usage-events \
  -H "x-api-key: sk_test_…" \
  -H "Content-Type: application/json" \
  -d '{
    "quantity": 12.5,
    "unit": "km",
    "occurredAt": "2026-10-26T13:45:00Z",
    "externalRef": "viaje-88421",
    "metadata": { "deviceId": "scooter-17" }
  }'

curl -X POST https://api.quore.app/api/policies/by-external-ref/FLOTA-001/usage-events \
  -H "x-api-key: sk_test_…" \
  -H "Content-Type: application/json" \
  -d '{ "quantity": 3, "unit": "km", "occurredAt": "2026-10-26T14:10:00Z" }'

• Responde 201 con el evento registrado.
• Por tu propio identificador: by-external-ref busca la póliza por su externalRef, que se toma al emitir de la variable que el producto define para eso.
• Unidad distinta a la del producto: 400. Póliza cancelada, vencida, rechazada o caducada por falta de pago, o consumo posterior al fin de vigencia: 422.
• Un evento que llega después del cierre de su período se cobra una sola vez en el período siguiente, como ajuste.
• Los períodos son de días fijos o meses calendario, según el producto.

• Los productos recurrentes cobran el primer período al contratar (la póliza se activa con ese cobro) y después generan un ciclo de cobro por período con el medio de pago registrado.
• Si un cobro se rechaza se reintenta a los 1, 3 y 7 días del vencimiento, dentro del período de gracia; después queda failed.
• Sin medio de pago registrado o con autenticación requerida, el ciclo queda pending_action: se avisa a los administradores y, cuando debe actuar, al asegurado.
• Tras varios ciclos fallidos la póliza queda caducada por falta de pago y deja de aceptar consumo.
• Ningún ciclo empieza después del fin de vigencia; las suscripciones de MercadoPago y Rebill se cancelan al terminar la vigencia.