Fix premium domain pricing for aftermarket listings#68
Conversation
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 SummaryThis PR fixes a real pricing bug where premium/aftermarket domains were quoted at the standard registry TLD price because
Confidence Score: 4/5Safe 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
Reviews (2): Last reviewed commit: "(fix): soft-fail availability lookup in ..." | Re-trigger Greptile |
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.
What does this PR do?
Fixes premium (aftermarket) domains being quoted at the base TLD price. Name.com's
:getPricingendpoint only covers standard registry registrations, so a premium listing likeappwrite.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 (premiumflag set, or a non-registrationpurchaseTypesuch asaftermarket), itspurchasePrice/renewalPriceoverride the registry pricing and the result is marked premium.NameCom::suggest()treats non-registrationpurchase types as premium and now exposesrenewalPriceandpurchaseTypeper suggestion.purchase()accepts an optionalpurchasePriceparam (backward-compatible), which registrars require for premium registrations — mirroring the existingtransfer()support. Wired throughRegistrar,Adapter,NameCom(request payload),OpenSRS(existingregister()param) andMock.getPrice()no longer cachesnullrenewal/transfer prices as0.0; a cachednullnow raisesPriceNotFoundExceptionas the live path does.Test plan
composer lint,composer check(PHPStan level 4) passapi.dev.name.comnb.xyz→ $3,807.69premium: 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 forappwrite.xyz(premium: true, ~$2,242) via the cloud suggestions endpoint.Related
purchasePriceat purchase confirmation and re-validating the quoted price) depends on this being released and bumped.