BE-05 Checkout y puerto PaymentGateway

BE-05 — Checkout y puerto PaymentGateway

• Depende de: BE-04, US-05, ADR-05, DS-02.
• Módulo: checkout (hexagonal), inventory, orders.

Objetivo

Orquestar el checkout: validar stock, reservar y crear la intención de pago vía el puerto PaymentGateway.

Alcance

• Puerto de salida PaymentGateway (createPayment). confirm y refund siguen en BE-06.
• Adaptador Mercado Pago (Checkout Pro / preferencia) detras del puerto. Stripe no se importa en dominio ni application.
• Caso de uso CreatePaymentIntentUseCase con header Idempotency-Key persistido en payments.idempotency_key.
• Reserva de stock (FOR UPDATE) antes de llamar a la pasarela; compensación si la pasarela o el save del pago fallan.
• Tras un intent exitoso el carrito pasa a CONVERTED y deja de ser reutilizable.
• Moneda tomada de stores.currency (no hardcodeada).
• Tenant: el claim JWT storeId manda; X-Store-Id distinto → 403 (BE-09).

Criterios de aceptación

• Sin stock = 409 ProblemDetail antes de crear el pago.
• Carrito vacío o inactivo = 422 ProblemDetail.
• payments.provider_reference único; replay con la misma Idempotency-Key no duplica orden ni reserva.
• El dominio no importa SDKs de pasarela.

Evidencia

• Unitarias con doble del puerto: CreatePaymentIntentUseCaseTest (vacío, idempotencia, 409 de stock, happy path + markConverted).
• Adaptador MP en sandbox con token mock (TEST-mock-access-token) sin red.
• Esquema: Flyway V2__checkout_tenant_defaults.sql (idempotency_key, default MERCADO_PAGO / PEN).

Fuera de este nodo

Webhooks, pago SUCCEEDED/FAILED y reserva CONFIRMED/liberada: BE-06 (DONE). Orden a PAID y API de lectura: BE-07. Relay del outbox: BE-12. Ajuste admin de inventario: BE-08 / US-07.