Pagar desde el teléfono, con el membrete de siempre.

La pantalla /payments ya existe como placeholder de MF-03 y se abre desde Más, desde «Ver todos» del home y desde las notificaciones. Es una pantalla de stack (fuera de (tabs)) con el StackHeader de MF-04, y lleva los dos tabs de la web como Tabs pill a lo ancho. La card es la de la página web, campo a campo, en una columna: tipo de cobro, ruta, código, cotización, estatus, «Total | Pendiente», vencimiento y «Pagar ahora».

Paridad con la web: grupos por mes con «N pagos · total» a la derecha y filas que se despliegan. Cambian tres cosas porque el soporte es un teléfono: el scroll infinito reemplaza el botón «Cargar más» (FlashList con onEndReached, página de 20), el comprobante se abre en el PdfViewer de MF-04 con compartir nativo, y el enlace a la entidad dice qué abre según su tipo.

Se copian los seis estados de la web. Los skeletons son anatómicos: repiten la forma de la card y de la fila, no barras genéricas. Un error nunca tira una lista que ya cargó: si falla la página siguiente del historial, aparece una línea roja al pie con reintento. Sin conexión, las listas muestran lo último que cargaron y el aviso es el ConnectionAlert global de MF-03, que ya cubre todo el stack (app). No hay un banner propio de pagos.

Mientras carga, el tab «Pendientes» no muestra contador: nunca un 0 falso (la misma regla de los chips de MF-06). En el vacío de pendientes, «Ver historial» es la siguiente acción natural. Mientras se refresca, la lista queda al 60 % sin skeleton (isPlaceholderData), como en la web.

Tres puertas, y ninguna obliga a pasar por la lista. En la web, «Pagar» del home y «Pagar ahora» de la alerta del flete abren el portal directamente. Hoy la app navega a /payments (home) o muestra el toast «Funcionalidad de pago próximamente» (alerta). MF-07 conecta las dos al mismo PaymentPortalSheet. El contador vive en la fila Pagos de Más y en el punto rojo del tab, ambos alimentados por sidebar-counts.pendingPayments.

La alerta del flete paga pendingAmount neto: los fees de servicio viajan con su pago, no con el flete (lib/freights/service-fees.ts, portado en MF-06). Por eso «Fees de servicio: $21,70» corresponde al pago anterior con tarjeta, y el fee de este pago lo calcula el portal cuando se elige el método (§06).

El enfoque ya está decidido (WebView en v1). Queda la forma. El portal habla otro sistema: marino y papel, Neue Haas, cifras tabulares, el filo de --grad-marca. La app habla el producto. Hay que decidir quién pone la cabecera y qué se ve mientras la web no está lista. Se evaluaron tres formas:

Cerrado por Fabrizio: B. La marca ya separa las dos cosas: Contexto A es para el dinero y Contexto B para operar. Poner el membrete nativo le dice al cliente «aquí se paga» antes de que cargue un byte, y hace que la espera tenga la forma del portal y no la de un sheet genérico. Además resuelve el único punto frágil de la WebView, porque la app, que conoce su origen, puede mostrar en el membrete a qué host está conectada (§07). La cabecera noche ya es un patrón de MF-01/MF-03 (sheet de crear, Próximamente), así que no se introduce nada nuevo en el shell.

Se presenta como page sheet a pantalla casi completa, sobre la pantalla desde la que se abrió, que queda con velo marino. No se cierra arrastrando: el gesto choca con el scroll de la WebView y un deslizamiento accidental perdería un formulario de Stripe a medio llenar. Se cierra con la ✕ del membrete o con el botón atrás de Android. Debajo del membrete corre el portal real en embed, la misma pasarela que la web: resumen, montos rápidos, los cuatro métodos (Stripe, PayPal, Binance Pay y Zelle) y el desglose del fee de servicio. No hay SDK de pago nativo.

La ortografía del portal tiene deuda visible («Resumen del Pago», «Opciones Rapidas», «Monto Especifico», «Descripcion», «encriptacion»). La maqueta ya muestra la versión corregida en sentence case, y el arreglo va como fase chica en apps/payments-portal con spanish-i18n-review.

