Pagos en stablecoins para headless commerce: ¿hay un plugin para Medusa, Saleor o Vendure?

Payzum es un procesador de pagos cripto sin custodia y enfocado en stablecoins: los pagos se liquidan directo en wallets que controla el comercio. Esta guía trata de pagos en stablecoins para headless commerce. Está pensada para equipos que montan su tienda sobre Medusa, Saleor, Vendure o Sylius y construyen su propio storefront encima. Explica por qué un checkout headless necesita una integración de pagos hecha para su framework y te da seis comprobaciones para cualquier plugin cripto. Después recorre cómo se engancha la integración de Payzum al checkout de cada framework, con el código que de verdad escribes. Las cuatro aparecen, con su licencia, en nuestro índice de plugins de pago cripto open source. Este artículo baja un nivel más.

Por qué una tienda headless necesita pagos en stablecoins hechos para su framework

En una tienda headless, el checkout es tu código. En WooCommerce o Magento, una pasarela de pago es algo que subes y activas. En un stack headless, un pago toca tres sitios que mantienes tú. El módulo del backend crea el pago. El storefront manda al comprador a pagar y lo trae de vuelta. Y una ruta de webhook tiene que encontrar el pedido correcto cuando llega el dinero. Una opción cripto que solo existe como plugin de carrito deja al equipo headless con una API REST y mucho código de pegamento por escribir.

Son frameworks serios, con releases frecuentes. El 4 de octubre de 2026, GitHub mostraba unas 36.600 estrellas para Medusa, 23.400 para Saleor y unas 8.500 para Vendure y Sylius cada uno. Los cuatro publicaron versión en las últimas cinco semanas. Medusa v2.21.2 salió el 28 de septiembre de 2026, Saleor 3.23.38 el 2 de octubre, Vendure v3.7.3 el 2 de septiembre y Sylius v2.3.0 el 28 de septiembre. Se eligen porque permiten vender en varias regiones, canales y monedas: Medusa tiene regiones, y Saleor y Vendure tienen canales. Justo ahí es donde las tarjetas salen caras.

Las tarjetas extranjeras se comen el margen. Tomemos la tarifa publicada de Stripe en euros, consultada el 4 de octubre de 2026. Una tarjeta estándar del EEE cuesta 1,5 % + 0,25 €. Una tarjeta emitida fuera del EEE y del Reino Unido cuesta 3,15 % + 0,25 €, más un 2 % si hay conversión de divisa. Un pedido de 120 € pagado con una tarjeta mexicana o estadounidense, cobrado en dólares, deja 6,43 € en comisiones. Si el comprador lo disputa, son 20 € por recibir la disputa y otros 20 € por responderla. Estos últimos solo se recuperan si ganas.

Muchos compradores ya tienen el dinero en USDT o USDC. Pasa en Argentina, Venezuela o Colombia, y con desarrolladores y clientes cripto en cualquier parte. También pasa en países donde la tarjeta internacional se rechaza o paga recargos cambiarios. Esos compradores pagan encantados en stablecoins si tu checkout se lo permite. Si no, se van o pasan a una transferencia lenta.

Lo que le cuesta a un equipo headless una integración cripto hecha a mano

Llamar a una API cripto desde tu backend lleva una tarde. Resolver bien los casos límite lleva mucho más. Cada punto de esta lista es un fallo que nos encontramos al construir nuestras propias integraciones:

