# Modo prueba

Con tu **llave de prueba** (`sk_test_…`) haces el ciclo completo sin mover dinero: creas cobros, los pagas, te llegan los webhooks firmados y los ves en tu portal.

## Cómo se paga un cobro de prueba

Abre su `url`: la página muestra **"Modo prueba"**. Llénala con datos de ejemplo:

| Campo | Ejemplo |
|---|---|
| Banco | Cualquiera de la lista |
| Teléfono | `0414` + `1234567` |
| Cédula | `V` + `12345678` |
| Clave de pago | Cualquier número de 8 dígitos, p. ej. `12345678` (o una de las claves de la tabla de abajo, para forzar un resultado) |

No se le pide nada a ningún banco ni llega ningún mensaje: con una clave cualquiera el pago se aprueba y el cobro pasa a `pagado`.

## Forzar un resultado

El modo prueba te deja provocar los casos difíciles para que pruebes tu manejo de cada uno. Sólo funciona en cobros creados con una llave `sk_test_…`; en un cobro de producción estas claves no hacen nada especial (se tratan como cualquier clave y las valida el banco).

### Con la clave de pago

En el paso de la clave, escribe una de estas para provocar cada desenlace. Cualquier otra clave de 8 dígitos aprueba. El **monto** y el banco elegido no cambian el resultado: lo decide sólo la clave.

| Clave de pago | Desenlace | Qué ves | Qué te llega |
|---|---|---|---|
| Cualquier otra de 8 dígitos | **Aprobado** | El cobro pasa a `pagado` y la página muestra el comprobante. | `link.pagado` |
| `11111111` | **Rechazado** (rechazo genérico) | El cobro sigue `pendiente`, la página muestra el rechazo y tu cliente puede intentarlo con otra clave. | Nada |
| `11111112` | **Rechazado por fondos** | Igual que el anterior, con el aviso "Saldo insuficiente". Motivo `SALDO_INSUFICIENTE`. | Nada |
| `11111113` | **Rechazado por clave inválida** | Igual, con el aviso "La clave de pago no es válida". Motivo `OTP_INVALIDO`. | Nada |
| `11111114` | **Banco no disponible** | Igual, con el aviso "El banco no está disponible en este momento". Motivo `BANCO_NO_DISPONIBLE`. | Nada |
| `22222222` | **Pendiente y luego aprueba** | El pago queda `procesando`. A los 30 segundos más o menos pasa solo a `pagado`. Mientras tanto no se puede volver a pagar. | `link.pagado`, recién a los 30 s |
| `33333333` | **Tarda en confirmar** | La página se queda en "Procesando tu pago" unos 8 segundos y luego aprueba. | `link.pagado`, al aprobar |

En producción, según el banco de quien paga, un pago puede pasar primero por `procesando` y `link.pagado` llega cuando el banco lo confirma. En modo prueba, "Cualquier otra" aprueba en el acto; para probar cómo maneja tu sistema la espera, usa `22222222`.

Los rechazos siguen el mismo camino que un rechazo real del banco: el cobro se libera, el intento queda registrado como rechazado y no sale ningún webhook (un cobro rechazado no tiene aviso). Las dos formas de aprobar sí disparan los mismos webhooks que en producción, con `"mode": "test"`.

**Solo funcionan en modo prueba.** Se aplican únicamente a un cobro creado con una llave `sk_test_…`. Con una llave `sk_live_…`, y en cualquier cobro de producción, estas claves no hacen nada especial: se tratan como cualquier clave y las valida el banco. Ninguna llave ni dato de la petición puede encenderlas: lo decide el modo con que se creó el cobro, y ese modo no cambia.

### Sin abrir la página: `POST /links/:id/simular`

Para que tu servidor maneje un cobro de punta a punta sin abrir la página de pago:

```bash
curl -s -X POST https://pay.pagaconquickpay.com/switch/v1/links/<id>/simular \
  -H "x-switch-key: $QP_TEST_KEY" -H "content-type: application/json" \
  -d '{ "resultado": "pagado" }'
```

| `resultado` | Qué hace | Respuesta |
|---|---|---|
| `pagado` | Marca el cobro `pagado` y dispara los mismos avisos que un pago real. Te llega `link.pagado` (con `"referencia": "SIMULADO"`). Si tu comercio tiene liquidación inmediata activa, también te llega un `link.acreditado` simulado. | `200` con `"estado": "pagado"` |
| `rechazado` | Simula que el banco rechazó: el cobro queda `pendiente`, sin cambios y sin webhook. Sirve para confirmar que tu sistema sigue esperando. | `200` con `"estado": "pendiente"` |
| `expirado` | Vence el cobro al instante (`expirado`). | `200` con `"estado": "expirado"` |

La respuesta incluye `"simulado": true`. Si el cobro no es de prueba, recibes `403` (`solo_modo_prueba`). Si ya no está `pendiente` (o está vencido por tiempo), `409` (`no_simulable`). Un cobro en `procesando` por la clave `22222222` se puede adelantar con `pagado`.

Todos los avisos de prueba traen `"mode": "test"` dentro de `data`. → [Webhooks](/developers/webhooks-referencia)

## Qué pasa igual que en producción

- Los estados del cobro y su consulta (`GET /links/:id`).
- El webhook `link.pagado`, firmado igual que en producción, con `"mode": "test"`.
- El cobro aparece en tu portal marcado como prueba.

## Lo que el modo prueba no hace

- **No cobra dinero ni consulta a ningún banco.** La referencia de un pago de prueba es `SIMULADO`.
- **No simula todos los rechazos del banco** (cuenta bloqueada, por ejemplo): sólo los de la tabla de arriba. Los estados exactos que puede devolver un cobro real están en [Estados de un cobro](/developers/ciclo-de-vida).

> **Un cobro de prueba nunca se vuelve real**, aunque lo abra alguien de verdad con su clave del banco. Y uno de producción nunca es de prueba: no mezcles llaves en el mismo pedido.

## Si algo no funciona en producción

La [página de estado](/estado) muestra si el servicio y los cobros con débito inmediato están operativos, y los incidentes recientes. Los mismos datos están en [`/estado.json`](/estado.json), sin llave.