Todo lo que no es el portal lo pinta la app, con las piezas del portal: papel --hueso, placa circular, título en display, CTA marino con filo y botón fantasma. El membrete no cambia, salvo la fila de Conexión, que dice la verdad: host seguro, «Sin señal» o el host del banco. El «no se cobró nada» solo se dice cuando es cierto (antes de PAYMENT_READY o en un error de carga).

1. El skeleton tiene la forma del portal

   Resumen con borde marino, barra, bloque de monto, cuatro montos rápidos y CTA, en --line-soft sobre papel. Cuando llega PAYMENT_READY, la WebView (montada con opacidad 0 desde el principio) hace fundido sobre el skeleton. No hay flash blanco.

2. Sin conexión no destruye nada

   Si se cae la red con el portal ya cargado, la WebView se queda como está (Stripe reintenta solo) y solo la fila Conexión pasa a «Sin señal» con punto rojo. El estado de pantalla completa aparece únicamente si no hay nada que mostrar. «Reintentar» recarga la misma URL, porque el enlace dura 24 h.

3. Error con salida de emergencia

   «Abrir en el navegador» usa expo-web-browser con la URL sin embed. Es la opción C como fallback, equivalente al «Abrir en pestaña nueva» de la web. Al volver (AppState activo) se invalidan igual pendientes, historial y contadores.

4. Enlace vencido: uno nuevo, no un callejón

   PAYMENT_ERROR por token inválido lleva a este estado. «Generar un enlace nuevo» repite el POST payment-gateway/links con el mismo ítem y recarga. Los errores de tarjeta (rechazada, sin saldo) los muestra el portal dentro de su formulario, y la app no los tapa.

5. El membrete dice dónde estás

   La verificación 3DS de Stripe navega fuera del portal. La fila pasa a «Tu banco · hooks.stripe.com» con el icono de banco en celeste. Es la única señal de host que tiene el cliente dentro de una WebView, y por eso solo aparecen hosts de la lista permitida (§09).

6. Salir con confirmación, solo cuando importa

   Antes de PAYMENT_READY, la ✕ cierra directamente. Después pide confirmación con «Seguir pagando» como acción principal. El texto no promete lo que la app no sabe: si el cliente ya envió un Zelle, se refleja cuando se verifique.

En modo embed, el portal no redirige al terminar: avisa con PAYMENT_SUCCESS. La app, en ese instante, invalida primero (['payments','pending'], ['payments','history'], ['users','sidebar-counts'] y, si es un flete, ['freights', id]) y después reemplaza el cuerpo del sheet por una pantalla final nativa en papel. Hay dos finales según el status del payload: pagado (tarjeta, PayPal, Binance) o en verificación (Zelle, status: "pending_verification"). Las dos se animan al entrar en vista.

1. El único momento con brillo

   El membrete toma --grad-celeste-glow con un fundido de 420 ms, el escudo pasa a doble check con «Pago recibido», la placa --grad-fresh entra con pop ease-spring de 420 ms, el check se dibuja (260 ms) y los textos suben 12 px con stagger de 40. «Ver el comprobante» aparece solo si viene receiptUrl. No hay toast: la pantalla ya es la confirmación.

2. La card se va, el resto se acomoda

   Al tocar «Listo», la card pagada se pliega y se desvanece (260 ms) y las demás suben. La banda «Pendiente total», el contador del tab, la fila de Más, el punto del tab y el home ya están al día por la invalidación. Si fue un abono parcial, la card se queda con el nuevo pendiente.

3. Zelle: enviar no es recibir

   «Ya envié el pago» llega con status: "pending_verification". La app no celebra: muestra «Estamos verificando tu Zelle» con el monto enviado y el memo, y la manecilla del reloj da una sola vuelta (640 ms, sin repetir ni pulsar). Membrete «Pago enviado», sin brillo.

4. El pendiente no desaparece hasta que ops verifique

   Con Zelle igual se invalida (el portal pudo registrar algo), pero el pendiente sigue en la lista, el badge y el home hasta que operaciones verifique el pago y la API cambie el estatus de la cotización. El texto de la pantalla lo dice antes de cerrar, así la lista sin cambios no parece un error.