• Pedidos marcados como pagados por la página de retorno. La cripto se confirma después de la redirección. Si tu código confía en que el comprador llegue a /gracias, cualquiera puede fingir esa visita.
• Firmas que solo validan a veces. Casi todos los frameworks web parsean el JSON antes de que corra tu handler. Si compruebas el HMAC contra el JSON re-serializado, 2.50 vuelve como 2.5 y la firma deja de coincidir. Los pedidos con importes redondos pasan las pruebas y los reales fallan en producción. Lo reprodujimos en Vendure 3.7.2.
• Un pedido pagado que un webhook tardío devuelve a impago. Los proveedores de pago envían más de una notificación y las reintentan. Un expired tardío y bien firmado, de una factura que el comprador sí pagó, es tráfico normal. En una prueba de punta a punta en Saleor, uno bajó el importe cobrado de una transacción de 3.0 a 0.0.
• Facturas gemelas. Una petición reintentada sin clave de idempotencia crea una segunda factura. El comprador puede pagar las dos.
• Importes que se desvían. Vendure guarda los precios en unidades menores (céntimos) y Medusa v2 en unidades mayores. Dividir entre 100 con decimales de coma flotante, o ignorar los decimales de cada moneda, produce facturas que no cuadran por una fracción.
• Un webhook que nunca encuentra el pedido. Puede ser una referencia que no apunta de vuelta a la sesión, o una ruta que el framework no reconoce. Antes de la v2.21.2, Medusa no resolvía su ruta de webhook con el prefijo pp_. Y en Express 5, una ruta de montaje sin barra inicial nunca se ejecuta. En ambos casos, el comprador paga y el pedido se queda sin pagar.

Cada uno de estos fallos acaba en una de dos cosas: mercancía enviada sin cobrar, o un cliente que ya pagó esperando mientras alguien lee logs. Y suelen aparecer un sábado, no en la demo del sprint.

Por qué los plugins de tarjeta, las pasarelas custodiales y la API a pelo se quedan cortos en un checkout headless

Los plugins de tarjeta están maduros, pero el dinero no es final. Medusa, Saleor, Vendure y Sylius tienen buenas integraciones de tarjeta, y conviene mantener la tuya. Pero el adquirente retiene los fondos primero, las comisiones transfronterizas se acumulan y un pago puede revertirse meses después de enviar el pedido.

Las pasarelas cripto custodiales resuelven el cobro, no la custodia. El comprador paga a la dirección de la pasarela. La pasarela te acredita un saldo y retiras cuando ella lo permite, con sus mínimos y su política de congelamiento. Muchas, además, solo publican plugins de carrito, así que vuelves a la API a pelo.

La API o el SDK sin más te dejan todo lo anterior a ti. Payzum publica SDKs oficiales para Node.js/TypeScript, PHP, Python y Rust, y son la herramienta correcta para flujos a medida. Ese camino lo cubre nuestra guía para elegir una pasarela de pagos cripto con API REST. Pero una integración de framework es el SDK más todo lo de la sección anterior, ya escrito y probado.

Un servidor cripto autoalojado es una opción legítima si no quieres ningún tercero y tienes a alguien que lo opere. Las integraciones de este artículo son para equipos que quieren la misma custodia sin operar infraestructura de pagos.

Cómo elegir un plugin de pagos en stablecoins para una tienda headless: seis comprobaciones

Hazle estas seis preguntas a cualquier integración cripto para un framework headless, incluida la nuestra:

1. ¿Usa el punto de extensión de pagos nativo del framework? Un provider, una app, un handler o un gateway al que llama el framework es un método de pago de verdad. Tu panel, los estados del pedido y el resto de integraciones lo ven. Una ruta paralela que escribe directamente en los pedidos es un riesgo.
2. ¿Qué marca el pedido como pagado? Busca una notificación de servidor a servidor cuya firma se compruebe sobre los bytes crudos de la petición, con ventana anti-replay, antes de leer ningún campo. La vuelta del comprador solo debería mostrar un estado.
3. ¿Puede un webhook tardío o repetido deshacer o duplicar un pedido pagado? Un evento reenviado no debería cambiar nada. Un evento de fallo debería contrastarse con la factura real antes de degradar nada.
4. ¿Los importes son exactos? Busca cadenas o aritmética entera, los decimales propios de cada moneda y la unidad del framework, sea menor o mayor.
5. ¿Dónde se liquidan los fondos? ¿En tu propia wallet, o en un saldo que guarda el proveedor? Solo la primera opción deja a nadie con capacidad de congelar el dinero.
6. ¿Puedes leer el código y ver qué envía? Con una licencia abierta, tu equipo puede auditar el camino del webhook. Comprueba que no envía datos personales del cliente que el pago no necesita.

