Desarrollo de e-commerce con Laravel

La mayoría de los negocios no debería construir su propia tienda. Una plataforma alojada sale más barata que una base de código mientras el negocio quepa dentro, y para un catálogo de doscientos productos simples el consejo honesto es que cabe.

El trabajo de abajo empieza donde deja de caber, y normalmente deja de caber en la trastienda y no en el escaparate.

Dónde se acaba de verdad una plataforma

Precios que son una regla, no un número. Precios por contrato según cliente, escalados por cantidad, una cuenta de mayorista con condiciones distintas por grupo de producto. Casi todas las plataformas modelan un precio y un descuento, y todo lo que va más allá acaba en una hoja de cálculo que alguien mantiene a mano.

Stock que vive en más de un sitio. Dos almacenes, una tienda física, un canal de marketplace y una ruta de envío directo desde proveedor. La pregunta "cuántos podemos vender" deja de tener una sola respuesta, y la respuesta de la plataforma es la que sobrevende.

Un ERP que es la fuente de verdad. Cuando la contabilidad es dueña del precio y del stock, la tienda va por detrás. Una plataforma que asume que esos campos son suyos peleará contra la integración durante toda la vida del proyecto.

Una preparación de pedidos que es un flujo. Envíos parciales, pedidos pendientes, un paso de picking, un plazo de fabricación. Un pedido que no es simplemente pagado-y-enviado es donde terminan los motores de flujo de las plataformas.

Las partes que construimos con cuidado, porque ahí se pierde dinero

Stock que no puede sobrevender. Leer un nivel de stock y luego decrementarlo es una carrera, y bajo una promoción es una carrera que ocurre cientos de veces por segundo. El decremento es una actualización condicional que decide la base de datos:

$claimed = Inventory::where('variant_id', $id)
    ->where('available', '>=', $qty)
    ->decrement('available', $qty);   // 0 significa que se lo llevó otro

Encima va una reserva con caducidad - stock retenido mientras hay un checkout en curso y liberado si se abandona - porque la alternativa es sobrevender o retener stock para siempre por carritos que nadie completó.

Un pedido como máquina de estados, no como columna de estado. Qué transiciones son legales, cuáles son irreversibles y qué puede tocar cada una. Una columna de estado que se escribe desde cuatro controladores es como un pedido acaba enviado y reembolsado y a la vez pendiente de pago.

Webhooks de pago que llegan dos veces, tarde o desordenados. Todos los proveedores mandan duplicados, y la notificación de cobro puede llegar antes que la redirección que supuestamente la precedía. Los webhooks se verifican, se guardan en crudo y se procesan de forma idempotente contra una referencia del proveedor, de modo que una repetición no hace nada en lugar de provocar un segundo envío.

Impuesto calculado una vez, en el momento correcto, y registrado. El tipo que se aplicó el día del pedido es parte del pedido, no una consulta que se repite cuando alguien abre la ficha un año después. Cuando se vende fuera del país, el lugar de prestación y la situación fiscal del cliente cambian la respuesta, y la regla que produjo cada línea tiene que quedar guardada junto al importe, porque eso es lo que pide una inspección.

Dinero siempre como entero. Unidades menores, con la divisa y su exponente guardados. La coma flotante en un sistema de comercio produce un libro que nunca cuadra y una conciliación que nadie puede cerrar.

Las integraciones que deciden el proyecto

Los proyectos de comercio rara vez son un solo sistema. Son una tienda, un ERP o un paquete contable, un proveedor de pago, un transportista, a veces un PIM y un marketplace.

Lo que hace que salgan bien es decidir la propiedad antes de escribir código: qué sistema es dueño del número de stock, cuál del precio, cuál del cliente. Todos los desastres de integración a los que nos han llamado empezaron con dos sistemas creyéndose dueños del mismo campo, y se resolvían con procesos nocturnos que se sobrescribían alternativamente.

Después la parte mecánica, que es la misma disciplina que cualquier trabajo de integración: reintentos con retroceso, un outbox para que no se pierda nada cuando el otro extremo esté caído, y un registro de lo enviado que una persona pueda leer cuando un cliente pregunte por su pedido.

La parte de administración, que es casi todo el uso real

El escaparate se lleva la atención y la trastienda se lleva las horas. Búsqueda de pedidos que funcione con una referencia parcial, el historial completo de un cliente en una pantalla, un reembolso que sea una acción y no cuatro, y un ajuste de stock que registre quién lo hizo y por qué.

Esto lo construimos sobre un panel de administración y no desde cero, porque una pantalla CRUD a medida no es donde está el valor, y porque quien lo usa ocho horas al día prefiere algo convencional a algo ingenioso.

Cómo transcurre un encargo

La primera conversación va de dinero, no de código. Dónde se pierden pedidos hoy, cuánto cuesta el lado de administración en horas de personal, y qué integración da miedo a todo el mundo.

De ahí escribimos el alcance: las fases, la lista de integraciones, qué pasa con sus URL actuales, y el precio. No se construye nada antes de que ese documento esté firmado, porque en una tienda los errores caros se cometen la primera semana y se descubren al sexto mes.

El desarrollo corre luego en fases que terminan desplegadas. El checkout nunca es lo primero que tocamos ni lo último que probamos.

Qué recibe

Un backend de comercio con las reglas escritas y aplicadas en un solo sitio, un modelo de pedido capaz de explicar su propia historia, integraciones con un dueño por campo, y pruebas sobre los caminos que mueven dinero: checkout con presión concurrente sobre el stock, webhooks duplicados, reembolsos parciales, impuestos en los casos frontera.

Si todavía no sabe si construir es la respuesta correcta, normalmente no lo es, y una auditoría de lo que tiene hoy se lo dirá antes y más barato que una propuesta.