Academia › Publicar › Dominio y correo
El botón de cobro va en tu dominio, salvo que Apple Pay te obligue a separarlo
Sabes si el botón de pago necesita subdominio propio o no, y has añadido su verificación sin pisar la del WhatsApp que ya tenías puesta.
Ya resolviste esa pregunta para el botón de cobro: mismo dominio o subdominio propio según a quién obligue quién. Ahora te toca aplicarla a dos casos que no se parecen tanto como crees. Ya tienes la web publicada y el número de WhatsApp verificado. 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, la que se le olvida a casi todo el mundo: el cobro también tiene que demostrar que el dominio es tuyo, igual que hizo el número de WhatsApp. Si esa prueba se pone mal, no se rompe el cobro. Se rompe la del WhatsApp, 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 Stripe, Mercado Pago o Redsys, paga, y vuelve a tu web. Ese enlace cuelga de cualquier URL sin que el dominio del cliente cambie nunca durante todo el trayecto. Ahí no hace falta ningún subdominio.
Es distinto si vas a alojar tú mismo el formulario de cobro, con sus propios campos de tarjeta y su propio diseño, o si el procesador exige un dominio propio para activar ciertas formas de pago. Apple Pay es el caso típico: pide comprobar el dominio exacto donde se ejecuta el botón, no uno cualquiera de tu web. Ahí sí entra en juego un subdominio, con lo que ya sabes de antes: no hereda nada de lo que tenías montado, hay que apuntarlo y verificarlo por su cuenta.
- No añades ningún registro DNS nuevo: el certificado y el hosting ya están puestos
- El cliente ve tu dominio en todo el proceso, hasta el segundo antes de saltar al procesador
- La verificación del cobro se añade en el mismo dominio raíz donde ya tienes la del WhatsApp
- Url de checkout con marca propia, útil si mañana cambias de procesador y no quieres que el enlace cambie
- Solo compensa si vas a alojar tú el formulario, o el procesador exige un dominio dedicado para una función de pago concreta, como Apple Pay
Cual elijo: Si el botón es un enlace que abre la pantalla del procesador -Payment Link de Stripe, Checkout Pro de Mercado Pago-, va en tu dominio: no hay ninguna ventaja técnica en separarlo y sí una complicación de más que mantener. Reserva el subdominio para cuando alojes tú el formulario o el procesador te obligue a un dominio dedicado para activar una función de pago concreta.
La verificación del cobro no borra la del WhatsApp -si sabes cómo se pone
El procesador de pago, para activarte ciertas funciones, te va a pedir lo mismo que te pidió Meta para el número de WhatsApp: un registro TXT en el DNS que demuestre que el dominio es tuyo. El tipo de registro es el mismo, TXT, y muchas veces el nombre donde se cuelga también coincide: el dominio raíz, el que en el panel aparece como @.
Ahí se equivoca la mitad de la gente que hace esto sin ayuda. Abre el panel DNS, ve un campo TXT con el valor del WhatsApp ya puesto, y lo sustituye por el valor de Stripe 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 el TXT del procesador: 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 decides alojar el cobro en pagos.tudominio.com porque vas a activar Apple Pay o Google Pay, el procesador no te pide un TXT. Te pide subir un archivo -domain-association o similar- en una ruta concreta del dominio: tudominio.com/.well-known/apple-developer-merchantid-domain-association.
La trampa está en dónde lo subes. Ese archivo tiene que estar en el mismo host que carga el botón de pago. Si el botón vive en pagos.tudominio.com, el archivo va ahí, no en el dominio principal.
No es solo Apple Pay. Google Pay pide el mismo tipo de comprobación cuando activas el pago con un toque desde Android, y el error de dónde subir el archivo es idéntico: si el botón vive en el subdominio, la prueba también.
Apple comprueba el archivo en el mismo dominio exacto donde se ejecuta el botón, no en el dominio raíz
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 para activar Apple Pay, 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 su prueba puesta sin tocar la del WhatsApp. 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.
- Decidiste si el botón de cobro va en tu dominio o en un subdominio propio, y por qué
- El TXT de verificación del cobro está añadido junto al del WhatsApp, no encima
- Si usas Apple Pay o Google Pay, el archivo de verificación vive en el mismo host que carga el botón
- Sabes qué revisar primero si un cliente avisa de que el WhatsApp aparece sin verificar
Ponte a prueba
Responde antes de abrir cada una. Si alguna se te resiste, vuelve al apartado que la explica.
1. Usas un enlace de Mercado Pago que abre su propia pantalla al pulsar "Pagar". ¿Te hace falta un subdominio para el cobro?
No. Es un enlace externo: el cliente nunca deja de ver tudominio.com hasta que salta a la pantalla de Mercado Pago. El botón puede ir en cualquier página de tu web sin tocar el DNS más allá de lo que ya tienes.
2. Añades el TXT de Stripe y dos días después un cliente te escribe que el WhatsApp del negocio aparece "sin verificar". ¿Qué revisas primero?
El panel DNS: lo más probable es que al poner el TXT de Stripe se haya sustituido el de WhatsApp en vez de añadirse como fila nueva. Restauras el TXT del WhatsApp y dejas los dos conviviendo en el mismo nombre.
3. Vas a alojar el formulario de cobro en pagos.tunegocio.com para activar Apple Pay. ¿Dónde subes el archivo de verificación de Apple?
En pagos.tunegocio.com, el mismo host que carga el botón, no en tunegocio.com. Apple valida el archivo contra el dominio exacto donde se ejecuta el pago, no contra el dominio raíz.
Ya sabes cuándo el cobro pide subdominio propio y cuándo no. Esa misma pregunta -¿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.