La guía de webhooks firmados explica las comprobaciones 2 y 3 con detalle de ingeniería.

Cómo se engancha Payzum al checkout de cada framework headless

Las cuatro integraciones siguen el mismo modelo, adaptado a la API de pagos de cada framework:

1. Crear. Cuando el comprador elige cripto, el backend crea una factura de Payzum por el total del pedido en su moneda, con una clave de idempotencia para que un reintento no cree una gemela.
2. Redirigir. El framework le da a tu storefront la URL de un checkout alojado. Allí el comprador elige moneda y red, escanea un QR o copia la dirección, y paga desde cualquier wallet. Ningún dato de wallet ni de tarjeta pasa por tus servidores.
3. Confirmar. Payzum envía una notificación firmada en su formato IPN compatible con NOWPayments. La integración verifica el HMAC-SHA-512 sobre los bytes crudos, con ventana anti-replay, y solo entonces marca el pago como pagado.
4. Liquidar. El dinero ya está en tu wallet: Solana confirma en unos 0,4 segundos, y Base y Polygon en unos dos. No hay saldo de Payzum que retirar, y las integraciones no contienen ninguna dirección de wallet.

El checkout solo ofrece los tokens que aceptas, que configuras en tu panel de Payzum, y Payzum aplica esa lista de su lado. La mayoría de tiendas elige USDT y USDC en redes de comisión baja. Si también aceptas otras criptos, la auto-conversión opcional a USDC o USDT está disponible en la mayoría de las redes soportadas. Por qué importa la custodia lo explicamos en qué es un procesador de pagos cripto sin custodia.

Las cuatro integraciones de un vistazo

Versiones publicadas en npm y Packagist al 4 de octubre de 2026.

Medusa v2: un Payment Module Provider

Medusa v2 añade métodos de pago como providers de su Payment Module. El provider de Payzum extiende AbstractPaymentProvider con el identificador payzum. Lo registras en medusa-config.ts:

// medusa-config.ts (apps/backend/ en un monorepo de create-medusa-app)
modules: [
  {
    resolve: "@medusajs/medusa/payment",
    options: {
      providers: [
        {
          resolve: "@payzum/medusa-payment-payzum",
          id: "payzum",
          options: {
            apiKey: process.env.PAYZUM_API_KEY,
            webhookSecret: process.env.PAYZUM_WEBHOOK_SECRET,
            payCurrency: "all",
            ipnCallbackUrl: "https://tu-tienda.example/hooks/payment/payzum_payzum",
          },
        },
      ],
    },
  },
]

Cómo se engancha al checkout. Cuando el storefront inicia una sesión de pago con el provider, initiatePayment() crea una factura de Payzum. La referencia de la factura es el ID de la sesión de pago de Medusa, que es lo único que trae de vuelta la notificación. El provider devuelve invoiceUrl en los datos de la sesión, y tu storefront redirige ahí al comprador. Con payCurrency: "all", el comprador elige la moneda, limitada a los tokens que acepta tu cuenta.

Cómo se confirma. Medusa trae una ruta de webhook, /hooks/payment/[identifier]_[id], que para este provider es /hooks/payment/payzum_payzum. El método getWebhookActionAndData() verifica la firma sobre los bytes crudos en tiempo constante y rechaza todo lo que caiga fuera de una ventana de 10 minutos. Un pago finished se informa como captured. Según la documentación de webhooks de Medusa, Medusa marca entonces la sesión como capturada y, si el carrito aún no está completado, lo completa. Así que el pedido existe aunque el comprador haya cerrado la pestaña.

