Academia › Publicar › Dominio y correo

El botón de cobro va en tu web, y casi nunca te pide tocar el dominio

Sabes si tu botón de pago necesita algo en tu dominio o no, y si te lo pide, lo añades sin pisar lo que ya tenías en el DNS.

Por Yodai · Publicado el 6 de septiembre de 2026 · Actualizado el 12 de octubre de 2026

Tienes la web publicada y el WhatsApp del negocio en marcha. Ahora quieres cobrar sin que el cliente tenga que llamarte o mandarte un bizum a mano: un botón de «Pagar» en la página del servicio, o un enlace que se manda por WhatsApp cuando alguien pregunta precio.

La primera pregunta no es qué pasarela usar. Es dónde vive ese botón: en tudominio.com, en una carpeta como tudominio.com/pagar, o en un subdominio nuevo, tipo pagos.tudominio.com.

Y la segunda: si ese cobro te pide añadir algo en tu dominio, cómo lo pones sin pisar lo que ya funciona. Con un simple enlace de pago no te pide nada. En otros casos sí, y ahí un registro mal puesto no rompe el cobro: rompe lo que ya tenías, como el correo, y tarda en notarse.

¿Mismo dominio o subdominio para el cobro?

La mayoría de los botones de pago no son una página que tú construyas. Son un enlace: el cliente pulsa, sale a la pantalla de pago de Stripe, de PayPal o del TPV virtual de tu banco, paga, y vuelve a tu web. Ese enlace se pone en cualquier página de tu web y no te obliga a tocar tu dominio. Ahí no hace falta ningún subdominio, y con los enlaces de pago de Stripe, Apple Pay funciona sin configurar nada más.

Es distinto si metes el formulario de cobro dentro de tu propia página, con sus campos de tarjeta y tu diseño, o si quieres que la pantalla de pago de tu pasarela lleve una dirección tuya. Si el formulario va dentro de tu página, Apple Pay pide registrar en tu pasarela cada dominio exacto donde se ve el botón: tudominio.com y, si lo usas, pagos.tudominio.com, cada uno por su cuenta. Y si quieres la pantalla de pago de Stripe con tu dirección, Stripe solo lo permite en un subdominio, nunca en una carpeta como tudominio.com/pagar, y lo cobra aparte. Un subdominio no hereda nada de lo que tenías montado: hay que apuntarlo y verificarlo por su cuenta.

Si el cobro te pide una fila en el DNS, se añade sin borrar las que ya tienes

Cuando una pasarela te pide filas en el DNS, como para la pantalla de pago con tu dirección, una suele ser un TXT que demuestra que el dominio es tuyo, igual que el que pide Meta cuando quiere verificar tu dominio. En el caso de Stripe, ese TXT cuelga del subdominio (algo como _acme-challenge.pagos), no del dominio raíz. Otros servicios lo cuelgan del dominio raíz, el que en el panel aparece como @, donde ya suelen vivir otros TXT, como el SPF de tu correo.

Ahí se equivoca mucha gente que hace esto sin ayuda. Abre el panel DNS, ve un campo TXT con un valor ya puesto, y lo sustituye por el nuevo pensando que solo cabe uno. No es cierto: un mismo nombre admite varios registros TXT a la vez, uno detrás de otro, y todos se leen. Lo que hay que hacer es añadir una línea nueva, no editar la que ya funciona.

Un detalle que se te va a cruzar al añadir cualquier TXT: no todos los paneles DNS llaman igual al campo del nombre. Unos ponen @, otros dejan el campo en blanco para el dominio raíz, y otros piden directamente tudominio.com escrito entero. Es el mismo registro con tres formas distintas de escribirlo, y si pones el nombre que no toca, el TXT queda colgado de un subdominio fantasma que nadie comprueba, y la verificación falla sin ningún mensaje de error claro. Antes de dar por hecho que algo no funciona, mira primero si el nombre del registro es el que tu proveedor espera para el dominio raíz.

Cuándo el subdominio sí necesita su propia prueba

Si el formulario de cobro va dentro de pagos.tudominio.com y quieres Apple Pay, la comprobación no es un TXT. Con Stripe, registras ese dominio en su apartado de dominios para métodos de pago. Si tu pasarela no lo hace por ti, la comprobación de Apple consiste en subir un archivo a una ruta fija de ese dominio: pagos.tudominio.com/.well-known/apple-developer-merchantid-domain-association.

La trampa está en qué dominio registras. Cuenta el dominio exacto que carga el botón de pago: si el botón vive en pagos.tudominio.com, es ese el que registras, o donde va el archivo, no solo el dominio principal.

No es solo Apple Pay. Stripe también pide registrar el dominio para otros métodos, como Google Pay o Link, cuando el formulario va dentro de tu página, aunque sin archivo: si el botón vive en el subdominio, es el subdominio el que registras.

Si más adelante cambias el cobro de sitio

El botón de cobro no es solo un enlace estético. En Redsys, por ejemplo, la URL del comercio está dada de alta en el TPV virtual, y las notificaciones de pago completado apuntan a esa URL exacta. Si empezaste con el botón en tudominio.com/pagar y seis meses después lo mueves a pagos.tudominio.com, no basta con cambiar el enlace en la web: hay que actualizar la URL de notificación en el panel del banco o del procesador, o los pagos se completarán sin que tu sistema se entere.

Mantener un subdominio de cobro tiene un coste que no se ve el primer día: cada vez que renueves el certificado, cada vez que muevas de proveedor de hosting, hay una pieza más que revisar. Si el botón fuera solo un enlace, ese coste no existiría. Por eso conviene decidir esto una vez, con cabeza, y no ir cambiando el sitio del botón cada vez que se prueba un procesador nuevo.

Con esto, el cobro ya tiene su sitio decidido y, si la necesitaba, su prueba puesta sin tocar lo que ya tenías en el DNS. Lo que queda por resolver es qué pasa el día que ese negocio entre en un mercado nuevo: si sigue en el mismo dominio o pide uno propio.

Ya sabes cuándo el cobro pide subdominio propio y cuándo no. Esa misma pregunta, si va con lo que ya tienes o necesita casa aparte, vuelve a aparecer con el idioma de tu web y con una marca nueva que quieres abrir, y la respuesta no es la misma para las dos.

En Yodai conectas a tu web el dominio que ya tienes y sigue registrado donde está, a tu nombre. Mira cómo va el dominio propio para tu página web.