Skip to content

Fix premium domain pricing for aftermarket listings#68

Merged
ChiragAgg5k merged 2 commits into
mainfrom
fix-premium-domain-pricing
Jul 6, 2026
Merged

Fix premium domain pricing for aftermarket listings#68
ChiragAgg5k merged 2 commits into
mainfrom
fix-premium-domain-pricing

Conversation

@ChiragAgg5k

Copy link
Copy Markdown
Member

What does this PR do?

Fixes premium (aftermarket) domains being quoted at the base TLD price. Name.com's :getPricing endpoint only covers standard registry registrations, so a premium listing like appwrite.xyz (~$2,242 one-time acquisition fee) was priced at the base .xyz promo price of $1.99.

Changes

  • NameCom::getPrice() now also consults :checkAvailability. When the domain is a purchasable premium listing (premium flag set, or a non-registration purchaseType such as aftermarket), its purchasePrice/renewalPrice override the registry pricing and the result is marked premium.
  • NameCom::suggest() treats non-registration purchase types as premium and now exposes renewalPrice and purchaseType per suggestion.
  • purchase() accepts an optional purchasePrice param (backward-compatible), which registrars require for premium registrations — mirroring the existing transfer() support. Wired through Registrar, Adapter, NameCom (request payload), OpenSRS (existing register() param) and Mock.
  • Cache fix: getPrice() no longer caches null renewal/transfer prices as 0.0; a cached null now raises PriceNotFoundException as the live path does.

Test plan

  • composer lint, composer check (PHPStan level 4) pass
  • Mock suite and NameCom integration tests (availability/suggest/price) pass against api.dev.name.com
  • Live check on dev: registry premium nb.xyz → $3,807.69 premium: true; standard domains unchanged. The aftermarket merge path can't be reproduced in name.com's dev sandbox (no aftermarket listings there); verified the data shape against production search results for appwrite.xyz (premium: true, ~$2,242) via the cloud suggestions endpoint.

Related

  • Consumer-side change in the cloud repo (passing purchasePrice at purchase confirmation and re-validating the quoted price) depends on this being released and bumped.

Name.com's getPricing endpoint only returns standard registry
registration pricing, so premium aftermarket listings (e.g. short or
brandable domains sold at a one-time acquisition fee) were quoted at
the base TLD price — a domain selling for ~$2,200 was priced at $1.99.

- NameCom::getPrice() now consults checkAvailability and, when the
  domain is a premium listing (premium flag or a non-registration
  purchaseType), uses its purchasePrice/renewalPrice as authoritative
- NameCom::suggest() treats non-registration purchase types as premium
  and exposes renewalPrice and purchaseType per suggestion
- purchase() accepts an optional purchasePrice (required by registrars
  for premium domains), wired through Registrar, NameCom (request
  payload, mirroring transfer()), OpenSRS (existing register() param)
  and Mock
- getPrice() no longer caches null renewal/transfer prices as 0.0;
  they now correctly raise PriceNotFoundException
@greptile-apps

greptile-apps Bot commented Jul 6, 2026

Copy link
Copy Markdown

Greptile Summary

This PR fixes a real pricing bug where premium/aftermarket domains were quoted at the standard registry TLD price because :getPricing only covers vanilla registry registrations. It also adds backward-compatible purchasePrice threading through the full call chain.

  • NameCom::getPrice() now issues a secondary :checkAvailability call on every cache miss to merge the correct purchasePrice/renewalPrice; the cache fix also corrects the previous behaviour of storing 0.0 for null prices.
  • NameCom::suggest() now includes renewalPrice and purchaseType per suggestion using the same aftermarket-premium detection logic.
  • purchase() accepts an optional ?float $purchasePrice across Registrar, Adapter, NameCom, OpenSRS, and Mock, mirroring the existing transfer() support.

Confidence Score: 4/5

Safe to merge for standard domains; the happy-path premium fix is correct, but the mandatory second API call on every cache miss is a reliability concern worth addressing before high-traffic use.

The getPrice() change unconditionally issues a second network call to checkAvailability on every cache miss, meaning a rate-limit or transient error on that endpoint now degrades pricing for all domains, not just premium ones.

src/Domains/Registrar/Adapter/NameCom.php — specifically the getPrice() double-call strategy and its error handling interaction with caching.

Important Files Changed

Filename Overview
src/Domains/Registrar/Adapter/NameCom.php Core pricing logic updated to merge availability data for premium aftermarket domains; adds a mandatory second API call on every cache miss
src/Domains/Registrar.php Backward-compatible addition of optional purchasePrice parameter to purchase(); cleanly threaded to the adapter layer
src/Domains/Registrar/Adapter.php Abstract purchase() signature updated to accept optional purchasePrice; no logic changes
src/Domains/Registrar/Adapter/Mock.php purchase() updated to accept purchasePrice to satisfy interface; parameter unused as expected for a mock
src/Domains/Registrar/Adapter/OpenSRS.php purchase() properly wires new purchasePrice through to the existing register() call; straightforward change

Reviews (2): Last reviewed commit: "(fix): soft-fail availability lookup in ..." | Re-trigger Greptile

Comment thread src/Domains/Registrar/Adapter/NameCom.php Outdated
Comment thread src/Domains/Registrar/Adapter/NameCom.php
Per review: a transient checkAvailability failure no longer breaks
getPrice() when getPricing already returned usable data. The premium
merge is skipped and the result is not cached, so the merge is retried
on the next request. Rate limits still propagate. Also documented why
a renewal price of 0 (name.com's 'no data') must not override the
registry renewal price.
@ChiragAgg5k ChiragAgg5k merged commit 73bb46e into main Jul 6, 2026
6 checks passed
@ChiragAgg5k ChiragAgg5k deleted the fix-premium-domain-pricing branch July 6, 2026 03:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants