Skip to main content

Why we verify your domain

Your website is the public face of your product. Before we approve KYB and enable production payments, we need to confirm that the domain you list as Product website actually belongs to you. Domain verification is a one-time step per store, and the binding stays in place after KYB approval. There are two entry points — both write to the same backend state, so verifying once is enough:
  • Settings → General — verify (or re-verify) your product domain at any time, independent of KYB.
  • Settings → Business Details → Step 8 (Website URL) — inline during KYB submission. The “Submit for review” button stays disabled until the domain on this step is verified.

Verification methods

Pancake offers four ways to verify a domain. Pick whichever your stack already supports — they are equivalent.
Pick one method. Once any method succeeds, the others stop being relevant for this domain.
If your support email is already verified in Step 7 (Contact Email) and lives on the same domain as your website, Pancake automatically detects this and shows a one-click Verify domain button. Example. Support email support@acme.com (verified) + Product website https://acme.com → auto-match available.
  1. Click Verify domain.
  2. Pancake validates the email/domain pair on the server. Verification completes immediately.
If the support email is on a different domain (e.g. team@gmail.com while the site is acme.com), this option is hidden — use one of the manual methods below.

Method 2 — DNS TXT record

The most reliable method. You add a TXT record to the DNS zone for your domain.
  1. In the dashboard, click Use another method → DNS TXT.
  2. Pancake shows three values:
    • Type: TXT
    • Host / Name: _waffo-challenge (the dashboard strips the .your-domain.com suffix automatically — most providers prepend it for you)
    • Value: a one-time challenge string starting with waffo-domain-verify=…
  3. Open your DNS provider’s dashboard and add the record exactly as shown. Leave TTL at the default.
  4. Wait for propagation. Most providers publish within minutes; some (Cloudflare, Route 53) are nearly instant.
  5. Back in Pancake, click I’ve added the record. We query the public DNS for the TXT value and complete verification on success.
You can leave the TXT record in place after verification. It does no harm. If you remove it, the existing binding is unaffected — we only re-check at verification time.

Provider-specific notes

If your provider expects a fully-qualified record name, use _waffo-challenge.your-domain.com instead of just _waffo-challenge.

Method 3 — HTML <meta> tag

Useful when you can’t change DNS but you can deploy site code.
  1. In the dashboard, click Use another method → HTML meta tag.
  2. Pancake shows the snippet:
  3. Add it to the <head> of your site’s homepage (https://your-domain.com/).
  4. Deploy. Verify the tag is present in the rendered HTML — view-source must include it; tags injected only after JS execution can fail if our crawler hits before hydration. If you’re on a fully client-rendered SPA, prefer Method 2 or 4.
  5. Back in Pancake, click I’ve added the tag.

Method 4 — .well-known file

Drop a static file under a fixed path. Works on any host that serves static assets.
  1. In the dashboard, click Use another method → .well-known file.
  2. Pancake shows:
    • File URL: https://your-domain.com/.well-known/waffo-verify.txt
    • File contents: a single line starting with waffo-domain-verify=…
  3. Create the file at exactly that path. Make sure the response is 200 OK, Content-Type: text/plain (or any text-like type), and the body is the challenge value with no extra whitespace.
  4. Confirm in a browser that the URL returns the expected content.
  5. Back in Pancake, click I’ve uploaded the file.
Common mistake: deploying the file at /.well-known/waffo-verify (no extension) or returning a 301 redirect to www.your-domain.com. Both fail. Use the exact URL Pancake shows, served from the apex / canonical host you typed into the website field.

Troubleshooting

”Could not find the record / tag / file”

Recheck the value. The challenge is generated per attempt; if you hit Refresh in Pancake, the previous value is invalidated. Make sure you copied the latest one.

TXT record exists but verification still fails

DNS caches. Try dig TXT _waffo-challenge.your-domain.com (Linux/macOS) or nslookup -type=TXT _waffo-challenge.your-domain.com (Windows). If the value isn’t visible there yet, wait 5–10 minutes and retry.

The challenge expired

Each challenge has a short lifetime (the dashboard shows the exact time under the action button). If it expired, click Refresh in Pancake to issue a new one, then update your DNS / meta tag / file with the new value.

I want to change my product website later

Before KYB approval, you can revoke the current domain binding from Step 8 (Website URL) and re-verify a new one yourself. After KYB approval, changing the domain goes through review — see Changing your domain after going live below. You do it yourself in the dashboard; no support ticket is involved.

Changing your domain after going live

Once KYB is approved, your domain is part of what we reviewed, so swapping it is a reviewed change rather than a free edit. The whole flow is self-service in Settings → General.
Only the store owner or an invited admin can start a domain change, and only from the dashboard — the API does not expose this flow.

How it works

  1. In Settings → General, next to the Website field, click Change domain.
  2. Type the new domain. Pancake checks it immediately and tells you if it can’t be used — invalid format or an IP, a public email provider’s domain, the domain you already use, a domain another of your stores verified (we name the store), a domain already in use elsewhere, a request already in progress, or a waiting period you’re still inside.
  3. Prove you own the new domain using any of the four methods above. The challenge is valid for 24 hours, and starting a new one voids the previous one for this store.
  4. When verification succeeds, the page shows Verified — not in effect yet. Nothing has changed: your current domain still takes payments, your website field is untouched, and no new binding exists yet. We also probe https://<new-domain> once; if it doesn’t respond we show a warning but still let you submit.
  5. Add a note if you want (required if this exact domain was declined before), confirm once, and submit. Submit within 7 days of verifying, otherwise verify again.

While it’s under review

The request appears in our review queue alongside business verifications and is handled the same way.
  • Your current domain keeps taking payments the entire time.
  • A submitted request cannot be withdrawn, and the target domain cannot be changed. If you picked the wrong domain, wait for the decision and start a new request.
  • You’ll get an email when the request is received and again when it’s decided.

Possible outcomes

After the switch

There is a 7-day transition period: transactions that still arrive on the old domain during that window are not treated as unauthorized resale. The dashboard shows the deadline and a countdown, and we send a reminder on day 5. Point your checkout links, redirects and integrations at the new domain before it ends.
Exception — a store that went live without a verified domain. That first binding has no old domain to keep accepting, so it gets no transition period, no countdown and no day-5 reminder, and the store.domain_changed webhook carries oldDomain: null. It also starts no waiting period (see Limits below).

Limits

  • One domain change request in flight per store.
  • After a successful change you must wait 30 days before requesting another. A first binding on a store that had no verified domain does not count as a change here — it starts no waiting period, so you can request one right away.
  • After a declined request, a failed switch, or an expired verification, the next attempt is delayed — 5 minutes, then 30 minutes, then 2 hours, then 24 hours. The dashboard tells you when you can try again.
  • Your store keeps exactly one verified domain; we never hold two at once.

Programmatic / API access

If you’re verifying domains as part of an automated onboarding flow, the underlying endpoints are: Both require the merchant JWT (or API key) and the standard X-Environment header.

Next steps

After domain verification succeeds, head back to Business Details and complete the remaining steps (Step 9 onward). The Submit for review button unlocks once all steps including domain verification turn green.