410975f972900c1f0080f5b2333b3d92ad64b5a2
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  devopsandClaude Sonnet 5
|
c507da8abc |
feat(fulfillment): integrar EnvíoClick para cálculo real de envío
ADR 0009 §2 ya había anticipado esto: la shipping option actual es un placeholder de negocio ($15.000 COP fijo), no un cálculo real por peso/volumen -- y el modelo de direcciones del checkout (IDs DIVIPOLA en vez de texto libre en lib/data/colombia.ts) ya se había construido pensando en esta integración. Este commit la implementa. Investigación en vivo (no solo documentación -- misma disciplina que ya costó varios rehechos con las pasarelas de pago): la SPA de docs públicas (apidoc.envioclickpro.com.co) no renderiza sin sesión, pero está generada con apiDoc, así que se bajó y leyó directo su api_data.json/api_project.json (spec completa real), y se probó /quotation en vivo con la API key real del usuario -- 200 OK con tarifas reales de PIBOX/COORDINADORA/ENVIA/RAPPI/TCC. Esto corrigió varios datos mal asumidos de un plugin de WordPress desactualizado usado como referencia inicial (API v1): la URL base real es api.envioclickpro.com.co/api/v2 (no api.envioclickpro.com a secas), y el header de auth real es "Authorization" a secas, no "AuthorizationKey". Hallazgo crítico evitado leyendo el código fuente de @medusajs/utils/dist/common/define-config.js: defineConfig() ya registra por defecto un módulo de fulfillment con el provider manual_manual, aunque medusa-config.ts no lo mencione explícitamente -- pero transformModules() indexa por serviceName y el último que llega pisa al anterior (no mezcla providers). Agregar un bloque propio de fulfillment sin incluir también manual_manual ahí habría roto en silencio el envío manual que ya usa la shipping option existente. Verificado cargando la config compilada real: ambos providers quedan registrados juntos. - src/modules/envioclick-fulfillment/: AbstractFulfillmentProviderService. calculatePrice() cotiza en vivo durante el checkout -- Medusa advierte explícitamente que un error acá bloquea el checkout completo, así que NUNCA se deja propagar una excepción: cualquier falla (red, dirección sin id DIVIPOLA, EnvíoClick caído) cae al precio fijo de $15.000 que ya se usaba, para no romper la compra. createFulfillment() vuelve a cotizar en el momento de generar la guía real en vez de reusar el idRate mostrado en checkout (más correcto: CalculatedShippingOptionPrice no tiene forma de persistir ese id entre llamadas, confirmado leyendo el tipo real, y un idRate viejo podría estar vencido si el fulfillment pasa horas/días después). cancelFulfillment() sí cancela de verdad (cancellation/batch/order existe y está confirmado, a diferencia del refund de ePayco que quedó sin implementar). - Solo 1 paquete por cotización/guía (límite real de la API, confirmado: "min 1, max 1") -- el carrito se agrega a un solo paquete. Como hoy NINGÚN producto tiene peso/dimensiones cargados (confirmado en vivo: 18 productos activos, 0 con weight), se usa un paquete de fallback conservador completo en vez de mezclar datos reales con inventados a medias -- la cotización no va a ser precisa hasta que se carguen esos datos (tarea de datos, no de código, fuera de alcance de este commit). - Frontend: cambio chico pero necesario en checkout-client.tsx/ medusa-cart.ts -- el checkout mandaba el nombre de la ciudad a Medusa, nunca el id DIVIPOLA (aunque el form sí lo tenía disponible). Hay municipios con el mismo nombre en distintos departamentos de Colombia, así que el nombre solo no alcanza para identificar la ciudad sin ambigüedad -- se guarda el id real en la metadata de la dirección (Medusa sí tiene ese campo), que el fulfillment provider lee para derivar el código DANE real que pide EnvíoClick (5 dígitos + "000" de relleno, confirmado contra su propio ejemplo: "11001000" = Bogotá). Pendiente de verificar con una llamada real (no se quiso generar una guía de prueba en la cuenta real del usuario sin avisar): /shipment_sandbox y cancellation/batch/order, verificados contra la spec oficial real pero no probados en vivo todavía. Co-Authored-By: Claude Sonnet 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01THZFwPzrwv6VAbuwmaf5vR |
||
|
devopsandClaude Sonnet 5
|
2ceea23f40 |
feat(payments): integrar PayU LatAm (PSE) como pasarela de pagos
ADR 0009 ya había decidido PayU LatAm como proveedor (única opción que no exige cuenta Bancolombia/Nequi) y confirmado que no existe ningún plugin real de Medusa para su API -- los paquetes que aparecen buscando "PayU" son para PayU Polonia/CEE, API completamente distinta (clientId/posId/secondKey vs. apiLogin/apiKey/merchantId/accountId). Este commit implementa esa decisión: módulo de pago custom (AbstractPaymentProvider) para PSE (transferencia bancaria), primer alcance del método de pago -- Nequi/Daviplata quedan fuera por ahora. Backend (commerce-backend): - src/modules/payu-pse/: initiatePayment arma y postea SUBMIT_TRANSACTION contra la API real de PayU LatAm; authorizePayment devuelve "pending_authorization" (PSE es async, la confirmación real llega por webhook, no en el momento de completar el carrito); getWebhookActionAndData valida la firma MD5 del webhook antes de confiar en cualquier confirmación de pago -- falla cerrado si no matchea. refundPayment/ retrievePayment tiran error explícito en vez de simular éxito: esos endpoints de PayU no quedaron verificados en vivo y hay dinero real de por medio. - No hace falta un subscriber propio para completar la orden -- el subscriber nativo de Medusa (payment-webhook + process-payment-workflow) ya hace ese trabajo con los métodos de arriba bien implementados (confirmado leyendo el código fuente instalado de @medusajs/medusa 2.18.0, no la documentación). - Correlación webhook↔sesión: Medusa inyecta su propio session_id en `data` antes de initiatePayment; se usa ese mismo valor como referenceCode de PayU, así el reference_sale que vuelve en el webhook ya es directamente el session_id de Medusa. - src/lib/payu.ts: cliente HTTP + firmas (orden y webhook, fórmulas distintas, confirmadas contra el SDK PHP oficial de PayU). - src/api/store/payments/pse-banks/route.ts: lista de bancos PSE, cacheada en memoria. - medusa-config.ts, Dockerfile, configmap/secrets.template: 7 env vars nuevas (PAYU_API_LOGIN/API_KEY/MERCHANT_ID/ACCOUNT_ID/ENV/RESPONSE_URL/ NOTIFY_URL), dummies de build agregados, secrets con placeholder "CAMBIAR". Frontend (ecommerce): - Nuevo step "payment" en components/checkout/checkout-client.tsx (reemplaza al step "review" que solo ofrecía WhatsApp): selector de banco, tipo de persona (N/J), tipo/número de documento, botón "Pagar con PSE" que crea la sesión de pago, completa el carrito y redirige al banco (navegación completa, no iframe -- así lo exige PayU). WhatsApp queda como respaldo manual si falla la iniciación del pago. - lib/headless/providers/medusa-payment.ts + 3 rutas proxy nuevas bajo app/api/cart/, mismo patrón que el resto del carrito (medusaCartFetch, ahora exportado desde medusa-cart.ts). - app/checkout/pse/return/: página de vuelta del banco -- nunca afirma éxito, la confirmación real es el webhook async. Arranca contra las credenciales de sandbox genéricas y públicas de PayU (developers.payulatam.com) mientras el usuario termina su propio registro de comercio -- swap de las 4 credenciales via secret cuando estén listas, sin cambios de código. Verificado: build real de Medusa con las env vars dummy (no solo tsc), tipos de AbstractPaymentProvider/WebhookActionResult/PaymentActions confirmados contra @medusajs/utils y @medusajs/types instalados (node_modules limpiado después), typecheck + lint + build completo del frontend, páginas nuevas renderizando sin error. Pendiente: prueba end-to-end contra el sandbox real de PayU (necesita el backend desplegado) y habilitar el provider en la región Colombia desde el Admin. Co-Authored-By: Claude Sonnet 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01THZFwPzrwv6VAbuwmaf5vR |
||
|
devops
|
bb2c0bbe85 |
feat(ecommerce): ADR 0009 - checkout con direccion y seleccion de envio
Siguiente corte tras el carrito real: pagina /checkout de 3 pasos (direccion -> envio -> confirmar) contra el Store API real, usando la shipping option que ya se verifico en produccion. Endpoints nuevos (setShippingAddress, getShippingOptions, addShippingMethod) probados en vivo con un carrito de prueba real antes de escribir el codigo -- direccion, opciones de envio y total ya confirmados correctos (80.000 + 5.000 = 95.000). El pago (PayU custom) sigue sin existir, asi que el ultimo paso sigue siendo WhatsApp -- pero ahora el mensaje incluye direccion, metodo de envio y total real en vez de solo la lista de productos. El boton del CartDrawer pasa de abrir WhatsApp directo a llevar a /checkout. |
||
|
devops
|
b8ce9ded87 |
fix(ecommerce): carrito muestra la foto real del producto
Reportado en produccion: el carrito mostraba el logo generico de ARI en vez de la foto del producto. Verificado en vivo: item.thumbnail viene null en la respuesta de Medusa para todo el catalogo real (confirmado tambien contra /store/products directamente -- el campo thumbnail del producto es null en la fuente, no solo omitido en la respuesta del carrito). El catalogo ya resuelve esto cayendo a images[0] (mapProduct() en medusa.ts); la linea del carrito necesita pedir esa relacion explicita via fields=*items.product.images (no viene por defecto) y aplicar el mismo fallback. |
||
|
devops
|
3fc77c6cdc |
feat(ecommerce): ADR 0009 - carrito real conectado a Medusa (Store API)
Primer corte de checkout real, a proposito acotado: el carrito pasa de estado 100% local (localStorage con productos completos) a sincronizar con un cart_id real de Medusa via /api/cart/* (rutas puente same-origin, mismo patron que /api/search -- MEDUSA_BACKEND_URL es DNS interno del cluster, no resuelve desde el navegador). Formas de respuesta de la API verificadas en vivo con un carrito de prueba real antes de escribir el mapeo (no asumidas contra documentacion): agregar el mismo variant_id dos veces hace merge de cantidad automatico (no crea linea duplicada); eliminar una linea devuelve el carrito actualizado en 'parent', no en 'cart' como los demas endpoints. La firma publica de useCartStore (addItem/removeItem/updateQuantity/ items) no cambia, asi que ningun componente consumidor (cart-drawer, navbar, product-card, product-purchase, mobile-add-to-cart) necesito tocarse. Sigue cerrando por WhatsApp -- direccion/envio/pago quedan para los siguientes cortes del ADR 0009. |