Skip to main content
Usa este flujo para iniciar pagos ecommerce con PagoEfectivo desde el API de autorización de PayIn.
POST /charges
endpoint
Este flujo utiliza el mismo endpoint base de autorización. Revisa los ambientes y la configuración general en el Overview.

Características del flujo

Tipo de flujo

Asíncrono.

Método de pago

Permite iniciar cobros ecommerce con PagoEfectivo.

Código de pago

El API devuelve un CIP y una URL de pago para que el usuario complete la operación fuera del checkout.

Validación final

El resultado final debe confirmarse por backend con notificación o consulta.

Consideraciones

Este flujo requiere redirect_url para retornar al comercio cuando finalice la autorización y permite enviar callback_url para notificación host to host.
El usuario puede completar el pago después de la sesión inicial usando el CIP o la URL generada por PagoEfectivo. Complementa este flujo con Notificaciones o con Consulta.
No tomes como final la respuesta inicial del POST /charges. Generar el CIP no equivale a recibir el pago. Confirma el resultado con Notificaciones o con Consulta.

Request

Antes de consumir este endpoint, solicita tu Access Token en Autenticación.

Headers


Body

Objeto raíz del request


Objeto payment_method


Objeto payment_method.method_details

redirect_url debe apuntar a una ruta de tu comercio preparada para recibir el retorno del usuario. Si envías callback_url, asegúrate de que sea accesible desde backend.

Objeto payment_details

Para billing, shipping y customer, usa la estructura ecommerce estándar con first_name, last_name, email, phone y location.

Ejemplo de request


Response

La respuesta inicial normalmente deja la transacción en seguimiento. Confirma el resultado final con notificaciones o con consulta antes de actualizar la orden.

Objeto transaction

state puede devolver valores como PENDIENTE o INVALIDO. Cuando el CIP fue generado correctamente, la transacción normalmente queda en PENDIENTE hasta que el usuario complete el pago o expire.
No uses meta.status.code como validador de autorización o denegación del pago. Ese código solo indica si el servicio procesó o respondió correctamente; el resultado del pago se valida con transaction.state y, como respaldo, desde backend con consulta o notificación.

Objeto transaction.payment_method


Objeto transaction.payment_method.method_details


Objeto transaction.expiration_date


Objeto transaction.processor_response


Objeto transaction.processor_response.result_message


Objeto transaction.lifecycle

En lifecycle puedes recibir estados como REGISTRADO, PENDIENTE e INVALIDO.

Objeto transaction.lifecycle[].date


Ejemplo de response


Buenas prácticas

  • Confirma el resultado final por backend antes de actualizar la orden.
  • Asegúrate de enviar un merchant_operation_number único por transacción.
  • No asumas que un CIP generado significa pago completado; interpreta PENDIENTE como un estado intermedio.
  • Usa callback_url si tu operación necesita confirmación server to server.
  • Conserva transaction_id, merchant_operation_number, cip, cip_url y la fecha de expiración para seguimiento, soporte y conciliación.

Errores comunes

Pago asumido como exitoso

Generar el CIP no equivale a recibir el pago. El usuario todavía debe completar el abono en el canal habilitado por PagoEfectivo.

CIP expirado

Si el usuario intenta pagar después de expiration_date, deberás generar una nueva operación en lugar de reutilizar la anterior.

Siguiente paso

Api de Consulta con PagoEfectivo

Verifica cómo consultar una operación iniciada con PagoEfectivo.