Capturar pago

POST /orders/{order_hash}/payment
Authorization: Bearer {client_id}

Llamado por el widget. La primera llamada crea una fila Payment; el flujo del préstamo procede de forma asíncrona vía webhooks de Ventipay.

Esta es la llamada que inicia el préstamo. No captura fondos de forma síncrona — Ventipay procesa la solicitud, captura el 30%, y financia el 70% en su propio timeline. SkipPay recibe esos eventos de Ventipay y los expone como webhooks salientes a ti.

Respuesta (201 Created)

{
  "hash": "pay_xyz789",
  "status": "pending",
  "amount": "100000",
  "payment_provider": "ventipay",
  "created_at": "2026-04-15T10:05:00Z"
}

status empieza como pending y transita por el ciclo de vida del Payment de SkipPay:

pending → paid → (refunded | partially_refunded)
       └→ failed

No haces polling. Recibes webhooks (ver Webhooks → Catálogo de eventos).

Por qué el widget puede llamar varias veces

El widget usa este endpoint también como probe de readiness. Si las precondiciones no están listas, devuelve 400 con códigos como processor_customer_identity_not_validated o processor_payment_method_not_found. El widget interpreta esas respuestas como señales de control de flujo — muestra la pantalla correcta y reintenta más tarde.

Un 400 desde POST /payment temprano en el flujo no es una integración rota. Ver Casos borde del widget Spot.

Cuándo ves "paid"

El webhook order.paid dispara cuando ambas cuotas están liquidadas en los libros de SkipPay — la captura del 30% y la aprobación del préstamo del 70%. Hasta entonces, la orden puede quedar en partially_paid.