Los fallos tardíos se vuelven a comprobar. Un evento expired o failed dispara primero una consulta de la factura real, y nunca degrada un pago que sí se hizo. La versión 1.2.0 corrigió exactamente ese caso. Además, authorizePayment() pregunta a la API de Payzum por el estado de la factura en lugar de fiarse del cuerpo de un webhook.

A tener en cuenta. Activa el provider en cada región donde lo quieras, desde el admin de Medusa en Settings → Regions. El SDK de Payzum es solo ESM, así que necesitas Node 20.19 o superior, o 22.12 o superior. refundPayment() lanza un error a propósito: las devoluciones se hacen fuera de Medusa. El provider solo envía a Payzum el total del carrito, la moneda, la referencia de sesión y tu URL de callback, sin datos personales del cliente.

Saleor: una app de pagos sobre la Transactions API

Saleor ejecuta los pagos en apps: servicios separados a los que Saleor llama por webhooks. La app de Payzum es un servicio pequeño en Next.js. Puedes instalar la instancia que aloja Payzum o desplegar la tuya.

Instalación. En el Dashboard de Saleor, ve a Apps → Install external app y pega https://saleor.payzum.com/api/manifest, o el /api/manifest de tu propio host. Abre la app y guarda tu API key, tu secreto de webhook y el entorno. Las credenciales se guardan cifradas con AES-256-GCM en la metadata privada de la app. La app pide un único permiso, HANDLE_PAYMENTS. Como dice la documentación de apps de pago de Saleor, sin ese permiso "Saleor will not call your payment webhooks", es decir, Saleor no llamará a tus webhooks de pago.

Cómo se engancha al checkout. La app se suscribe a tres webhooks síncronos: PAYMENT_GATEWAY_INITIALIZE_SESSION, TRANSACTION_INITIALIZE_SESSION y TRANSACTION_PROCESS_SESSION. Tu storefront llama a transactionInitialize con el ID de gateway payzum.app.payment:

mutation {
  transactionInitialize(
    id: "<checkout-o-pedido-id>"
    paymentGateway: {
      id: "payzum.app.payment"
      data: { successUrl: "https://tienda.example/gracias", cancelUrl: "https://tienda.example/carrito" }
    }
  ) {
    transaction { id }
    data            # { payzum: { paymentId, paymentUrl } }: redirige al comprador a paymentUrl
    transactionEvent { type message }
  }
}

La app crea la factura, con el ID de la transacción de Saleor como referencia, y responde CHARGE_ACTION_REQUIRED con la URL del checkout.

Cómo se confirma. Cada factura lleva su propia URL de notificación, así que no hay nada que pegar en el panel de Payzum. El endpoint del IPN lee el cuerpo crudo sin dejar que Next.js lo parsee, verifica la firma e informa el resultado con transactionEventReport. finished pasa a CHARGE_SUCCESS, y expired o failed pasan a CHARGE_FAILURE. Una factura partially_paid se queda en CHARGE_ACTION_REQUIRED: un pedido con pago incompleto nunca se envía, y al comprador nunca se le empuja a pagar dos veces. Saleor deduplica los informes reintentados, y si Saleor no responde, la app contesta con un 5xx para que Payzum reenvíe. Cuando el comprador vuelve, transactionProcess lee la factura de la API e informa su estado actual.

A tener en cuenta. Payzum no tiene un paso de autorizar y luego capturar, así que configura el flujo de transacción por defecto de tu canal en CHARGE, en Configuration → Channels → Payment settings. La app no ofrece acción de reembolso. Prepara los pedidos a partir de los eventos de transacción, nunca porque el comprador llegó a successUrl. Si la alojas tú, sirve cualquier host con Node 20+ que corra Next.js, y el repositorio también incluye un despliegue para Cloudflare Workers.

Vendure: un PaymentMethodHandler más un webhook firmado

