What is a "Transfer Robot" and how does it work?

 

This article will explain the basic principle of the Transfer Robots. It will cover the following questions:

 

 

 

What is the Transfer Robot service?

 

Openprovider developed a series of transfer robots for a wide range of external registrars.
The process is simple:

  • You provide us with access to your account at the other registrar
  • We schedule the transfers and process them in the background

 

As we have access to your account, we are able to retrieve the required details by API to start the transfer.

Our system will create an Openprovider customer handle which completely matches the current details. We will retrieve the nameservers, dns zone (if applicable) and transfer-code.

We offer 2 options regarding the transfer-dates of the domains;

  • We can read the expiration date of a domain via your account, so we schedule it shortly before that date to safeguard your cash flow. You will see the scheduled domains at all times in your control panel, which gives you all the freedom to adjust or remove (via RCP or API) the transfers yourself before they start.

  • Or transfer the entire portfolio on one given date, which will allow you to close the other registrar account sooner and bundle all possible end-customer communications and questions in 1 moment.

 

 

 

What details are required to initiate the robot transfer service?

 

In general, Openprovider only needs 2 things;

1. The credentials of the account.

2. The list of domains that needs to be transferred.

 

1 --> Please make sure that the credentials shared have API access enabled.

Some registrars are working with IP whitelisting. In those cases our IP addresses which our robot is using needs to be added to the account. Our sales team can inform you further about the IP addresses which need to be added.

 

2 --> To avoid any confusion about current statuses or renewal-settings in the account, we will only import the domains for Robot Transfer, which you will submit to us. (preferable csv format)

 

Ready?

You can start your request via the control panel.
Our sales team will reach out to you as soon as possible with more details.

 

Screen_Shot_2021-12-14_at_20.55.42.png

 

For which registrars do you offer a Robot Transfer service?

As the list of available Robots keeps on growing, please reach out to sales@openprovider.com to get the latest info about that.

 

 

Will this also skip any transfer messages towards end-customers and the ICANN contact-verification requirement?


Transfer messages

The goals of the transfer robot is to schedule and process the domains in an automated way. There are some notifications from the current registrar which we can not prevent. Therefore we ask to read the information below carefully and inform the end-customer before activation the robot.


We offer 2 options regarding the transfer confirmations;

  • Our robot will receive the FOA2 email, confirming the transfer to achieve the domain to be transferred as soon as possible. To do this, the end-customer will get a notification that the email-address is (temporarily) updated. (Default option)
  • The end-customer receives the FOA2 email. Approval can speed up the transfer, but in most cases, it is not required as a gTLD transfer will continue after 6 days. With this option the end-customer has the option to reject the transfer.

Our advise is to use the default option where our robot will receive and handles the transfer related emails. This will reduce the risk of rejected transfers. A notification about a changed email-address might be less intimidating than an email about an outgoing transfer.

Our advise is to inform the end-customers about the upcoming notifications regarding the temporary email-address adjustment. After the transfer is completed, the original email-address is placed back.

 

 

ICANN contact-verification

One of the ICANN requirements is the contact verification: each contact used as owner for a gTLD registration is checked against our database. If the e-mail address has not yet been verified, we will send an e-mail to that e-mail address in which we require an affirmative response. If we do not receive one, we are forced to suspend the domain registration, until the email is verified.

This verification process must be done by every registrar itself. It is not possible to "re-use" verification done by other / previous registrars.

As this requirement is part of our contract with ICANN (as ICANN accredited registrar), we cannot skip this process.
We do advise to review our white-label options in this article and create a custom template which your end-customers will recognize.

 

 

 

 

 

Was this article helpful?
Additional questions? Submit a request