Reserva temporária
A vaga fica retida exatamente pelo tempo configurado por produto enquanto o cliente completa o pagamento no Stripe, sem bloquear estoque por carrinhos que nunca chegam até essa parte.
Checkout e pagamentos
Reservado enquanto decidem. Liberado assim que não decidem.
Um pagamento pendente nunca bloqueia uma vaga para sempre, e nunca a libera cedo demais. Se o pagamento nunca chega, ela se libera sozinha, por três caminhos diferentes ao mesmo tempo, para nunca depender de que só um deles funcione.
- 3 mecanismos Um job agendado para o instante exato, uma varredura a cada minuto, e uma limpeza se o próprio início do pagamento falhar
- 2 camadas de idempotência Um evento duplicado do Stripe nunca cobra duas vezes, nunca emite ingressos duas vezes, nem corrompe o pedido
- Reembolso automático Se um pagamento chega atrasado e a vaga já foi para outra pessoa, ele é cobrado, detectado e reembolsado sozinho
Quatro peças do checkout.
Cada uma resolve uma forma diferente de receber, sem duplicar regras de negócio.
Retenção opcional por produto
Alguns produtos aceitam um risco mínimo de overbooking em troca de simplicidade, sem nenhuma retenção temporária. Um mesmo pedido pode misturar linhas com e sem retenção sem problema algum.
Checkout sem conta
Um comprador anônimo pode pagar diretamente quando a organização permite, ou o canal pode ser obrigado a passar pelo seu próprio servidor com uma chave.
Links de pagamento manuais
Um agente pode gerar um link do Stripe pelo painel e enviá-lo por WhatsApp ou e-mail, para vendas por telefone ou redes sociais, sem checkout próprio.
Como um pagamento é protegido, passo a passo
Cinco passos, desde o momento em que a vaga é retida até o pedido ficar pago ou reembolsado.
- 1
A vaga é retida
O pedido nasce pendente de pagamento, com seu próprio prazo de expiração, e retém capacidade ou estoque antes mesmo de criar a sessão do Stripe. Nada é confirmado ainda.
- 2
A sessão de pagamento é criada
A chamada ao Stripe acontece fora da transação do banco de dados: uma API externa nunca deve manter um bloqueio de linha aberto enquanto espera resposta.
- 3
O webhook confirma, sob bloqueio
Quando o Stripe avisa que o pagamento teve sucesso, a linha do pedido é bloqueada e verificada de novo para ver se ainda está pendente, fechando a janela onde duas entregas do mesmo evento poderiam competir.
- 4
A retenção vira venda
Se o pedido ainda está pendente, a retenção é confirmada, os ingressos são emitidos, e o pedido vira pago, tudo dentro da mesma transação.
- 5
Se chegou atrasado, é reembolsado
Se o pedido já não estava pendente (expirou, foi cancelado, ou a vaga já não existe), o pagamento é reembolsado automaticamente, com o motivo registrado para o suporte revisar.
O que o checkout realmente retorna
O pedido com seu status, seu prazo de expiração e o total já calculado, junto com a URL de pagamento do Stripe. O cliente nunca vê um checkout próprio pela metade.
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 Sessão de pagamento criada
Um pagamento atrasado sempre encontra tudo já fechado
Liberar uma retenção vencida também cancela qualquer transação de pagamento que ainda estivesse aberta para aquele pedido. Então, quando um webhook de pagamento bem-sucedido chega depois que a vaga expirou, ele nunca encontra uma transação "pendente" esperando: encontra uma já cancelada, e o reembolso automático parte exatamente daí, como o caminho normal, não como uma exceção rara.
Perguntas frequentes
Nada se duplica. Existe uma verificação rápida no início para eventos já processados, e uma segunda verificação dentro do mesmo bloqueio da linha do pedido, fechando a janela onde duas entregas verdadeiramente simultâneas do mesmo evento poderiam competir. Só uma vence.
Ele é cobrado, o conflito é detectado, e é reembolsado automaticamente, com o motivo registrado para o suporte revisar. Nunca se emite um ingresso para uma vaga que já foi para outra pessoa.
Não. Um produto pode aceitar um risco mínimo de overbooking em troca de nunca bloquear uma vaga enquanto alguém decide se vai pagar. Um mesmo pedido pode misturar linhas com e sem retenção sem nenhum conflito.
Sim, se a organização permitir isso para sua loja. Também é possível exigir que a chamada passe pelo próprio servidor da organização com uma chave, para evitar expor o checkout diretamente ao navegador.
Por três caminhos ao mesmo tempo: um job agendado para o instante exato da expiração, uma varredura de backup que verifica todo pedido vencido a cada minuto, e uma limpeza automática se algo falha ao iniciar o pagamento. Qualquer um dos três é suficiente, e nenhum deles pode liberar a mesma vaga duas vezes.
Mais reservas. Mais canais. A mesma calma.
A Tiqory mantém disponibilidade, preços, pagamentos e acesso a trabalhar juntos enquanto a sua operação cresce. Conte-nos para onde vai; mostramos como chegar lá sem recomeçar.