¿Clip tiene sandbox? La respuesta verificada 2026 (y por qué la documentación se contradice)

En parte. Clip sí tiene un ambiente de pruebas (sandbox) con credenciales y tarjetas de prueba, pero solo para las APIs de Checkout Transparente y Reembolsos. Su FAQ aún dice que no hay sandbox, y todo lo demás — links de pago, terminales, el resto de las APIs — no lo tiene. Para eso pruebas en producción con un cobro real mínimo (los bancos aceptan MXN$1 o hasta $0.01) y lo reembolsas de inmediato.

Esa contradicción no es un error tuyo de lectura: es real. La página developer.clip.mx/reference/pruebas publica un set de tarjetas de prueba y credenciales de modo prueba, mientras que las preguntas frecuentes siguen diciendo que Clip no tiene sandbox. Ambas cosas son ciertas al mismo tiempo porque el modo prueba solo cubre una rebanada de la plataforma. Si vienes de Stripe o Conekta esto te va a chocar, porque ahí el test mode es universal. En Clip no lo es, y confundir las dos cosas es la fuente número uno de cargos reales accidentales en QA.

Este post es el manual de campo para probar Clip sin quemarte: qué cubre de verdad el modo prueba, el ritual de “cobra un centavo y reembólsalo” para todo lo demás, y las barreras de ingeniería (idempotencia, feature flags, conciliación) para que ninguna corrida de QA cobre dos veces ni deje un cargo huérfano en producción.

Sandbox universalNo. La FAQ lo confirma: no hay sandbox global como en Stripe/Conekta

Modo prueba parcialSí, solo Checkout Transparente + Reembolsos: credenciales y tarjetas de prueba

Links de pago, terminales, restoSin modo prueba: pruebas en producción con un cargo real mínimo

El ritualCobra MXN$0.01–$1 real, reembólsalo, con idempotencia y feature flag

Qué cubre el ambiente de pruebas de Clip: solo Checkout Transparente + Reembolsos

Sé preciso con el alcance, porque aquí es donde la gente se tropieza. El modo prueba de Clip aplica a dos flujos:

Checkout Transparente — el cliente se queda en tu sitio; tú tokenizas la tarjeta y cobras por API. Sus endpoints son generatecardtoken (Card Token API) y realizarpago (Payments API, o sea POST /payments).
Reembolsos — la API de Refunds, para revertir un cobro.

Eso es todo. El resto de la plataforma no tiene modo prueba:

Checkout Redireccionado — cuando generas un link de pago (“link de pago”) y rediriges al cliente a la página hospedada de Clip.
Checkout Embebido — el checkout de Clip incrustado en tu página.
Terminales / pinpad — todo el mundo físico de lectores de tarjeta.
Cualquier otra API que no sea Card Token, Payments o Refunds.

La consecuencia práctica: si tu integración es Checkout Transparente puro, puedes probar casi todo con credenciales de prueba. Si usas links de pago, terminales o cualquier otra cosa, no hay atajo — vas a producción con cargos reales mínimos. La mayoría de las integraciones reales son mixtas, así que en la práctica vas a necesitar ambas técnicas en el mismo proyecto.

Si todavía estás decidiendo qué modo de checkout usar, lo desgloso en el post hermano de integración de Clip. Aquí asumo que ya elegiste y solo quieres probarlo sin cobrarle a tus clientes por error.

El detalle de auth: la credencial de prueba lleva el prefijo `test_` y no se parece a la de producción

Este es el gancho que nadie te advierte y que rompe la corrida de pruebas del primer día. Clip no te da un host de sandbox aparte ni una bandera de modo: prueba vs. producción lo decide la credencial que mandas, y las dos credenciales ni siquiera se parecen. La de prueba es un token Bearer con prefijo test_ que la API detecta automáticamente como modo prueba (por ejemplo Bearer test_6e107925-...). La de producción es tu API key y tu clave secreta en Base64 detrás de Basic, que según la API que consumes va en el header x-api-key o en authorization — ese detalle depende del endpoint, no del entorno. Puedes crear hasta 6 credenciales de prueba y 6 de producción por cuenta.

