Precio de suscripción en Checkout UI Extensions de Shopify

Una extensión de interfaz de pago (checkout UI extension) de Shopify no puede reescribir el precio recurrente que ve un suscriptor al pagar. Ese número proviene de la política de precios (pricing policy) del plan de venta (selling plan), así que cuando se ve mal después de un cambio de producto, la corrección va en el plan, no en la extensión.

Un vendedor con una suscripción de velas vio que el Recurring Subtotal mostraba siempre el precio inicial, incluso después de que los clientes cambiaran a una variante de recarga más barata, como se describe en un hilo de la Comunidad de Shopify. Vemos la misma confusión en nuestra propia cola de soporte: 13 preguntas sobre el pago de suscripciones en 90 días, incluidos vendedores que no saben qué promete el pago frente a lo que realmente se cobra.

De dónde viene realmente el precio recurrente

Shopify organiza los productos de suscripción en grupos de planes de venta (selling plan groups). Cada plan tiene una política de precios, y esa política tiene dos formas: fixed, un único ajuste para toda la suscripción, o recurring, un ajuste distinto una vez terminado un periodo inicial. El pago lee directamente la política asociada a esa línea.

Las extensiones de interfaz de pago se colocan junto a ese número, no dentro de él. Shopify las documenta como bloques o contenido estático colocado antes o después de las secciones del pago. El cálculo del precio lo gestiona por separado Shopify Functions, no una extensión de interfaz.

Si no has auditado tus extensiones de pago y cuenta desde el último plazo, es un buen punto de partida antes de añadir otra.

Dos cosas que la gente llama "cambio de producto"

Separa estos dos casos antes de diagnosticar: un cambio de ciclo integrado en el plan, como precio inicial de velas y luego precio de recarga sin ninguna acción del cliente, y un cambio manual de producto hecho por el comprador a mitad de la suscripción. El caso del foro mencionado arriba es del primer tipo. Un cambio manual es una acción distinta, pero actualiza el mismo objeto de política de precios por debajo.

La auditoría: averigua qué está roto

1. Consulta el plan de venta detrás del producto, desde el panel de tu app de suscripciones o mediante la consulta Admin GraphQL sellingPlanGroups, y revisa sus políticas de precios.
2. Comprueba si tiene una política o dos. Una sola política significa que ambos ciclos mostrarán y cobrarán el mismo número, por diseño.
3. Si esperas dos precios, añade la política recurring que falta a través de tu app de suscripciones, de modo que el primer ciclo cobre el precio inicial y los ciclos posteriores el precio del cambio.
4. Guarda el cambio, realiza un pedido de suscripción de prueba real y revisa su primer cobro próximo dentro de tu app de suscripciones antes de decirle a nadie que el problema está resuelto.
5. Si ambas políticas ya son correctas y el pago sigue sin quedar claro, es un problema de redacción, no de precio. Pasa a la siguiente sección en lugar de volver a editar el plan.

Por qué merece la pena arreglarlo antes de la próxima migración

Un suscriptor que ve un precio al pagar y otro distinto en su extracto suele cancelar o abrir una disputa bancaria. Suele aparecer justo cuando las tiendas migran de app de suscripciones.

También hemos visto tickets de soporte donde los métodos de pago fallaban de forma independiente al precio, por ejemplo una pregunta de "iDEAL/Mollie payments not working" tras un cambio de proveedor. Es un fallo distinto que conviene revisar por separado.

Si estás valorando si una migración merece la pena, nuestro desglose de costes de suscripción cubre las comisiones que la mayoría de tiendas pasan por alto.

Cuando el número es correcto pero el texto no

Las apps construidas sobre el modelo de precios nativo de Shopify guardan un cambio igual que Shopify. Progus Subscriptions, por ejemplo, mantiene las políticas de precios de cada plan como pares de tipo de ajuste y valor de ajuste, el mismo objeto del que lee el pago, así que la auditoría anterior funciona igual sin importar qué app gestione la suscripción.

Si el importe cobrado ya es correcto y solo quieres contexto adicional antes del cambio, un desarrollador puede añadir una extensión de interfaz de pago cerca del resumen del pedido. Puede leer un precio futuro guardado en un metafield y mostrarlo como una nota. Esa nota no cambia la línea Recurring Subtotal, solo responde a la pregunta de al lado.

Shopify limita las extensiones de interfaz de pago en los pasos de información, envío y pago a tiendas con plan Shopify Plus. Las extensiones cerca del resumen del pedido siguen un tipo de destino distinto, así que confirma tu ubicación exacta antes de prometer nada.

Conclusión

Las extensiones de interfaz de pago son una capa de presentación, no un motor de precios. Cuando un número se vea mal, revisa primero la política de precios del plan de venta, y construye una extensión propia solo después de confirmar que el importe cobrado en sí es correcto.

Las apps de suscripciones cambian por adquisiciones, migraciones y proveedores que retiran funciones, más a menudo de lo que la mayoría de comerciantes espera. Vuelve a probar la política de precios y la configuración del método de pago por separado después de cualquiera de esos eventos, porque uno puede fallar sin que falle el otro.