Vendure modela los pagos con un PaymentMethodHandler y una máquina de estados de pago. El plugin de Payzum registra tres cosas: un handler, un controlador de webhook en /payzum/webhook y el middleware de cuerpo crudo que necesita la comprobación de firma. Añádelo a tu configuración:

// vendure-config.ts
import { PayzumPlugin } from "@payzum/vendure-plugin-payzum"

export const config: VendureConfig = {
  // ...
  plugins: [PayzumPlugin],
}

Configuración. En el Admin UI, crea un método de pago con el handler Crypto / Stablecoins (Payzum). Ponle el código payzum, que es también el método que tu storefront pasa a addPaymentToOrder. Después rellena la API key, el secreto de webhook, la moneda de liquidación (all deja elegir al comprador), el entorno y la URL de callback del IPN, https://<tu-host-vendure>/payzum/webhook. Apunta el webhook del panel de Payzum a esa misma URL.

Cómo se engancha al checkout. Cuando el storefront llama a addPaymentToOrder, createPayment() crea una factura de Payzum para el código del pedido. Convierte las unidades menores de Vendure en una cadena decimal exacta. Devuelve el pago como Authorized, con la URL del checkout en metadata.public.invoiceUrl, y tu storefront redirige ahí al comprador. La guía de pagos de Vendure lo llama flujo en dos pasos: autorizar en el checkout y liquidar después. Aquí, «después» es el webhook firmado. Si Payzum rechaza la factura, por ejemplo por una clave incorrecta o un importe por debajo del mínimo de la red, el pago vuelve como Declined con el motivo en su metadata. Nada lanza errores dentro del checkout.

Cómo se confirma. El controlador verifica la firma sobre los bytes que capturó su middleware y responde 401 a todo lo falsificado, caducado o sin firmar. Con finished, liquida el pago autorizado de Payzum y el pedido pasa a PaymentSettled. En la versión actual de npm (1.2.0), el plugin además guarda en el pago la moneda, la red y el importe recibido. Solo cancela una autorización ante expired o failed después de que la API de Payzum confirme ese estado. Y si Vendure rechaza la transición, responde 503 para que Payzum reintente.

A tener en cuenta. El plugin apunta a Vendure 3.x sobre Node 20.19 o superior, y funciona con Express 4 y 5. Instálalo desde npm, que tiene la versión actual. No incluye handler de devoluciones.

Sylius 2: un gateway sobre Payment Requests

Sylius 2.0, publicado el 12 de noviembre de 2024, introdujo los Payment Requests como su nueva capa de pagos y sacó Payum a un bundle aparte. El plugin de Payzum está construido sobre Payment Requests, no sobre Payum, y sigue la estructura del plugin oficial de Stripe para Sylius.

composer require payzum/sylius-payzum-plugin

// config/bundles.php
return [
    // ...
    Payzum\SyliusPayzumPlugin\PayzumSyliusPayzumPlugin::class => ['all' => true],
];

Configuración. En el admin, ve a Configuration → Payment methods → Create y elige el gateway Payzum (crypto & stablecoins). Rellena tu API key y tu secreto de webhook, y marca Sandbox mode para usar staging. Hay dos ajustes opcionales que los otros frameworks no tienen: Pay currency fija un solo activo, como usdc, y Network fija una sola red, como polygon. Déjalos vacíos para que elija el comprador.

Cómo se engancha al checkout. El handler de captura crea la factura, pasa el payment request a processing y redirige al comprador al checkout alojado. El hash del payment request viaja como referencia de Payzum. Así, una notificación verificada se asocia a su pago sin fiarse de nada más del contenido. Cuando el comprador vuelve, la página de pago muestra el estado real, y un pago que aún se está confirmando sigue en processing.

Cómo se confirma. Las notificaciones llegan a la ruta propia de Sylius, sylius_payment_method_notify (/payment-methods/{code}). El plugin envía esa URL con cada factura, así que no hay nada que configurar en el panel. Verifica la firma sobre los bytes crudos, con ventana anti-replay. Después vuelve a comprobar el importe y la moneda de la factura contra el pago antes de completarlo. finished completa el pago, expired o failed lo marcan como fallido, y una notificación reenviada no cambia nada.