La consecuencia de ingeniería: un cliente HTTP que hardcodea el header de auth va a funcionar en prueba y fallar con 401 en producción (o al revés), porque Bearer test_... y Basic <base64> no son intercambiables. Trátalo como configuración por entorno, no como constante — y verifica el header exacto de cada endpoint en developer.clip.mx/reference, no de memoria:

// La credencial de Clip (y su esquema) depende del entorno. No la hardcodees:
// resuélvela desde config. Prueba = "Bearer test_..."; producción = "Basic <base64>".
function clipAuthHeader(env) {
  // Verifica en developer.clip.mx/reference si el endpoint espera el token
  // en `authorization` o en `x-api-key`; ese detalle es por-API.
  return env.CLIP_AUTH; // p. ej. "Bearer test_6e107925-..." o "Basic <base64 key:secret>"
}

const clip = {
  baseUrl: 'https://api.payclip.com',
  auth: clipAuthHeader(process.env),
};

La regla que te ahorra una tarde de depuración: la credencial y su esquema son un solo valor de configuración por entorno. Nunca los separes. Si mandas el esquema de un entorno con la credencial del otro, la petición se rompe de una forma que parece un bug de red pero es un mismatch de auth.

Probar el flujo cubierto: credenciales de prueba, la tabla de tarjetas y el card token de 15 minutos

Para lo que sí tiene modo prueba (Checkout Transparente + Reembolsos), el flujo es el normal de cobro con dos pasos. Primero tokenizas la tarjeta con generatecardtoken, que te devuelve un Card Token ID en el campo id con expiración de 15 minutos. Luego cobras con realizarpago (POST /payments) pasando ese token anidado en payment_method, el monto y "currency": "MXN".

// Paso 1: tokenizar con generatecardtoken -> Card Token ID en `id` (expira en 15 min)
// Usa las tarjetas de prueba de developer.clip.mx/reference/pruebas.
const tokenRes = await fetch('https://api-secure.payclip.com/card_tokens', {
  method: 'POST',
  headers: { Authorization: clip.auth, 'Content-Type': 'application/json' },
  body: JSON.stringify({ /* datos de la tarjeta de prueba */ }),
});
const { id: cardTokenId } = await tokenRes.json();

// Paso 2: cobrar con realizarpago (POST /payments); el token va anidado en payment_method
const payRes = await fetch('https://api.payclip.com/payments', {
  method: 'POST',
  headers: { Authorization: clip.auth, 'Content-Type': 'application/json' },
  body: JSON.stringify({
    amount: 1.00,
    currency: 'MXN',
    payment_method: { token: cardTokenId },
  }),
});

Dos cosas que importan en la práctica. Una: los nombres exactos de campos y rutas verifícalos siempre en la referencia; los nombres de endpoint (generatecardtoken, realizarpago) son estables pero el shape del body evoluciona. Dos: la expiración de 15 minutos del Card Token ID es un límite real. En una corrida de QA lenta — donde tokenizas, revisas logs, tomas un café y luego cobras — el token puede caducar y realizarpago falla. No es un bug: tokeniza y cobra dentro de la misma ventana, o regenera el token.

Clip también expone obtenermetodosdepago (Payment Methods) y obtenercuotasmensuales (Installments / meses sin intereses) para armar el checkout, pero el par que de verdad ejerces en pruebas es token + pago.

Carga credenciales de PRUEBALa credencial de prueba es un Bearer con prefijo test_; resuélvela desde config
generatecardtoken con una tarjeta de pruebaDevuelve un Card Token ID (en el campo id) que expira en 15 min
realizarpago (POST /payments)payment_method.token + amount + currency: MXN, dentro de la ventana de 15 min
Reembolsa vía Refunds APIEl único otro flujo con modo prueba; cierra el ciclo

