Flujo de pago

Tu servidor ──POST /checkout-sessions──▶ GC API ──devuelve checkout_url──▶

Cliente ──visita checkout_url──▶ Página de pago de GC
  │
  ├── Selecciona método de pago
  ├── Ingresa datos de tarjeta
  ├── Autenticación 3DS (si aplica)
  │
  ├── Éxito ──redirige──▶ success_url
  └── Falla ──redirige──▶ failure_url

Tu servidor ──GET /checkout-sessions/{id}──▶ Verifica estado (servidor a servidor)

GC ──POST webhook──▶ Tu endpoint webhook (confirmación autoritativa)

Las dos fuentes de verdad

Un pago tiene dos confirmaciones sobre las que puedes actuar:

1. Redirección del cliente a success_url o failure_url. Útil para UX (mostrar "Gracias por tu pedido"), pero no autoritativa — el cliente puede cerrar el navegador antes de la redirección, la red puede fallar, y la URL no contiene datos de pago.
2. Entrega del webhook a tu endpoint registrado. Autoritativa — se dispara cuando el gateway confirma. Reintentos con backoff en caso de fallo.

Qué hacer tras la redirección

GET /api/v1/checkout-sessions/{id}

Úsalo en el handler de redirección para renderizar la página de recibo o mostrar un intersticial "estamos confirmando tu pago". El estado de la sesión será completed si el pago se capturó.

Qué hacer en el webhook

Trata el webhook como la fuente de verdad para el cumplimiento, lógica de reembolsos y contabilidad. Aunque el cliente nunca vuelva a tu success_url, el webhook se disparará igualmente.

TIP

Haz que tu lógica de cumplimiento sea idempotente sobre transaction_id. El webhook puede reintentarse — tu código no debe cumplir dos veces.

Siguiente

• Webhooks — payload, verificación de firma, calendario de reintentos
• Manejo de errores — cómo se ven fallas y rechazos