A tener en cuenta. Pide PHP 8.2 o superior y Sylius 2.x. Los importes se convierten con aritmética exacta de cadenas y el número de decimales propio de cada moneda. El repositorio incluye tests de PHPUnit para la verificación de firma, la conversión de importes y el mapeo de estados.

Cómo configurar pagos en stablecoins para headless commerce, paso a paso

Sea cual sea tu framework, la puesta en marcha tiene la misma forma. La mayor parte del tiempo se va en los pasos 5 y 6.

1. Revisa tu stack. Necesitas Medusa v2, Saleor 3.20+, Vendure 3.x o Sylius 2.x. Para los paquetes de Node, comprueba que usas Node 20.19 o superior; para Sylius, PHP 8.2 o superior. Tu endpoint de webhook tiene que ser accesible por HTTPS desde internet. Un staging detrás de autenticación básica o de una lista de IPs nunca recibirá respuesta.
2. Configura tu cuenta de comercio en Payzum. Regístrate en merchant.payzum.com y añade la wallet donde quieres cobrar. Elige los tokens que aceptas, por ejemplo USDT y USDC en Solana, Base y Polygon. Después crea una API key y apunta tu secreto de webhook (IPN). Staging tiene sus propias claves.
3. Instala la integración. Es npm install para Medusa y Vendure y composer require para Sylius. Para Saleor, es el manifiesto alojado o un despliegue propio.
4. Configúrala. Pega la clave, el secreto y el entorno. En Medusa y Vendure, pon también la URL de callback en la integración y en el panel de Payzum. Saleor y Sylius envían la suya con cada factura. En Saleor, pon el canal en el flujo CHARGE. En Medusa, activa el provider en tus regiones.
5. Conecta la redirección del storefront. Lee la URL de checkout que devuelve tu framework y manda ahí al comprador. Es invoiceUrl en los datos de sesión de Medusa, data.payzum.paymentUrl en Saleor, metadata.public.invoiceUrl en Vendure y la redirección de captura en Sylius. Tu página de retorno debe mostrar el estado del pedido, no crearlo.
6. Prueba en staging. Paga un pedido de prueba. Después paga otro y cierra la pestaña antes de que se confirme: el pedido tiene que quedar pagado igual. Reenvía una notificación y comprueba que no cambia nada. Paga de menos una factura y comprueba que el pedido no se envía.
7. Sal a producción. Cambia a tu clave y tu secreto de producción, y paga un pedido real pequeño.

Lo que estas integraciones no hacen

• No hay devoluciones desde el framework. Un pago en stablecoins confirmado es final. Si devuelves, envías las stablecoins desde tu wallet y lo registras en tu panel.
• No hay cobros recurrentes automáticos. La cripto la empuja el comprador desde su wallet y no se puede «tirar» de ella. Para ingresos recurrentes, mira suscripciones cripto sin contracargos.
• Los pagos parciales esperan. Una factura pagada de menos sigue abierta hasta que el comprador paga el resto o caduca. Ninguna integración la marca como pagada.
• No están en ningún marketplace. Al 4 de octubre de 2026, las integraciones se distribuyen por GitHub, npm, Packagist y el manifiesto alojado de Saleor de Payzum.

Casos de uso: tiendas headless que cobran en USDT y USDC

La fontanería es la misma para todos. Lo que cambia es qué parte se paga sola.