Por qué Clip no es Stripe ni Conekta: no hay modo prueba universal en todas las APIs

Si tu modelo mental viene de Stripe o Conekta, recalíbralo. En esas plataformas el test mode es un interruptor global: flipeas una llave, todo el dashboard, todas las APIs y todos los webhooks operan contra datos falsos, y cobras con 4242 4242 4242 4242 en cualquier flujo. Nunca tocas dinero real hasta que quieres.

Clip no funciona así. El modo prueba es una excepción acotada a dos APIs, no el default de la plataforma. Todo lo que quede fuera de Checkout Transparente y Reembolsos opera contra dinero real desde el primer request. Ese es exactamente el punto que la FAQ de Clip captura cuando dice que no hay sandbox: desde la perspectiva de “una sola llave que apaga el dinero real en toda la plataforma”, no lo hay.

La implicación de ingeniería es que no puedes tratar a Clip como Stripe en tu suite de pruebas. No hay un entorno espejo completo. Tienes que segmentar tus pruebas: lo que cae en las dos APIs cubiertas va con credenciales de prueba; todo lo demás va con el ritual de cargo real mínimo de la siguiente sección. Si comparas cabeza a cabeza cómo se sienten las tres pasarelas mexicanas, escribí Stripe vs Mercado Pago vs Conekta — y el contraste de test mode es una de las diferencias que más duele en el día a día.

Stripe / Conekta

Interruptor global: todas las APIs en test mode
Tarjetas de prueba en cualquier flujo
Webhooks de prueba end-to-end
Nunca tocas dinero real hasta querer

Clip

Modo prueba solo en Checkout Transparente + Reembolsos
Links de pago, terminales y demás sin test mode
Todo lo no cubierto opera con dinero real
Requiere ritual de cargo real mínimo + reembolso

El ritual de pruebas en producción para lo demás: cobra un centavo y reembólsalo (Node)

Para todo lo que no tiene modo prueba, esta es la técnica probada: cobras un monto real diminuto y lo reembolsas de inmediato. Algunos bancos aceptan MXN$1 o incluso $0.01 con comisión prácticamente nula. El lado bueno de que sea real: un cargo de prueba exitoso significa que de verdad estás listo para producción — no hay un entorno espejo que te mienta.

El patrón mínimo en Node:

// Ritual de prueba en producción: cobra un monto real diminuto, luego reembólsalo.
async function smokeTestClipCharge() {
  const amount = 0.01; // MXN$0.01 — comisión prácticamente nula

  const pay = await fetch(`${clip.baseUrl}/payments`, {
    method: 'POST',
    headers: { Authorization: clip.auth, 'Content-Type': 'application/json' },
    body: JSON.stringify({ amount, currency: 'MXN', payment_method: { token: cardTokenId } }),
  }).then((r) => r.json());

  // Reembolsa de inmediato — no dejes el cargo real colgando.
  await fetch(`${clip.baseUrl}/refunds`, {
    method: 'POST',
    headers: { Authorization: clip.auth, 'Content-Type': 'application/json' },
    body: JSON.stringify({ payment_id: pay.id, amount, currency: 'MXN' }),
  });

  return pay.id;
}

La disciplina que convierte esto de “hack peligroso” en “prueba de humo confiable”: reembolsa siempre, y reembolsa antes de considerar la prueba terminada. Un cargo de prueba sin su reembolso es dinero real de un cliente atorado en tu cuenta. Envuélvelo en un try/finally si hace falta, pero nunca dejes que un throw a media prueba se salte el reembolso. Verifica los nombres exactos de la ruta de reembolso (/refunds) y del campo del monto contra la referencia de Clip; el patrón es estable, los nombres pueden variar.

La idempotencia que Clip no te da: aplica una clave de deduplicación para que un reintento de QA nunca cobre doble

