Arquitectura de una extensión de pago para Adobe Commerce
Una extensión de pago reutilizable para Adobe Commerce, construida para distribuirse entre varios comercios.
Se omiten los nombres del cliente y de los socios. El detalle de implementación se limita a lo que puede compartirse públicamente; hay más disponible durante una entrevista.
En resumen
- 01Problema
- Los comercios en Adobe Commerce necesitan una sola extensión de pago que coordine la evaluación de fraude, la autenticación 3-D Secure, la autorización y las operaciones posteriores al pago, empaquetada como una extensión reutilizable y no como código a la medida para una sola tienda.
- 02Mi responsabilidad
- Contribuí con decisiones de arquitectura e implementé salvaguardas en todo el ciclo de vida del pago, desde la secuenciación y la validación de tokens hasta la idempotencia, la concurrencia y la compatibilidad del SDK, y contribuí al diseño del proceso de certificación y de evidencia.
- 03Reto de arquitectura
- Un pago puede repetirse de muchas formas: reintentos del navegador, envíos duplicados, solicitudes concurrentes. Ninguna de ellas debe convertirse en una segunda llamada al procesador ni en una segunda operación financiera.
- 04Decisión clave
- Estado persistente del intento de pago, con transiciones que solo avanzan y control de concurrencia, para que un token de pago pueda avanzar por exactamente un intento.
- 05Resultado
- Fase avanzada de implementación, certificación y preparación para el marketplace.
Arquitectura
Evitar que un pago se convierta en dos
- 01CheckoutLa tienda recibe una tarjeta tokenizada
- 02Extensión de pagoOrquesta el ciclo de vida
- 03Evaluación de fraudeDecisión antes de la autenticación
- 043-D SecureAutenticación del tarjetahabiente, con desafío cuando se requiere
- 05AutorizaciónFondos reservados
- 06Posterior al pagoCaptura, reembolso, autorización incremental
Decisión clave
Estado persistente del intento de pago
Cada token de pago está ligado a un intento persistente cuyo estado solo puede avanzar. Cuando un intento llega a un resultado terminal ya no puede procesarse otra vez, y avanzarlo es una transición con control de concurrencia, así que dos procesos no pueden mover el mismo token de forma independiente. Se probó con procesos concurrentes compitiendo por el mismo token: solo uno avanzó. Contribuí al diseño de esta salvaguarda y la implementé.
Garantía 1 · Solo avanza
- Intento creado
- Avanzan las etapas de procesamiento
- Resultado terminal
Se rechaza volver a procesar un intento terminal.
Garantía 2 · Un solo ganador
Mismo token
- Solicitud A avanza
- Solicitud B rechazada
- Solicitud C rechazada
Decisiones complementarias
Otras decisiones
Secuenciación explícita del ciclo de vida
La evaluación de fraude, 3-D Secure y la autorización se ejecutan en un orden fijo: primero la decisión de fraude, luego la autenticación del tarjetahabiente y después el pago.
Protección contra capturas y reembolsos duplicados
Las operaciones posteriores al pago están protegidas para que una solicitud repetida no pueda producir una segunda captura o un segundo reembolso.
Aislamiento configurable de capacidades
La evaluación de fraude y 3-D Secure se controlan cada una con su propia configuración, así que los ajustes de una capacidad no alteran el flujo de la otra.
Contención de advertencias del SDK
Las advertencias y deprecaciones del SDK del proveedor en PHP 8.4 se contienen para que no puedan filtrarse a respuestas críticas en seguridad, sin modificar cómo se comporta el propio SDK.
Para lectores técnicos
Detalle técnico
Contexto
Una extensión de pago para Magento 2.4.8 / Adobe Commerce, construida para distribuirse entre varios comercios y no escrita para una sola tienda. Coordina la evaluación de fraude, la autenticación 3-D Secure, la autorización y la captura, los datos de tarjeta tokenizados y las operaciones posteriores al pago, y debe mantener ese ciclo de vida consistente cuando las solicitudes se reintentan, se repiten o se ejecutan de forma concurrente.
Escala
- Diseñada para desplegarse en varios comercios como una extensión distribuible de Adobe Commerce.
- Varias marcas de tarjeta y varios flujos de autenticación, fraude y pago.
Responsabilidad
- Contribuí con decisiones e implementé correcciones en la secuencia de evaluación de fraude, 3-D Secure y pago.
- Implementé salvaguardas para la prevención de repetición de intentos de pago, la idempotencia, la concurrencia y la protección contra capturas y reembolsos duplicados.
- Trabajé en la validación de tokens de corta duración, la resolución del tipo de tarjeta, la autorización incremental y la estabilidad del desafío 3-D Secure.
- Trabajé en el aislamiento por configuración entre capacidades de pago y en la compatibilidad del SDK del proveedor con PHP 8.4.
- Contribuí al diseño del proceso de certificación y de evidencia técnica.
Complejidad
- Secuenciar la evaluación de fraude, la autenticación 3-D Secure y el pago como un solo ciclo de vida explícito.
- Validación de tokens de corta duración emitidos al navegador, y resolución del tipo de tarjeta.
- Operaciones posteriores al pago, incluyendo captura, reembolso y autorización incremental.
- Garantías de idempotencia y concurrencia alrededor de los intentos de pago.
- Ejecutar un SDK de PHP del proveedor en PHP 8.4 sin alterar su comportamiento.
Arquitectura
- Un orden explícito de pasos: evaluación de fraude, luego 3-D Secure, luego autorización.
- Capacidades de pago aisladas por configuración.
- Estado de intento persistente, que solo avanza, y que protege el avance de cada token de pago.
Evidencia
Suites extensas de pruebas automatizadas, incluyendo pruebas de concurrencia. No son públicas.