Conceptos

La referencia compartida a la que enlazan las páginas de producto. Está después de Spot y AAPD a propósito — primero lee las páginas de producto, después cae aquí cuando un término necesita desambiguación. El catálogo de errores HTTP vive en Referencia → Errores.

Glosario

Autenticación

Skip usa cuatro credenciales distintas en su superficie API. No son intercambiables.

Cómo se envía cada una

public_key  →  query string
              ?public_key=pk_live_xxx

client_id / client_secret  →  Authorization header
              Authorization: Bearer <credencial>

secret_key  →  header
              secret_key: sk_partner_xxx

Confusiones comunes

• "¿client_id o client_secret?" Usa client_secret para cualquier operación que tu backend haga que cree o modifique estado (órdenes). Usa client_id para lo que hace el widget en nombre del paciente (el widget las lee de tu config).
• "¿public_key es secreta?" No. Es la misma clave que pones en tu código frontend. Lo sensible es client_secret y webhook_secret.

Rotación

Para rotar cualquier credencial, coordínalo con el equipo de Skip. En el caso de client_secret y webhook_secret, tanto el valor viejo como el nuevo funcionan ~5 minutos después de la rotación, así que puedes: deploy primero, luego rotación, luego deploy de nuevo, sin downtime.

Ambientes y URLs base

Skip corre dos ambientes. Ambos tienen funcionalidad completa. Usa staging para desarrollo y testing de integración; cambia a producción cuando salgas en vivo.

Eligiendo ambiente

Las credenciales de staging están separadas de las de producción. Si tu public_key es pk_test_*, estás en staging. Si es pk_live_*, estás en producción. Cuando Skip te onboardea, recibes ambos pares. Configúralos vía variables de entorno:

# staging
SKIPPAY_API_URL=https://staging.pay.getskip.ai
SKIP_BACKEND_URL=https://staging.backend.getskip.ai/api
SPOT_WIDGET_URL=https://staging.spot.getskip.ai
SKIP_PUBLIC_KEY=pk_test_xxx
SKIPPAY_CLIENT_ID=ci_test_xxx
SKIPPAY_CLIENT_SECRET=st_test_xxx

# producción
SKIPPAY_API_URL=https://pay.getskip.ai
SKIP_BACKEND_URL=https://backend.getskip.ai/api
SPOT_WIDGET_URL=https://spot.getskip.ai
SKIP_PUBLIC_KEY=pk_live_xxx
SKIPPAY_CLIENT_ID=ci_live_xxx
SKIPPAY_CLIENT_SECRET=st_live_xxx

Qué es igual y qué es distinto

Paths, shapes de endpoints y esquema de firma de webhook son idénticos en ambos. El origen del widget que validas en postMessage es siempre https://spot.getskip.ai. Lo que cambia: en staging los pagos corren en sandbox (no mueven plata real), los WhatsApp van a un número de prueba de Skip, y la presentación ISAPRE está mockeada (los reembolsos se aprueban al instante). Si necesitas un staging más fiel (ej. simular un cobro anticipado por timeout), pídeselo al equipo de Skip.

Probar pagos en staging

En staging el pago del paciente (el 30% del widget AAPD, o cualquier captura de tarjeta) corre en el sandbox de pagos de Skip — ninguna tarjeta real se cobra. Usa estas tarjetas de prueba para simular resultados en el widget:

El set completo (límite excedido, tarjeta vencida, etc.) está en la documentación de tarjetas de prueba del procesador — esa página es la fuente de verdad si algún número cambia. Estas tarjetas solo funcionan en staging; en producción son rechazadas.

Administración de órdenes

Skip opera un panel de administración interno para operaciones sobre órdenes AAPD (revisar estado, reintentos, soporte), disponible tanto en staging como en producción. No es self-service ni tiene URL pública: si tu operación necesita acceso, coordínalo con el equipo de Skip. Para operaciones programáticas usa la API con tu client_secret.

RUT, beneficiarios, ISAPRE

Skip es un producto chileno. Tres conceptos chilenos aparecen en todas partes.

RUT

El RUT ("Rol Único Tributario") es el ID nacional chileno. Toda persona y toda entidad legal tiene uno. Formato: XXXXXXXX-Y, donde X es hasta 8 dígitos y Y es un dígito verificador (0–9 o K).

Skip normaliza los RUTs antes de almacenar o comparar: quita los puntos, mantiene el guion antes del dígito verificador, convierte K a mayúscula, sin ceros a la izquierda.

12.345.678-9   →  12345678-9
12.345.678-K   →  12345678-K   (K mayúscula)

Puedes enviar cualquier variante — Skip normaliza al recibir. Cuando Skip te devuelve un RUT, siempre está normalizado. Skip rechaza RUTs mal formados con 422; igual conviene validar client-side para mejor UX:

function rutCheckDigit(body) {
  let sum = 0;
  let factor = 2;
  for (const digit of String(body).split("").reverse()) {
    sum += parseInt(digit, 10) * factor;
    factor = factor === 7 ? 2 : factor + 1;
  }
  const remainder = 11 - (sum % 11);
  if (remainder === 11) return "0";
  if (remainder === 10) return "K";
  return String(remainder);
}

Beneficiario

Un Beneficiary es la ficha del paciente que Skip crea cuando un usuario se registra vía widget o POS. Un User (titular de cuenta) puede ser dueño de varios beneficiarios — él mismo, su pareja, sus hijos. El RUT es la clave única por beneficiario. Cuando envías una boleta o creas una orden AAPD, Skip busca el Beneficiary por RUT y enruta todo (reembolsos, notificaciones) bajo esa ficha.

ISAPRE

Una ISAPRE ("Instituciones de Salud Previsional") es una aseguradora privada chilena de salud. Los pacientes son afiliados a una ISAPRE (o a FONASA, el seguro público) y presentan reembolsos a ella. Cuando un paciente se registra a Skip, entrega sus credenciales de login de la ISAPRE; Skip las usa para presentar reembolsos en su nombre. ISAPRE comunes: Banmédica, Colmena, Consalud, CruzBlanca, Vida Tres, Esencial. FONASA es la opción pública.

Issuer RUT vs doctor RUT

Una boleta médica tiene dos RUTs relevantes, y ambos los pide la ISAPRE para reembolso:

• Issuer RUT (receipt_rut, provider_rut, issuer_rut — el nombre varía por endpoint): la entidad que emitió la boleta. Usualmente la clínica o farmacia.
• Doctor RUT (doctor_rut, physician_rut): el médico que prestó el servicio.

Skip los almacena por separado. Cuando envías una boleta, popula los dos — incluso si es la misma persona.