To accept a domain-forwarding change in a customer portal, test the root URL, a real subpage and a URL with campaign parameters. Record the final destination for each. A working homepage redirect does not prove that old links still reach the right content.
This checklist is for businesses selling domain subscriptions and the customers managing those domains. It is a proposed acceptance test, not a report of a test performed in a customer account.
Confirm the Portal Can Manage This Domain
PayRequest's Cloudflare integration documentation describes forwarding from a domain subscription's Forwarding tab. The documented prerequisites are a domain product with linked registration, an active Cloudflare zone and a connected integration. The integration uses OpenProvider for the domain-registration workflow. If the tab is missing, have the merchant check those conditions before changing DNS elsewhere.
The Customer Portal documentation now groups supported services under My services. Open the domain's management page there. This shop portal is separate from the lighter payment-page account area; do not promise every account the same domain controls.
Write the Expected Destinations First
Use two domains you control. In this illustrative migration, old.example forwards to new.example. Select Preserve Path only when the destination has matching paths; select Preserve Query String when the destination needs the incoming parameters. The portal documents both switches and permanent 301 or temporary 302 redirects. Cloudflare also documents query preservation in redirect rules.
Complete this sheet before saving a change:
| Source to test | Expected final destination | What a failure suggests |
|---|---|---|
| https://old.example/ | https://new.example/ | Wrong target or forwarding unavailable |
| https://old.example/contact | https://new.example/contact | Path dropped, or matching page absent |
| https://old.example/?utm_source=invoice | https://new.example/?utm_source=invoice | Query handling differs from the agreed rule |
| https://old.example/contact?ref=client | Same path and ref on new.example | Combined path/query handling needs review |
| https://www.old.example/contact | Agreed www destination | Hostname coverage needs separate verification |
The www row is a test requirement, not a claim that the integration configures every hostname automatically. For a redirect to one social profile, preserving /contact may be inappropriate: agree on the profile URL as the destination instead.
Run the Five Checks and Keep a Rollback Note
- Save the previous target, redirect type and both preservation settings in the handoff note.
- Configure forwarding for the intended domain, then open every source URL in a fresh browser session.
- Compare the address bar and actual page with the sheet. A destination returning an error page fails even if forwarding occurred.
- Check HTTPS and the www case separately. If there is a loop or unexpected extra hop, ask the merchant to inspect the rules rather than repeatedly changing the target.
- Record the test time, final URL, result and owner for each failed row. Restore the agreed previous settings if the new destination is not ready, then retest.
Use invented, non-sensitive campaign values for testing. Query preservation keeps URL parameters; it does not prove that an analytics tool attributed the visit or that consent settings allowed tracking.
Accept the Change With a Specific Handoff
Example handoff: “Root and /contact passed. The combined ref test passed. The www address still fails HTTPS. Keep the change open until the merchant resolves hostname coverage.” This is more actionable than “forwarding works.”
For a temporary campaign, record its end date and who will restore the destination. For a permanent move, maintain a separate content-migration plan: a portal redirect setting alone does not guarantee search rankings or the transfer of every old URL.
Use the PayRequest Customer Portal to give eligible domain customers the documented management workflow, with this acceptance sheet alongside it. Review Services & integrations for the supported service portfolio.
For the broader client-billing handoff, read billing hosting clients.
Ready to configure your workflow? Create a PayRequest account.
Prepared by the PayRequest Team with AI assistance. Product documentation reviewed on 11 October 2026. The URLs and acceptance sheet are original illustrative examples; no customer outcome is claimed.
