Reserva temporal
El cupo se retiene exactamente el tiempo configurado por producto mientras el cliente completa el pago en Stripe, sin bloquear inventario por carritos que nunca llegan a esa parte.
Checkout y pagos
Retenido mientras deciden. Liberado en cuanto no lo hacen.
Un pago pendiente nunca bloquea el cupo para siempre, y nunca lo suelta demasiado pronto. Si el pago nunca llega, se libera solo, por tres caminos distintos a la vez, para que nunca dependa de que uno solo funcione.
- 3 mecanismos Job programado para el instante exacto, barrido cada minuto, y limpieza si falla el propio inicio del pago
- 2 capas de idempotencia Un evento de Stripe duplicado nunca cobra, nunca emite tickets ni corrompe el pedido dos veces
- Reembolso automático Si el pago llega tarde y el cupo ya se fue a otra persona, se cobra, se detecta y se reembolsa solo
Cuatro piezas del checkout.
Cada una resuelve una forma distinta de cobrar, sin duplicar reglas de negocio.
Hold opcional por producto
Algunos productos aceptan un riesgo mínimo de sobreventa a cambio de simplicidad, sin retención temporal. Un mismo pedido puede mezclar líneas con y sin retención sin ningún problema.
Checkout sin cuenta
Un comprador anónimo puede pagar directamente cuando la organización lo habilita, o exigir que el canal pase por su propio servidor con una clave.
Enlaces de pago manuales
Un agente puede generar un enlace de Stripe desde el panel y enviarlo por WhatsApp o correo, para ventas telefónicas o por redes, sin checkout propio.
Así se protege un pago, paso a paso
Cinco pasos, desde que se retiene el cupo hasta que el pedido queda pagado o reembolsado.
- 1
Se retiene el cupo
El pedido nace en estado pendiente de pago, con su propia fecha de expiración, y retiene capacidad o stock antes de crear la sesión de Stripe. Nada se confirma todavía.
- 2
Se crea la sesión de pago
La llamada a Stripe ocurre fuera de la transacción de base de datos: una API externa nunca debe mantener un bloqueo de fila abierto mientras espera respuesta.
- 3
El webhook confirma, bajo bloqueo
Cuando Stripe avisa que el pago tuvo éxito, se bloquea la fila del pedido y se revisa de nuevo si sigue pendiente, para cerrar la ventana donde dos entregas del mismo evento podrían competir.
- 4
La retención se vuelve venta
Si el pedido sigue pendiente, la retención se confirma, se emiten los tickets y el pedido pasa a pagado, todo dentro de la misma transacción.
- 5
Si llegó tarde, se reembolsa
Si el pedido ya no estaba pendiente (expiró, se canceló, o el cupo ya no existe), el pago se reembolsa automáticamente, con el motivo registrado para que soporte lo revise.
Lo que responde el checkout
El pedido con su estado, su fecha de expiración y el total ya calculado, junto con la URL de pago de Stripe. El cliente nunca ve un checkout propio a medio construir.
POST /api/v1/checkout
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
{
"order": {
"code": "01J8X8QK6Z9K2R3W4M5N6P7Q8R",
"status": "pending_payment",
"hold_expires_at": "2026-08-14T18:15:00Z",
"currency": "EUR",
"grand_total_amount": 53.24
},
"checkout_url": "https://checkout.stripe.com/c/pay/cs_live_..."
}200 Sesión de pago creada
Un pago que llega tarde ya encuentra todo cerrado
Liberar una retención vencida también cancela cualquier transacción de pago que seguía abierta para ese pedido. Así que cuando un webhook de pago exitoso llega después de que el cupo expiró, nunca encuentra una transacción "pendiente" esperando: encuentra una ya cancelada, y el reembolso automático parte exactamente de ahí, como el camino normal, no como una excepción rara.
Preguntas frecuentes
Nada se duplica. Hay una verificación rápida al inicio para eventos ya procesados, y una segunda comprobación dentro del mismo bloqueo de la fila del pedido, para cerrar la ventana donde dos entregas verdaderamente simultáneas del mismo evento podrían competir. Solo una gana.
Se cobra, se detecta el conflicto y se reembolsa automáticamente, con el motivo registrado para que soporte pueda revisarlo. Nunca se emite un ticket para un cupo que ya se le dio a otra persona.
No. Un producto puede aceptar un riesgo mínimo de sobreventa a cambio de nunca bloquear un cupo mientras alguien decide si paga. Un mismo pedido puede mezclar líneas con y sin retención sin ningún conflicto.
Sí, si la organización lo permite para su tienda. También puede exigirse que la llamada pase por un servidor propio con una clave, para evitar exponer el checkout directamente al navegador.
Por tres caminos a la vez: un trabajo programado para el instante exacto de expiración, un barrido de respaldo que revisa cada minuto todos los pedidos vencidos, y una limpieza automática si algo falla al iniciar el pago. Cualquiera de los tres es suficiente, y ninguno puede liberar el mismo cupo dos veces.
Más reservas. Más canales. La misma calma.
Tiqory mantiene disponibilidad, precios, pagos y acceso trabajando juntos mientras tu operación crece. Cuéntanos hacia dónde vas; te mostramos cómo llegar sin volver a empezar.