Saltar al contenido principal

Solicitud de pago

La Solicitud sirve para recibir pagos fuera de tu web: generas enlaces de pago y los envías por WhatsApp, correo o QR. Se crean por lote (uno o varios a la vez).

Diferencia con el Botón

El Botón recibe pagos dentro de tu sitio; la Solicitud genera enlaces para enviar por un canal externo. Una Solicitud no se marca failed: o se paga (paid) o vence (expired). → Ciclo de vida.

Solicitud: envía enlaces de pago por WhatsApp, correo o QR

Crear un lote de solicitudes​

curl -X POST https://sim-productos.abiertolab.com/api/v1/ext/payment-sessions/request/batch \
  -H "Authorization: Bearer <token>" -H "Content-Type: application/json" \
  -d '{
    "continue_on_error": true,
    "items": [{
      "title": "Pago de Rafael",
      "currency_reference": "USD",
      "amount_reference": 100,
      "agreement_id": "<agreement_id>",
      "identifier_label": "Nombre Cliente",
      "identifier": "Rafael",
      "description": "Pago de servicio",
      "due_date_session": "2026-12-31T23:59:59Z",
      "due_date_reached_behavior": "keep_active",
      "late_notice_message": "Tu enlace de pago está por vencer",
      "internal_reference": "REF-0001",
      "success_url": "https://miapp.com/pago-exitoso",
      "failure_url": "https://miapp.com/pago-fallido",
      "webhook_url": "https://miapp.com/webhooks/spidi"
    }]
  }'
  • continue_on_error — si un ítem del lote falla, sigue con los demás.
  • items — una entrada por solicitud; cada una nace pending con su payment_url.
  • due_date_session / due_date_reached_behavior — vencimiento del enlace y qué hacer al llegar.
  • late_notice_message — texto del aviso cuando el enlace está por vencer (obligatorio).
  • internal_reference — tu referencia interna de la solicitud (obligatorio).

Confirmar el pago​

Igual que el Botón: confirma con GET status y/o el webhook payment_session.paid. → Success URL: verificar status · Manejar notificaciones.

paid no es el dinero acreditado

paid confirma el débito (leg 1) — no que el dinero ya está en manos del beneficiario. La acreditación (leg 2) llega solo por webhook (payment_session.accredited) y no cambia el status. → Transacción a dos tiempos.

Probar en el simulador​

# fuerza el pago de la sesión creada (data.id del lote)
curl -X POST https://sim-productos.abiertolab.com/control/sessions/<session_id>/outcome \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"leg":1,"outcome":"paid"}'

Este flujo (crear lote → pending → paid) está verificado contra el simulador (simulador/test/func/guides.func.test.ts).

→ Usar el simulador