Ir al contenido

Simular pagos en prueba

En modo prueba nadie paga de verdad: tú decides cómo termina cada cobro con una llamada a la API o desde el panel.

Un cobro creado con kuti_test_… se queda esperando el pago. Para probar tu integración de punta a punta (pantalla de gracias, webhooks, conciliación) simula el resultado: el cobro cambia de estado y recibes los mismos eventos que con un pago real.

Los simuladores solo aceptan claves de prueba (kuti_test_…). Con una clave de producción responden 403 TEST_MODE_REQUIRED, y un cobro de producción nunca se puede simular.

Simular el pago de un cobro

  1. 1

    Crea el cobro

    POST /payment-intents o POST /checkout-sessions con tu clave de prueba. Guarda el id (pi_…).

  2. 2

    Simula el resultado

    POST /payment-intents/{id}/simulate con outcome (SUCCEEDED o FAILED) y, si el cobro ofrece varios métodos, payment_method_type con el método con el que pagó el cliente.

  3. 3

    Verifica

    La respuesta trae el cobro actualizado y a tu webhook llega payment.succeeded (o payment.failed).

El cliente pagóbash
curl -s -X POST https://api.kuti.pe/v1/payment-intents/pi_01J8Z3K4M5N6P7Q8R9S0T1U2V3/simulate \
  -H 'Authorization: Bearer kuti_test_…' \
  -H 'Content-Type: application/json' \
  -d '{ "outcome": "SUCCEEDED" }'
El pago fue rechazadobash
curl -s -X POST https://api.kuti.pe/v1/payment-intents/pi_01J8Z3K4M5N6P7Q8R9S0T1U2V3/simulate \
  -H 'Authorization: Bearer kuti_test_…' \
  -H 'Content-Type: application/json' \
  -d '{ "outcome": "FAILED" }'

Con qué método pagó

payment_method_type dice con cuál de los métodos del cobro pagó el cliente. Tiene que ser uno de los que el cobro ofrece (su payment_method_types): si envías otro, responde 422.

El cobro ofrecepayment_method_type
Un solo métodoOpcional: se usa ese.
INTEROPERABLE_QR y BANK_TRANSFERObligatorio: INTEROPERABLE_QR o BANK_TRANSFER. Sin él responde 422.
YAPE (Yape afiliado)No va aquí: usa /payment-intents/{id}/simulate/yape (más abajo).
El cliente pagó por bancobash
curl -s -X POST https://api.kuti.pe/v1/payment-intents/pi_01J8Z3K4M5N6P7Q8R9S0T1U2V3/simulate \
  -H 'Authorization: Bearer kuti_test_…' \
  -H 'Content-Type: application/json' \
  -d '{
    "outcome": "SUCCEEDED",
    "payment_method_type": "BANK_TRANSFER"
  }'

El cobro queda pagado con ese método: lo ves en paid_with.method_type de la respuesta y del evento payment.succeeded.

Desde el panel

Con el panel en Modo prueba, abre el cobro en Cobros y usa Simular pago. Hace lo mismo que la llamada a la API.

Pruébalo en el demo

demo.kuti.pe usa estos mismos simuladores: creas un cobro en una tienda de ejemplo, pulsas Simular pago exitoso o rechazado y ves la llamada a la API con su respuesta. Solo necesitas tu clave de prueba.

Yape afiliado, suscripciones y reembolsos

En modo prueba no hay app de Yape: tú simulas lo que haría el cliente y cómo responde el débito. Cada simulador tiene un GET (estado actual) y un POST (simular).

Qué simulasEndpointBodyPermiso
Yape afiliado en un cobro/payment-intents/{id}/simulate/yapeaffiliation: APPROVE · REJECT · EXPIRE; payment: SUCCEED · INSUFFICIENT_FUNDS · REVOKED · PENDING · ERROR; settle: COMPLETE · DENYpayment_intents
Afiliación de una suscripción/subscriptions/{id}/simulate/yapeLos mismos campos que en un cobrosubscriptions
Reembolsos de un cobro/payment-intents/{id}/simulate/refundsnext_outcome: SUCCEED · PENDING · DENY; settle: { refund_id, result: COMPLETE · DENY }refunds
El cliente aprueba su Yape en una suscripciónbash
curl -s -X POST https://api.kuti.pe/v1/subscriptions/sub_01J8Z3K4M5N6P7Q8R9S0T1U2V3/simulate/yape \
  -H 'Authorization: Bearer kuti_test_…' \
  -H 'Content-Type: application/json' \
  -d '{ "affiliation": "APPROVE" }'
El GET pide el permiso de lectura del recurso (p. ej. subscriptions:read) y el POST el de escritura (subscriptions:write). Una clave de solo lectura no puede simular.

Siguiente