Modo de prueba

Antes de cobrarle a un cliente real, prueba todo el flujo con tarjetas de prueba: no se mueve dinero y los pagos aparecen igual en la API y en los webhooks.

Cómo saber en qué modo estás

Cuando el ambiente apunta al sandbox del procesador, el panel muestra una franja naranja “Modo de prueba” arriba de todo. Este ambiente (https://go.paytiptap.com) está ahora mismo en producción.

En producción sí se cobra

Cuando el ambiente apunta a producción, cualquier pago que hagas con una tarjeta real mueve dinero de verdad y entra a tu liquidación. Prueba siempre en el ambiente de sandbox primero.

Tarjetas de prueba

Úsalas en la página de cobro. Fecha de vencimiento: cualquiera futura (por ejemplo 12/2030). CVV: 123 (Amex: 1234).

Campo	Tipo	Descripción
`4111 1111 1111 1111`	Visa	Pago aprobado. Es la que conviene para el flujo feliz.
`5555 5555 5555 4444`	Mastercard	Pago aprobado con otra marca.
`3782 8224 6310 005`	Amex	Pago aprobado con Amex (CVV de 4 dígitos).

Los montos disparan escenarios

En el sandbox del procesador ciertos montos simulan situaciones especiales. El más importante que verificamos: $45.00 dispara una autorización parcial (el banco autoriza menos del total). TipTap Go detecta el caso, anula la autorización y marca el pago como VOIDED — al cliente no se le cobra nada.

Usa montos neutros

Para probar el flujo normal usa montos como 12.50, 25.00 o 30.00. Si ves comportamientos raros, revisa primero si el monto es uno de los reservados.

Prueba completa de punta a punta

Crea una API key en Desarrolladores.
Registra un endpoint de webhook. Para desarrollo local sirve un túnel (ngrok, cloudflared) o directamente http://localhost:PUERTO, que aceptamos solo para pruebas.
Crea un link de pago de $12.50 por API.
Ábrelo en el navegador y paga con 4111 1111 1111 1111.
Verifica que llegó el webhook payment.succeeded y que GET /v1/payments lo muestra como APPROVED.

script de prueba (bash)

KEY=tiptap_sk_TU_LLAVE
BASE=https://go.paytiptap.com/api/v1

# 1. La llave funciona
curl -s $BASE/me -H "Authorization: Bearer $KEY" | jq .name

# 2. Link de prueba
LINK=$(curl -s -X POST $BASE/payment_links \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"title":"Prueba de integración","amount":12.50}')
echo $LINK | jq -r .url    # ← ábrelo y paga con 4111 1111 1111 1111

# 3. Después de pagar, el cobro aparece aquí
curl -s "$BASE/payments?status=APPROVED&limit=1" \
  -H "Authorization: Bearer $KEY" | jq '.data[0]'

3‑D Secure

Si el banco del cliente pide verificación (3DS), la página de cobro muestra el reto dentro del mismo flujo y el pago continúa solo cuando el banco lo aprueba. Tu integración no tiene que hacer nada distinto: el resultado te llega igual por webhook o por GET /v1/payments.

Cuentas de prueba

Puedes crear cuantas cuentas de comercio quieras desde /signup para probar el onboarding completo. Una cuenta sin verificación aprobada puede usar toda la API de lectura, pero los endpoints que cobran responden 403 activation_required.

← Errores y paginación Integrar con un agente de IA →