How to validate affiliate URLs and checkout return paths

ShopTools AI lets people find a promo code and separately open the store. Designing an affiliate route requires more than an HTTPS prefix: the application needs to establish what it may open and where a return is allowed.

This is a URL-validation model for developers, not a list of guarantees provided by the current ShopTools resolver. A parsed address does not establish that an external redirect chain will end at the expected page.

Parse the address structurally

Use a URL parser and an explicit scheme allowlist. For ordinary web navigation, that means HTTP(S), with HTTPS required where supported. Do not try to repair an unparseable address by guessing.

Decide separately how to handle credentials in URLs, unexpected ports and nested destinations. Allowing a scheme does not authorize every combination of the other components.

Keep the tracker distinct from the merchant

Store merchant identity separately from the affiliate URL. A destination may come from a verified explicit field, a product URL or a documented parameter used by a known network.

Limit nested decoding and validate each result. If the destination cannot be established, preserve that uncertainty. Do not substitute the tracking domain for the merchant just to enable a button.

Begin domain matching with an exact allowed hostname. Permit subdomains through an explicit rule. A simple string suffix check, or taking the last two labels, does not establish that two hosts belong to one merchant.

Internationalized names need normalization and display checks. Similar appearance is not proof of identity; an ambiguous match should be reviewed rather than accepted.

Authorize the return path separately

A return URL is not trusted merely because it accompanies a valid offer. Check the permitted merchant and the purpose of the path. Permission to return to checkout is not permission to open any page.

Retain query parameters through a narrow allowlist. Keep tokens, email addresses and order details out of analytics. If removing a sensitive parameter makes a safe return impossible, do not store that return address.

Record navigation intent separately from arrival. Constructing a URL or starting a visit does not establish that the merchant was reached. This distinction supports diagnosis, not an assumption that a purchase occurred.

Turn the boundaries into tests

• Reject disallowed schemes and nested destinations that exceed the decoding limit.
• Do not treat an unresolved tracking host as a merchant host.
• Reject another merchant's return URL and an unapproved subdomain.
• Do not merge visually similar internationalized names solely on appearance.
• Keep sensitive parameters out of diagnostic records.

External redirects and merchant conditions can change after validation. A valid URL therefore authorizes a specific action in a known context; it does not promise a safe purchase, a discount or a commission.