Aquí está el filo real de probar con dinero de verdad. Sin sandbox, cada corrida de tu prueba mueve dinero de verdad. Si tu runner de QA reintenta ante un timeout de red, o alguien corre el script dos veces, cobras dos veces. En un sandbox eso no importa; en producción sí.

La defensa estándar de pasarelas aplica exactamente igual que en los posts de Stripe/Mercado Pago/Conekta: una clave de idempotencia. Le asignas a cada intento lógico de cobro una clave estable, y tu capa la usa para deduplicar. Si Clip no honra un header de idempotencia nativo en ese endpoint, tú implementas la barrera del lado servidor: registra la clave antes de llamar, y si ya existe con un pago exitoso, devuelve ese resultado en vez de cobrar otra vez.

// Deduplicación del lado servidor: una clave lógica estable por intento de cobro.
async function chargeOnce(idempotencyKey, body) {
  const existing = await db.getCharge(idempotencyKey);
  if (existing?.status === 'paid') return existing; // ya cobrado: no repitas

  const res = await fetch(`${clip.baseUrl}/payments`, {
    method: 'POST',
    headers: {
      Authorization: clip.auth,
      'Content-Type': 'application/json',
      // Si el endpoint acepta un header de idempotencia, mándalo también.
      // Verifica el nombre exacto en developer.clip.mx/reference.
      'Idempotency-Key': idempotencyKey,
    },
    body: JSON.stringify(body),
  }).then((r) => r.json());

  await db.saveCharge(idempotencyKey, { status: 'paid', paymentId: res.id });
  return res;
}

Si quieres el tratamiento a fondo de por qué la deduplicación y la resistencia a replays no son opcionales en pagos, lo desarrollo en verificar la firma del webhook de Stripe — los patrones de idempotencia y replay son los mismos sin importar la pasarela.

Blindar producción: pon el monto tras un feature flag, ponle tope y registra cada cobro de prueba

Como tus pruebas corren contra producción, un accidente es un cobro real a un cliente real. Tres barandales, no negociables:

Feature flag el monto de prueba. El cargo diminuto solo debe existir cuando una bandera explícita de prueba está encendida. Sin la bandera, la ruta de smoke test ni siquiera se puede invocar. Así una corrida accidental en producción normal es imposible por construcción.
Ponle tope al monto. Valida en el servidor que cualquier cargo de prueba sea menor o igual a un techo bajo (p. ej. MXN$1). Un fat-finger que ponga 100.00 en vez de 0.01 debe rebotar antes de tocar la API de Clip.
Registra cada cobro de prueba. Cada cargo de prueba deja un log con quién, cuándo, monto, payment_id y su reembolso correspondiente. Sin esa bitácora no puedes auditar si algún reembolso quedó pendiente.

// Blinda la ruta de prueba: bandera + tope + bitácora antes de tocar Clip.
function assertTestCharge(amount, flags) {
  if (!flags.CLIP_TEST_CHARGE_ENABLED) throw new Error('prueba deshabilitada');
  const CAP = 1.00; // MXN$1 tope duro para cualquier cargo de prueba
  if (amount > CAP) throw new Error(`monto de prueba ${amount} supera el tope ${CAP}`);
  log.info('clip_test_charge', { amount, at: new Date().toISOString() });
}

El feature flag es el barandal más importante de los tres, porque convierte “acordarse de tener cuidado” en “imposible por default”. La disciplina no escala; la configuración sí.

Feature flag del monto de pruebacrítico

Tope duro al monto (≤ MXN$1)alto

Bitácora de cada cargo + reembolsoalto

Reembolso en finallymedio

Conciliar tu prueba contra Clip: consulta Get Payment en vez de confiar en el cliente

La regla de oro de pagos también manda en pruebas: nunca confíes en el “éxito” del lado cliente. La respuesta inmediata de realizarpago te da un payment_id, pero el estado final autoritativo lo tiene Clip. Para conocerlo consultas el endpoint “Consultar un Pago” (Get Payment) y lees el estado que Clip reporta.

