Academy › Publishing › Domain and email
The payment button lives on your website, and it almost never requires touching the domain.
You'll know whether your payment button needs anything on your domain, and if it does, you'll add it without overwriting what you already had in the DNS.
By Yodai · Published September 6, 2026 · Updated October 12, 2026
Your website is live and your business WhatsApp is up and running. Now you want to get paid without the customer having to call you or manually send you a Venmo payment: a "Pay" button on your service page, or a link you send over WhatsApp when someone asks about pricing.
The first question isn't which payment processor to use. It's where that button lives: at yourdomain.com, in a folder like yourdomain.com/pay, or on a new subdomain, like payments.yourdomain.com.
And the second: if that payment setup asks you to add something to your domain, how to do it without breaking what already works. A simple payment link doesn't ask for anything. In other cases it does, and there, a record set up wrong doesn't break the payment; it breaks what you already had, like your email, and it takes a while to notice.
Same domain or subdomain for payments?
Most payment buttons aren't a page you build yourself. They're a link: the customer clicks, lands on the payment screen for Stripe, PayPal, or your bank's virtual terminal, pays, and comes back to your site. That link goes on any page of your website and doesn't require you to touch your domain at all. No subdomain is needed there, and with Stripe payment links, Apple Pay works without any extra setup.
It's different if you embed the checkout form right in your own page, with its own card fields and your design, or if you want your payment processor's checkout screen to show your own address. If the form is embedded in your page, Apple Pay requires you to register every exact domain where the button appears with your processor: yourdomain.com and, if you use it, pay.yourdomain.com, each one separately. And if you want Stripe's checkout screen to show your own address, Stripe only allows that on a subdomain, never on a folder like yourdomain.com/pay, and it charges extra for it. A subdomain doesn't inherit anything from what you already had set up: you have to point it and verify it on its own.
- You don't add any new DNS record: the certificate and hosting are already in place
- The customer sees your domain the whole time, right up until the moment they're redirected to the processor
- If the form is embedded in your page, you register that domain with your processor for Apple Pay, without touching your DNS
- Checkout screen with your own address: on Stripe it costs extra and only works on a subdomain, not a folder
- It adds two new rows to your DNS, attached to the subdomain, that don't touch the ones on your root domain
Which one to choose: If the button is a link that opens your processor's checkout screen, like a Stripe or PayPal payment link, it goes on your site as is: there's no technical advantage to separating it, just one more complication to maintain. Save the subdomain for when you want the checkout screen to show your own address and it's worth paying for.
If the payment setup asks for a DNS row, you add it without deleting the ones you already have
When a processor asks for DNS rows, like for the checkout screen with your own address, one of them is usually a TXT record that proves the domain is yours, the same kind Meta asks for when it wants to verify your domain. With Stripe, that TXT record hangs off the subdomain (something like _acme-challenge.pay), not the root domain. Other services attach it to the root domain, the one that shows up in your panel as @, where other TXT records usually already live, like your email's SPF.
This is where a lot of people doing this on their own get it wrong. They open the DNS panel, see a TXT field with a value already in it, and replace it with the new one, thinking only one fits. That's not true: the same name can hold several TXT records at once, one after another, and all of them get read. What you need to do is add a new line, not edit the one that's already working.
One detail you'll run into when adding any TXT record: not every DNS panel labels the name field the same way. Some use @, others leave the field blank for the root domain, and others ask you to type out yourdomain.com in full. It's the same record written three different ways, and if you enter the wrong name, the TXT record ends up attached to a phantom subdomain nobody checks, and verification fails without any clear error message. Before assuming something's broken, first check whether the record name matches what your provider expects for the root domain.
When the subdomain does need its own verification
If your checkout form is embedded in pay.yourdomain.com and you want Apple Pay, the verification isn't a TXT record. With Stripe, you register that domain in its payment methods domains section. If your processor doesn't handle it for you, Apple's verification involves uploading a file to a fixed path on that domain: pay.yourdomain.com/.well-known/apple-developer-merchantid-domain-association.
The trap is in which domain you register. What counts is the exact domain that loads the payment button: if the button lives on pay.yourdomain.com, that's the one you register, or where the file goes, not just the main domain.
It's not just Apple Pay. Stripe also requires you to register the domain for other methods, like Google Pay or Link, when the form is embedded in your page, though without a file: if the button lives on the subdomain, that's the subdomain you register.
What counts is the exact domain where the button appears, not just the root domain
If you move your checkout later on
The payment button isn't just a decorative link. With a gateway like Authorize.net, for example, your merchant URL is set up in their virtual terminal, and completed-payment notifications point to that exact URL. If you started with the button at yourdomain.com/pay and six months later move it to pay.yourdomain.com, changing the link on your site isn't enough: you have to update the notification URL in your bank's or processor's panel, or payments will go through without your system ever knowing.
Keeping a payment subdomain comes with a cost that's not obvious on day one: every time you renew your certificate, every time you switch hosting providers, that's one more thing to check. If the button were just a link, that cost wouldn't exist. That's why it's worth deciding this once, thoughtfully, instead of moving the button every time you try a new processor.
With that, your payment setup has its place settled and, if it needed one, its verification in place without touching what you already had in your DNS. What's left to figure out is what happens the day that business expands into a new market: whether it stays on the same domain or gets one of its own.
- You decided whether the checkout button goes on your domain or on its own subdomain, and why
- If your processor asked for a TXT record, it's added as a new row alongside the ones you already had, not on top of them
- If the form is embedded in your page, every domain that shows Apple Pay or Google Pay is registered with your processor
- You know what to check first if, after touching your DNS, your emails start landing in spam
Test yourself
Answer before opening each one. If one gives you trouble, go back to the section that explains it.
1. You use a Stripe payment link that opens its own screen when someone clicks "Pay." Do you need a subdomain for the payment?
No. It's an external link: your customer never leaves yourdomain.com until they're sent to the Stripe screen. The button can go on any page of your site without touching your DNS beyond what you already have.
2. You add a TXT record your payment gateway asks for, and two days later your emails are landing in your customers' spam folders. What do you check first?
The DNS panel. Chances are that adding the new TXT record overwrote your email's SPF record instead of being added as a new row. Restore the SPF record exactly as it was and let both records live under the same name.
3. You're putting the payment form on pay.yourbusiness.com and you want Apple Pay to show up. Which domain do you register for Apple Pay?
payments.yourbusiness.com, the same host that loads the button. Registering just yourbusiness.com isn't enough. What counts is the exact domain where the button appears, not the root domain.
Now you know when checkout needs its own subdomain and when it doesn't. That same question, whether it fits with what you already have or needs its own setup, comes up again with your site's language and with a new brand you want to launch, and the answer isn't the same for both.
In Yodai you connect the domain you already have to your site, and it stays registered where it is, in your name. See how your own domain for your website works.
NextThe language hangs off your domain, a new brand doesn't