POC de pagos divididos: referencia rápida del tutorial

Esta página resume cómo se organiza la serie de tutoriales de prueba de concepto de pago dividido. Asigna cada archivo de solicitud de origen numerado a su página de Experience League publicada, enumera un orden de sección sugerido para los lectores y recopila notas para los autores y administradores.

Referencia archivo por archivo

Crear un POC de pago dividido: herramientas de App Builder e IA

etiqueta Source: 00_TUTORIAL_OVERVIEW.md (descripción general conceptual; la serie publicada se abre con esta página).

Propósito: Introducción y orientación para el tutorial.

Por qué se necesita: Ofrece a los desarrolladores el “por qué” antes del “cómo”. Explica qué construirán, quién es la audiencia y, de forma crítica, qué deben personalizar si su sitio difiere de una instalación de Luma limpia. También sirve como tabla de contenido para el resto de la serie.

Uso del tutorial: Sección de apertura. Establece el contexto antes de cualquier paso técnico.

POC de pago dividido: decisiones de arquitectura y diseño

Propósito: explicación detallada de cada decisión arquitectónica en el PoC.

Por qué es necesario: El punto de confusión más común al trabajar con este PoC es comprender por qué hay algo en PHP en comparación con App Builder. Sin este contexto, los desarrolladores intentan mover cosas que no se pueden mover (como la aplicación de crédito de la tienda) y fallan. Este documento se anticipa a esos fracasos con un razonamiento claro.

Temas clave cubiertos:

Uso de tutorial: sección “Arquitectura” o “Cómo funciona”. Los desarrolladores de Commerce experimentados pueden omitirlo, pero es esencial para los recién llegados a App Builder.

POC de pago dividido: requisitos previos y configuración del entorno

Propósito: Complete la lista de comprobación previa al vuelo antes de escribir código o de ejecutar mensajes.

Por qué es necesario: La fase de instalación tiene la tasa de errores más alta en los tutoriales. Este documento garantiza que el administrador de Commerce esté configurado correctamente (título de COD exacto, crédito de tienda habilitado, cliente de prueba con saldo, integración creada), que el proyecto de App Builder tenga eventos de E/S y que el proveedor de eventos de Commerce esté conectado, y que el entorno local tenga las versiones correctas.

Elementos de énfasis:

Uso del tutorial: Sección “Requisitos previos” o “Introducción”. Debe completarse de forma interactiva, no solo leerse.

POC de pago dividido: referencia de variables de entorno

Propósito: todas las variables de entorno para los tres componentes en un solo lugar.

Por qué es necesario: Las mismas cuatro credenciales de OAuth aparecen en tres archivos diferentes con nombres de variables diferentes (COMMERCE_* en comparación con COMMERCE_INTEGRATION_*). Tener una sola referencia evita la depuración de por qué no funciona cuando un conjunto de credenciales tiene un error tipográfico.

Componentes cubiertos:

Uso del tutorial: Barra lateral de referencia o sección “Configuración”. También se utiliza como complemento de las indicaciones de compilación.

POC de pago dividido: petición de API del módulo Commerce

Propósito: Mensaje de IA completo e independiente para generar todo el módulo PHP Client_SplitPayment.

Por qué es necesario: Este es el artefacto principal de generación de IA para PHP. Está escrito para que un desarrollador sin experiencia PHP pueda entregarlo a Cursor (con Claude) y obtener un módulo de trabajo. Se especifican todos los archivos, se definen todos los contratos de comportamiento, se incluyen notas de implementación críticas y se proporcionan los comandos para habilitar el módulo posteriormente.

Cobertura:

Uso del tutorial: sección “Generar el módulo Commerce”. El indicador en sí es el artefacto: los desarrolladores lo copian en su herramienta de IA y lo ejecutan.

POC de pago dividido: petición de App Builder orchestrator AI

Propósito: Mensaje de IA completo e independiente para generar la aplicación de App Builder split-payment-orchestrator.

