Personalización del checkout de Shopify

Lo que de verdad se pide

Casi nunca es un rediseño. En los proyectos que me llegan, el checkout se toca por cuatro motivos:

1. Avisar de algo antes de pagar. Un mínimo que no se cumple, un producto que tarda tres semanas, un plazo de pago que la empresa ya tiene concedido.
2. Pedir un dato. Número de pedido de compra, CIF, referencia interna del comprador, fecha de entrega deseada.
3. Bloquear. Que no se pueda pagar un carrito que el almacén no va a poder servir.
4. Ordenar métodos. Esconder o reordenar envíos y pagos según el carrito, el país o la empresa.

Los cuatro caben en Checkout Extensibility. Lo que no cabe es mover los pasos del checkout o maquetarlo libremente, y conviene saberlo antes de prometerlo a dirección.

Las piezas y cuál toca

• El editor para lo visual: logotipo, colores, tipografías, orden de bloques. Sin código y sin Plus.
• Extensiones de interfaz para añadir contenido o campos en los puntos permitidos del checkout y de la página de gracias.
• Functions para el comportamiento: validaciones que bloquean, descuentos, disponibilidad y orden de métodos de envío y de pago.

La diferencia que más importa al presupuestar: una extensión que muestra un aviso es una tarde; una validación que decide si un carrito puede pagarse toca reglas de negocio y hay que escribir los casos límite antes de tocar el código.

En B2B, dos cosas concretas

El checkout de un portal mayorista se juega en dos detalles. El primero es decir el plazo de pago donde el comprador lo ve: si paga a 60 días, decirlo en el carrito y en el checkout baja el abandono más que cualquier sello. El segundo es el pedido de compra: un comprador profesional tiene que poder meter su referencia, y esa referencia tiene que llegar al pedido.

Qué entrego

La extensión o la Function con su configuración, probada en una tienda de desarrollo con los carritos que de verdad dan problemas, y escrito qué se puede cambiar desde el admin sin volver a llamarme.