Skip Docs

Estas secciones recorren los procesos AAPD de extremo a extremo, con diagramas que nombran a cada actor y llamada. Úsalas para construir un modelo mental antes de leer la referencia endpoint por endpoint.

Orden AAPD end-to-end

El camino feliz: paciente paga 30% con tarjeta, ISAPRE aprueba, Skip cobra el 70% restante, la orden cierra.

Qué implementas realmente

De las llamadas en el diagrama, tu equipo escribe tres:

POST /orders (tu backend, server-side, client_secret).
POST /api/spot/widget (tu backend, server-side, public_key).
Embed del iframe + listener de postMessage (tu frontend), más el receptor de webhooks order.changed (tu backend, reaccionas al status = paid).

Todo lo demás (validación de identidad, setup de tarjeta, coordinación del financiamiento, presentación a la ISAPRE, eventual cobro del 70%) es responsabilidad de Skip y del widget.

Cuándo llega el `status = paid`

El order.changed con status = paid llega en el día 0, al completar el checkout: el 30% se capturó y el préstamo por el 70% quedó autorizado, con lo que la orden queda 100% pagada en los libros de SkipPay — Skip asume el cobro posterior del 70% al paciente. Se emite exactamente una vez por orden.

El cobro efectivo del 70% (aprobación ISAPRE en, digamos, día 15, o cobro anticipado) es gestión interna de Skip y no genera un webhook nuevo — a tus ojos la orden ya estaba pagada. El único evento posterior posible es status = refunded, si hay una reversa.

Línea de tiempo ISAPRE

La porción del 70% de una orden AAPD se cobra según lo que haga la ISAPRE. Hay tres timelines posibles.

A. ISAPRE aprueba (caso típico)

Boleta llega → reembolso presentado
ISAPRE procesa el reembolso
ISAPRE aprueba
  → Skip cobra el 70% restante
  → (sin webhook — tu orden ya estaba paid desde el checkout)
  → Paciente: notificación WhatsApp de pago exitoso

B. Acceso ISAPRE bloqueado

Reembolso presentado
Skip no logra acceder a la ISAPRE (contraseña, 2FA o cuenta bloqueada)
  → Paciente: notificación WhatsApp para regularizar el acceso
Si el acceso sigue bloqueado → Skip dispara cobro anticipado
  → 70% + comisiones cobrados
  → (sin webhook — tu orden ya estaba paid desde el checkout)
  → Paciente: notificación WhatsApp de cobro anticipado

C. La ISAPRE no resuelve a tiempo

Reembolso presentado
La ISAPRE queda demasiado tiempo sin resolver
  → Skip dispara cobro anticipado
  → 70% + comisiones cobrados
  → (sin webhook — tu orden ya estaba paid desde el checkout)
  → Paciente: notificación WhatsApp de cobro anticipado

Si la ISAPRE eventualmente aprueba (después del cobro anticipado):
  → Skip reversa y reembolsa el monto adelantado al paciente
  → webhook order.changed · status refunded dispara

En los tres casos tu endpoint ya recibió el único order.changed con status = paid en el día 0 — estos timelines no te notifican nada nuevo, salvo el refunded del caso C. Las diferencias se ven en el timing del cobro interno, las notificaciones al paciente y un posible reembolso posterior (caso C). Si quieres distinguir los casos para tu reporting, consulta GET /orders/{hash} e inspecciona la metadata del payment.

Videos demo

Grabación pendiente. Cada item se convertirá en un YouTube unlisted embebido cuando lo grabemos.

Widget AAPD end-to-end (~3 min) — Un paciente recorriendo el camino feliz completo: validación de identidad, setup de tarjeta, pago, éxito. Audiencia: cualquier partner AAPD.
Onboarding de sub-centro vía API (~2 min) — Un flujo estilo Sacmed: registrar un sub-centro, después crear una orden contra él. Audiencia: meta-prestadores.
Verificación de firma de webhook en 5 lenguajes (~2 min) — Mostrar los snippets de verificación en cURL, JS, Python, PHP, Go y confirmar que cada uno rechaza una firma inválida. Audiencia: cualquiera que recibe webhooks AAPD.

Flujos de AAPD