// La verdad la tiene Clip, no tu cliente. Consulta Get Payment.
async function reconcile(paymentId) {
  const res = await fetch(`${clip.baseUrl}/payments/${paymentId}`, {
    headers: { Authorization: clip.auth },
  });
  const payment = await res.json();
  // Lee el estado que reporta Clip; no inventes enums de estatus.
  // Verifica los nombres de campo en developer.clip.mx/reference.
  return payment;
}

En una prueba de humo esto es lo que cierra el ciclo: cobraste, reembolsaste, y ahora confirmas contra la fuente autoritativa que tanto el cargo como el reembolso quedaron registrados como Clip los ve — no como tu código cree que quedaron. Si vas a operar varias pasarelas a la vez, la conciliación cruzada se vuelve su propia disciplina; la trato en conciliación de pagos multi-rail en México.

Manejar el webhook de pago: verifícalo y luego pide el estado final a la API

Clip envía una notificación por webhook cuando cambia el estado de un pago. Una forma verificada de la notificación se ve así:

{
  "id": "pinpad-...",
  "origin": "pinpad-payments-api",
  "event_type": "PINPAD_INTENT_STATUS_CHANGED"
}

El patrón correcto son dos pasos, y es el mismo que uso con cualquier pasarela. Primero, verifica la autenticidad de la notificación antes de actuar sobre ella — trata todo webhook entrante como no confiable hasta probar que vino de Clip. Segundo, no te fíes del payload para el estado final: el webhook es una señal de “algo cambió”, así que úsalo como disparador para consultar “Consultar un Pago” (Get Payment) y leer el estado autoritativo. No inventes valores de estatus a partir del event_type; pide la verdad a la API.

Por qué webhook + consulta en vez de solo uno de los dos: los webhooks se pierden, se duplican y se reordenan; el polling puro desperdicia llamadas. La combinación — webhook como disparador, consulta autoritativa como fuente de verdad — es la robusta. Desarrollo el trade-off completo en webhooks vs polling vs API.

Tu checklist antes de salir a producción con pagos en línea de Clip

Antes de mandar tu integración de Clip a producción:

Confirmaste qué flujos usas y cuáles caen bajo modo prueba (solo Checkout Transparente + Reembolsos) vs cuáles exigen el ritual de cargo real mínimo.
Modo, credencial y esquema de auth viven en un solo objeto de configuración por entorno — nada de esquemas hardcodeados que pasan en prueba y truenan en producción.
Tu prueba de humo cobra MXN$0.01–$1 y reembolsa en un finally, sin dejar cargos huérfanos.
Cada intento lógico de cobro lleva una clave de idempotencia; un reintento de QA no puede cobrar doble.
El monto de prueba está tras un feature flag, tiene tope duro y cada cargo + reembolso queda en la bitácora.
Nunca marcas nada como pagado desde el cliente: concilias con “Consultar un Pago” (Get Payment).
El webhook se verifica primero y solo dispara una consulta autoritativa del estado final; no inventas enums de estatus.
Respetas la expiración de 15 minutos del Card Token ID entre generatecardtoken y realizarpago.

Si quieres el otro lado de la moneda — cómo montar los tres modos de checkout de Clip de punta a punta en Node — está en el post hermano de integración de Clip, y el panorama de dónde encaja Clip frente a las demás pasarelas mexicanas en Stripe vs Mercado Pago vs Conekta. Todo esto es parte del hub de pagos LATAM, donde reúno lo que de verdad se necesita para cobrar en México sin sorpresas.

Fuentes: la documentación para desarrolladores de Clip, sus preguntas frecuentes y la guía de pruebas — verificadas el 2026-07-06. Verifica siempre los nombres exactos de endpoints, campos y esquemas de auth contra la referencia viva, nunca contra la memoria.

¿Clip tiene sandbox? Tarjetas de prueba, credenciales de prueba y cómo probar en producción (2026)