Por qué es necesario: Las cuatro acciones de App Builder (payment-orchestrator, payment-accept, payment-decline, demo-dashboard) son el núcleo de la historia de “qué se movió de PHP”. Este mensaje los genera todos con especificaciones de comportamiento completas, estructura app.config.yaml correcta y la configuración de registro de eventos.

Cobertura:

Uso del tutorial: sección “Generar la aplicación de App Builder”. Acompañante del mensaje del módulo de Commerce.

POC de pago dividido: petición de API de la extensión Experience Cloud UI

Propósito: petición de datos de IA para generar la extensión opcional SDK de la IU de administración de Experience Cloud.

Por qué es necesario: El tablero de demostración en el indicador del orquestador es intencionalmente áspero: es prueba de concepto, no producción. Esta sección muestra a los desarrolladores el siguiente paso: incrustar el panel de pago dividido en el Admin Shell de Commerce mediante la IU de administración de SDK. Faltaba por completo en los mensajes originales.

Cobertura:

Uso del tutorial: Sección opcional “Yendo más lejos” o “Ruta de producción”. Se puede omitir si el tutorial se centra únicamente en el PoC.

POC de pago dividido: guía de prueba y verificación

Propósito: Guía de pruebas paso a paso que cubre todos los componentes en el orden de verificación correcto.

Por qué es necesario: La creación de los componentes es la mitad del trabajo. Los desarrolladores necesitan una ruta de verificación clara que comience desde el nivel más bajo (columnas de base de datos, puntos finales REST) y se genere en el flujo completo de extremo a extremo. Las indicaciones originales tenían una lista de comprobación de configuración, pero no un flujo de prueba explícito.

Cobertura:

Uso del tutorial: Sección “Pruebas” o “Verificación”. También es útil como referencia para la resolución de problemas.

POC de pago dividido: pasos siguientes después de la prueba de concepto

Propósito: hoja de ruta para convertir el PoC en patrones listos para la producción.

Por qué es necesario: Un tutorial de PoC corre el riesgo de dejar a los desarrolladores con un “¿qué pasa ahora?” sensación. Este documento asigna las progresiones naturales desde la demostración a la producción: reemplazando el panel de demostración con una extensión de Experience Cloud, conectando un ERP real, añadiendo API Mesh, expandiendo el flujo de trabajo de App Builder y la lista de comprobación de implementación de producción.

Contenido de clave:

Uso del tutorial: Sección de cierre “Pasos siguientes”. También es útil como punto de partida para iniciar conversaciones sobre un proyecto real.

Secciones del tutorial sugeridas

En función de estos archivos, una estructura típica para los lectores es:

Notas importantes para los autores de tutoriales

En el supuesto del tema de Luma: Cada mensaje de compilación genera código para una instalación de Luma limpia. El tutorial debe indicar claramente esto en la parte superior: los desarrolladores con cierres de compra personalizados deberán adaptar las rutas de inyección de LayoutProcessorPlugin y posiblemente la configuración de RequireJS. La introducción de series y los indicadores de compilación incluyen llamadas de personalización para esto.

En el módulo PHP: El tutorial explícitamente no proporciona el código PHP como una descarga de copiar y pegar. El mensaje de IA lo genera. Esto es intencional: enseña el patrón de uso de la IA para crear extensiones de Commerce, no solo copiar y pegar plantillas. Sin embargo, el código generado cuando se le solicita en un entorno limpio debe coincidir exactamente con el código de trabajo de app/code/Client/SplitPayment/.

En el umbral de 100 $: Este es un valor de PoC codificado. El tutorial debe tener en cuenta que los almacenes reales querrán configurarlo mediante la configuración de administración de Commerce en lugar de una constante de tiempo de compilación.

Dependencia de crédito de la tienda: El flujo de pago dividido tal como se creó requiere Magento_CustomerBalance (el módulo de crédito de la tienda nativa).

Recursos de POC de pagos fraccionados relacionados