Documentación
Cómo integrar Paygumi para cobrar suscripciones con tu cuenta de Wompi y decidir el acceso de tus usuarios.
Paygumi es un motor de cobros recurrentes sobre Wompi. Tu plataforma conecta su propia cuenta de Wompi, crea planes y envía a sus usuarios a una página de pago; Paygumi cobra cada periodo, reintenta los pagos rechazados y te avisa por webhook firmado qué acceso debe tener cada usuario.
Cómo encajan las piezas
| Concepto | Qué es |
|---|---|
Cliente (cus_…) | El usuario de tu sistema que paga. Lo identificas con tu propio id en external_id. |
Plan (pln_…) | Precio fijo en COP por periodo mensual, con días de prueba opcionales. Se crea en el panel. |
Sesión de checkout (cs_…) | Enlace de un solo uso a la página de pago, donde tu cliente registra su tarjeta y, si quieres, se suscribe. |
Suscripción (sub_…) | El cliente suscrito a un plan. Tiene un estado y un access_status. |
Cobro (chg_…) | El cobro de un periodo, con sus intentos en Wompi. |
Evento (evt_…) | Lo que te enviamos por webhook cuando algo cambia. |
El flujo en cinco pasos
- Tu backend crea una sesión de checkout con tu API key y redirige a tu usuario a la
urlque recibe. - Tu usuario escribe su tarjeta en
checkout.paygumi.com. La tarjeta va del navegador directo a Wompi; ni tu servidor ni Paygumi la ven. - Paygumi registra la tarjeta, crea la suscripción y procesa el primer cobro.
- Recibes los webhooks
checkout_session.completedypayment.approved(opayment.declined). - Con el campo
access_statusde cada evento decides si tu usuario tiene acceso. Ver suscripciones y estados de acceso.
Por dónde empezar
- Primeros pasos: API keys, sandbox y producción, y tu primera petición.
- Referencia de la API: todas las rutas públicas, con parámetros, respuestas y errores.
- Portal del cliente: que tus usuarios gestionen su suscripción sin que construyas pantallas.
- Idempotencia y errores: cómo reintentar sin cobrar dos veces y cómo leer los errores.