Skip to main content
Usa este flujo para generar una operación QR desde el API de autorización de PayIn y entregar el QR en la misma respuesta para que el usuario complete el pago desde su app bancaria o billetera compatible.
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 generar un código QR para que el usuario complete el pago desde su app bancaria o billetera compatible.

Generación del QR

El API devuelve la imagen del QR en base 64 dentro de transaction.processor_response.qr_image.

Validación final

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

Consideraciones

Este flujo permite enviar callback_url para recibir una notificación host to host cuando el estado de la operación cambie.
QR no utiliza redirect_url ni retorno del navegador al comercio. El código QR se obtiene en la respuesta inicial del POST /charges.
Aunque el QR se genera en la respuesta inicial, la confirmación final del pago sigue la misma lógica operativa de los métodos asíncronos. Complementa este flujo con Notificaciones o con Consulta.
No marques la orden como pagada solo porque el QR fue generado correctamente. Confirma siempre el estado final 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

Si envías callback_url, asegúrate de que sea una URL backend accesible para recibir confirmaciones server to server.

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

Objeto transaction

state puede devolver valores como PENDIENTE o INVALIDO. Cuando el QR fue generado correctamente, la transacción normalmente queda en PENDIENTE hasta que el pago sea completado 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 QR 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, qr_id y la fecha de expiración para seguimiento, soporte y conciliación.

Errores comunes

Pago asumido como exitoso

Generar el QR no equivale a autorizar el pago. El usuario todavía debe escanearlo y completar la operación.

QR 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 QR

Aprende a consultar el estado actualizado de una operación QR.