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 cuando ambas cuotas se liquidan en los libros de SkipPay — la captura del 30% y la aprobación del préstamo del 70%. Para el caso de cobro diferido (aprobación ISAPRE en, digamos, día 15), ese status = paid llega en el día 15, no en el día 0. Si quieres detectar "el paciente terminó el widget y el préstamo está en proceso", espera el order.changed con status = partially_paid.

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
  → webhook order.changed · status paid (final) dispara
  → 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
  → webhook order.changed · status paid (final) dispara
  → 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
  → webhook order.changed · status paid (final) dispara
  → 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 recibe el mismo order.changed final con status = paid (y el paid_amount total). Las diferencias se ven en el timing, 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