Resolve a rejected transfer using its actual failure reason. A wrong authorisation code, an ownership restriction and a payment problem require different actions. A new order with the same unresolved condition usually fails again.
IN THIS ARTICLE
01 Collect the evidence from the failed request
- Record the exact domain, request time, order or job reference and current transfer state.
- Copy the error code and message without exposing the authorisation code, API key or personal documents.
- Read the current registrar and full domain status list.
- Ask whether the failure occurred before registry submission or was a registry or losing-registrar rejection.
- Confirm the billing treatment of the existing order before submitting another paid request.
02 Match the remedy to the reason
- Invalid authorisation: obtain the current code from the authorised provider workflow. Check accidental spaces and whether a newer code replaced it.
- Transfer prohibited: identify an ordinary lock, timed restriction or registry condition before trying to unlock.
- Pending or duplicate request: inspect the existing transfer; do not start another while it remains unresolved.
- Contact or approval issue: recover authorised access and complete the actual required confirmation.
- Lifecycle or eligibility issue: resolve restoration, documentation or extension-specific requirements with the provider.
Can support simply force the transfer through?
Support can investigate the request, correct a recoverable issue and explain the registrar's reason. It cannot assume authority to override a valid dispute, registry restriction or missing holder approval. Provide evidence showing why a rejection is mistaken if you want it reviewed.
For a generic domain, the registrar's transfer policy constrains permissible denials. If a policy dispute remains after contacting the registrar, use the current ICANN complaint process for the relevant issue. Keep the original correspondence and dates; an isolated screenshot without the domain or request context is difficult to assess.
When the cause is corrected, agree whether the original order can be retried or a new request is needed. API integrations should distinguish a transport retry from a new business operation and use the documented idempotency rules. Verify completion through the resulting status and new sponsoring registrar.