Misma pasarela que la web: apps/payments-portal embebido, con sus cuatro métodos (Stripe, PayPal, Binance Pay y Zelle) y cero SDK nativo. Hay un solo contrato de mensajes y dos cables para transportarlo: el iframe de la web y la WebView de la app. El portal elige el cable según dónde corre. La app no inyecta JavaScript para parchar el portal y no usa polling como señal de éxito.

Fase chica obligatoria en el portal. Hoy apps/payments-portal/lib/embed/messaging.ts sale antes de postear si window.parent === window, que es justo el caso de la WebView, así que la app nunca recibiría nada. Hay que emitir también por ReactNativeWebView cuando exista (sin tocar el cable web ni su allowlist) y agregar status: "pending_verification" al éxito de Zelle. Sin endpoints ni migraciones. Plataforma: es pago de un servicio logístico físico, no IAP; react-native-webview es dependencia nativa nueva y requiere dev build por el método warehouse (sin eas build).

Los dos finales son los únicos momentos orquestados y los dos se pueden ver en el HTML (§08, botones «Repetir»). El degradado solo aparece donde algo avanza (el filo) o se completa (la placa de éxito). Nada pulsa ni supera los 640 ms. Háptica: success en el éxito, light en Zelle, warning al abrir la confirmación de salida.

• Cerrada · 1

  Opción B en todas las bifurcaciones

  Membrete nativo (Contexto A) y portal embed=true en el cuerpo. Los estados no-portal se pintan en papel. Sin arrastre para cerrar; ✕/atrás con confirmación después de READY. Ante cada bifurcación de forma gana la opción recomendada.

• Cerrada · 2

  Finales animados

  «Recibimos tu pago» y «Estamos verificando tu Zelle» con el motion de la spec: placa 420 ms ease-spring, check 260, manecilla 640 en una sola vuelta, stagger 40. Reduced motion lleva al estado final.

• Cerrada · 3

  Misma pasarela que la web

  apps/payments-portal embebido con Stripe, PayPal, Binance Pay y Zelle. Cero SDK nativo (ni Stripe RN, ni PayPal nativo, ni Binance).

• Cerrada · 4

  Un contrato, dos cables

  { source, type: READY | SUCCESS | ERROR, payload } con status: "pending_verification" para Zelle. Web por window.parent.postMessage con allowlist (nunca "*"); app por ReactNativeWebView.postMessage, validando source y el origen de la URL. Sin JS inyectado; el polling es solo red de seguridad; PayPal usa el fallback /success y /error. Fase obligatoria en messaging.ts.

• Cerrada · 5a

  Banda «Pendiente total»

  summary.totalPending + count + chip de vencidos, arriba de las cards. Se actualiza con la invalidación del éxito.

• Cerrada · 5b

  Equivalente en Bs en el historial

  Línea «Equivalente · tasa · fecha» con equivalentAmount, equivalentRate y equivalentRateCapturedAt, en la fila desplegada y solo cuando vienen (métodos en bolívares). El esquema de la app no los descarta.

• Cerrada · 5c

  Zelle «en verificación»

  UI nativa con monto y memo. El pendiente no desaparece de lista, badge ni home hasta que ops verifique.

• Cerrada · 6

  DoD en iPhone lo hace Fabrizio, en staging

  Con el PR montado y cuentas de prueba: Stripe pk_test + 4242, PayPal y Binance sandbox, Zelle = el formulario. Nunca producción. El visual QA de los agentes cubre la UI sin dinero; el DoD con dinero no es gate de los agentes.

• Diseño · consecuencia

  Pantalla de stack, entradas directas

  /payments con tabs Pendientes (contador) / Historial y ?tab=history para deep links. «Pagar» del home y «Pagar ahora» de la alerta del flete abren el sheet directamente; se retira el toast «próximamente».

• Deuda anotada · para goal-phases

  Lo que la web debe y la app no repite

  Dos mapas de color de estatus (gana el del widget). Tonos purple/sky fuera de escala. «Ver envío» para todos los tipos. Agrupación por createdAt y descarte de paidAt/equivalent*. El sheet web no invalida sidebar-counts. CorridorBadge morado con nombre crudo. Ortografía del portal. PAYMENT_CANCELLED sale del contrato. Sin eventos PostHog: definir payment_*.