Skip to main content
EL NUEVO MODELO DE PAGOS

Una compra.
Todos sus intentos.

La operación reúne el contexto de la compra. Las transacciones cuentan qué ocurrió cada vez que el cliente intentó pagar.

​
El cambio de enfoque

En Pay-me, no debes leer cada transacción como si fuera una venta independiente. El modelo tiene dos niveles: Una operación puede tener varias transacciones. Una transacción pertenece al contexto de una operación. Cambiar de método o reintentar no convierte, por sí solo, la compra en otro pedido.
“Sesión de compra” describe el contexto comercial. No significa que su vigencia sea idéntica a la de la pestaña del navegador, un token o un temporizador local. Respeta las condiciones de vigencia y reintento de tu integración.

​
Los nombres de estado se leen en dos niveles

Operación y transacción utilizan los mismos nombres de estado, pero describen recursos distintos. Por eso no basta con decir “está denegado”: debes precisar si hablas de la operación o de un intento. Los estados actuales son Registrado, Pendiente, Autorizado, Inválido, Denegado, Extornado, Liquidado, Expirado y Cancelado. El estado global de la operación y el de cada transacción deben conservarse por separado. Abonado y Devuelto están previstos, pero todavía no están disponibles. No los uses como condiciones obligatorias de tu integración.

​
Mira cómo se conserva una misma compra

Avanza por el ejemplo: dos intentos se rechazan y el tercero se autoriza. La operación y el pedido se mantienen; lo que crece es el historial de transacciones. La lectura correcta al terminar es una compra de S/ 50.00 con tres intentos, uno de ellos autorizado. No sumes los importes de los tres intentos como si fueran S/ 150.00 vendidos.

​
Qué cambia para tu integración

Tu tienda conserva el pedido

Relaciona la compra con su operación. No crees otro pedido únicamente porque un intento fue rechazado.

Cada intento conserva su identidad

Guarda cada transaction_id y su resultado. No sobrescribas el intento anterior al registrar el siguiente.

Soporte ve el recorrido

Distingue qué método se usó en cada intento, qué respuesta recibió y cuál terminó autorizado.

La conciliación separa niveles

Cuenta las compras por su contexto de operación y analiza autorizaciones, rechazos y ajustes por transacción.
Un intento pendiente no es un intento rechazado. Ante un timeout, un QR o un CIP pendiente, consulta su resultado antes de promover otro cobro. No asumas que Pay-me canceló los demás intentos ni que evita automáticamente cualquier duplicidad.

​
Cómo reconocer ambos niveles en la API

En la consulta de transacción, la respuesta contiene una estructura operation y una colección transactions.
Dos listas distintas: transactions[] agrupa transacciones; lifecycle[] agrupa eventos de una transacción. Que un intento pase por registrado, pendiente y autorizado no significa que existan tres intentos.
La consulta documentada recibe merchant_code, merchant_operation_number y transaction_id. No supongas que una consulta filtrada por transacción devuelve necesariamente todo el historial de la operación.

​
Ejemplo de estructura

Fragmento simplificado basado en la consulta documentada. Los identificadores son ilustrativos; no es un request para copiar ni el catálogo completo de estados.
Aquí hay una operación y una transacción con tres eventos, no tres transacciones. En este contrato, el importe 15000 está expresado en centavos: equivale a S/ 150.00 con moneda 604 (PEN).

​
Reglas para implementar sin confusiones

  1. Relaciona pedido y operación. Conserva sus identificadores por separado; no presupongas que tienen el mismo formato.
  2. Registra cada intento. Guarda transaction_id, método, estado y referencias necesarias para soporte.
  3. No deduzcas el pago de la interfaz. Cerrar el checkout o recibir un callback no demuestra por sí mismo una aprobación.
  4. Confirma desde el backend. Comprueba la operación, el intento, importe y moneda mediante la consulta o notificación correspondiente.
  5. Aplica cambios de forma idempotente. Una notificación repetida o una consulta reiterada no deben duplicar la entrega ni volver a registrar la misma venta.
  6. Conserva el historial. Un extorno o una devolución posterior no elimina la transacción que originó el pago.
Mantener una operación para la misma compra no significa reenviar a ciegas la misma petición HTTP. Las reglas de reintento, expiración e idempotencia técnica dependen del endpoint y del canal utilizado.

​
Comprueba que tu equipo lo entendió

En el ejemplo hay una compra, una operación y tres transacciones. Solo una transacción terminó autorizada.
No. Es una sola transacción que cambió de estado tres veces. Sus eventos comparten el mismo transaction_id.
No lo determines solo con ese dato. Revisa el estado de la operación y el contexto de sus intentos. No sobrescribas una compra ya confirmada con el rechazo de otro intento.

Continúa: estados de transacción

Aprende qué significa cada resultado y qué debe hacer tu integración.