• Una marca de moda en Valencia sobre Medusa. Tiene un storefront en Next.js, y un tercio de sus pedidos llega de México, Colombia y Estados Unidos. Un pedido de 120 € pagado con una tarjeta estadounidense en dólares cuesta 6,43 € según la tarifa publicada de Stripe, y eso antes de cualquier disputa. Si se paga en USDC sobre Base, la sesión se captura con el webhook firmado. Medusa completa el carrito aunque el comprador cierre la pestaña. El dinero está en la wallet de la marca segundos después de la confirmación.
• Un retailer de electrónica sobre Saleor, con un canal por país. Tiene canales para Argentina, Chile y Uruguay, y el equipo no quiere operar otro servicio, así que instala la app desde el manifiesto alojado de Payzum. Muestra la opción en stablecoins en sus storefronts del Cono Sur y pone esos canales en el flujo CHARGE. Un comprador en Buenos Aires, que ya ahorra en dólares digitales, paga en USDT sobre Solana, confirmado en unos 0,4 segundos. Si alguien paga de menos, la transacción queda en «acción requerida» y el pedido nunca llega al almacén.
• Una distribuidora de equipos de café en Medellín sobre Vendure. Vende máquinas de espresso a cafeterías de Centroamérica y el Caribe, con pedidos de unos 4.000 dólares. Antes cobraba por transferencia internacional: días de espera y montos que llegaban recortados por bancos intermediarios. Ahora la cafetería paga en USDT sobre Polygon, y el pago en Vendure pasa de Authorized a Settled cuando llega el webhook firmado. El almacén solo prepara pedidos liquidados, así que nada sale a crédito.
• Una agencia Symfony de Madrid que monta una tienda Sylius 2 para un comercio de audio y vinilos. La gestoría del cliente quiere un único activo, así que la agencia fija Pay currency en usdc y Network en polygon. La ruta de notificación es la de Sylius, así que no hay webhook que configurar. Antes de salir a producción, la agencia revisa los tests y el verificador de webhooks del plugin como parte de su code review habitual.

Payzum en un stack headless frente a un plugin de tarjeta, una pasarela cripto custodial y una integración propia

Comparación con criterios neutrales. Las cifras de tarjeta son la tarifa publicada de Stripe en euros, consultada el 4 de octubre de 2026.

La mayoría de tiendas no reemplaza nada. Añade las stablecoins como un método de pago más, junto a las tarjetas, y deja elegir al comprador.

Objeciones frecuentes, respondidas

«Preferimos llamar nosotros a la API».

Es razonable para un flujo poco común, y para eso existen los SDKs oficiales. Pero lee primero la lista de fallos de arriba. Las integraciones de framework son el mismo SDK más la captura del cuerpo crudo, las claves de idempotencia, la protección ante eventos tardíos y la conversión de unidades, todo ya hecho. Con la licencia MIT, también puedes hacer un fork y cambiar solo la parte que necesitas.

«Nuestro equipo de operaciones necesita un botón de devolución».

Para cripto no lo tendrá. Nadie puede revertir un pago en stablecoins, y por eso mismo no existen los contracargos. Una devolución se convierte en un pago saliente desde tu wallet, que registras en tu panel. La mayoría de tiendas mantiene las tarjetas para quien espera devoluciones con un clic y ofrece stablecoins a quien quiere pagar así.

«¿Y la volatilidad?».

Tus precios siguen en la moneda de tu tienda. La factura se crea por el total del pedido y el comprador paga el equivalente en la moneda que elija. Si solo aceptas USDT y USDC, recibes dólares digitales. Si también aceptas otras criptos, la auto-conversión opcional a USDC o USDT está disponible en la mayoría de las redes soportadas. USDT vs USDC para pagos te ayuda a elegir entre las dos.

«¿Sobrevivirá a la próxima actualización del framework?».

Las integraciones declaran los rangos a los que apuntan: Medusa ^2.0.0, Vendure ^3.0.0, el core de Sylius ^2.0 y Saleor 3.20 o superior. Las APIs de pago de los frameworks cambian entre versiones menores, así que prueba en staging antes de cada actualización, como con cualquier código de pagos. Como el código es público, tu equipo puede revisar un diff en lugar de esperar a un proveedor.