The favoured new TLD registrar payment model, by Chris Wright, ARI Registry Services
Posted in: Domain Names at 07/02/2013 13:45
This week, Thomas Barrett - the President of US based registrar EnCirca - published a timely article about how the registrar cash flow model could collapse with the imminent release of hundreds of new Top-Level Domains (TLD).
I would like to thank Thomas for raising this important issue and for encouraging all new TLD applicants to discuss this topic with their back-end registry provider.
Thomas is correct; the process new TLD registries choose to interact with registrars will have a major impact on the success of their businesses.
Building upon what Thomas has written, I would like to take this opportunity to provide insights from a back-end registry operator's view and offer an explanation for why I think the post bill pay model is favoured amongst registrars and should be supported by registries.
While Thomas briefly touched on this point, I would like to expand upon it and clarify a few issues.
The post bill pay model
ARI Registry Services has spent considerable time developing effective payment processes between registries and registrars. Following considerable consultation, the post bill pay model was constructed in conjunction with some of the largest registrars around the world.
We support the post bill pay model because it is actually significantly simpler and most registrars like it. In summary, this model essentially means registrars receive an invoice from the registry operator for all billable transactions following the end of a billing period. There are no accounts and no need for funds to be transferred outside of these invoices, which significantly helps to reduce the financial risk and strain on registrars.
It's worth noting that it can be important to make a distinction between transactions that can be reversed and transaction's that cannot. To make it simple for everyone, ARI Registry Services does not bill registry operators for transactions that are still reversible. We will wait until these transactions become non-reversible before we issue any invoices to registry operators. We offer similar functionality to our registry operators with respect to registrar billing so that they also have the choice to do this.
Benefits of the post bill pay model
As Thomas outlined in his article, there are a number of questions new TLD applicants should be asking their back-end registry provider. I completely agree with Thomas and offer the following responses to provide clarity on the benefits of the post bill pay model:
1) Is there an "accreditation" fee charged by the Registry?
As a back-end registry provider, we don't charge any accreditation fee.
In fact, we take this one step further. All established registrars that can demonstrate experience in integrating with registries of a similar structure to us do not need to perform technical accreditation processes with us. Furthermore, we strongly advise our registry clients against charging accreditation fees as this is an unnecessary barrier to entry for registrars and ultimately impacts the commercial success of the TLD.
2) How much does the Registry require as an initial deposit and for replenishments?
Deposits, account maintenance and funds for replenishments are abolished under the post pay billing model. We don't see any need for these.
The benefit of the post pay billing model is that there is no need to have account balances in the registry and we can simply track the transactions and invoice the registrars.
3) How does the Registry communicate the existing balance to Registrars?
When you move to the post pay model, all you need to do is provide a web interface that allows registry operators and registrars alike access to the billable transactions that have occurred in the current invoice cycle. Sending a daily summary of transaction totals is the preferred way to proactively inform registrars of what they have spent.
4) Is there an auto-renewal policy for non-renewed domains?
Thomas seems to suggest that registrars don't like auto-renewal because they basically provide credits to registrants or credits to the TLD.
This is easily addressed by delaying raising a transaction for this renewal until the end of the auto-renew grace period. Alternatively we can use the post pay model and the principle of not charging for non-reversible transactions. These solutions effectively eliminate this issue so you can still support an auto-renew service without the registrar having to carry the financial risk.
5) What are the bank fees to fund your registry account?
This is eliminated under the post pay bill model because there are no bank accounts and deposits to be tracked.
6) What payment options does the Registry accept for funds?
In our post bill pay model (as a back-end registry operator), we don't enforce any mandatory payment options. It's relatively straightforward; we send the invoicing data to the registry operator, who in turn will load the information into their accounting systems and generate an invoice for registrars. Registry operators are free to accept payment via any of the standard commercial invoicing payment options, or indeed any other method they desire.
7) Does the Registry have its own account for each Registrar or does the back-end provider provide a single account for each registrar for all of the TLDs the back-end provider manages?
This issue becomes a lot less of a problem under the post bill pay model because we do not require money to be deposited, and thus tied up.
Each registrar will get a separate invoice from each commercial entity (registry operator) they deal with (TLD or collection of TLDs).
8) Does the Registry provider emergency credit if funds run low?
Again, because there are no funds associated with the post bill pay model, this issue is eliminated.
Risk for registry operators
As can be seen in our responses above, the post bill pay model addresses all of the questions Thomas has raised. However, while reducing the financial burden to registrars, it does potentially expose the registry operator to more risk.
We argue that new TLD registry operators should be prepared to accept this risk given that it will make their TLD more appealing to registrars. Ultimately, if you don't have any registrars, you won't be able to sell your domain names.
Further, these risks are manageable and can be addressed. For example, you can conduct credit checks on registrars, ask potentially problematic or risky registrars to put money into escrow or offer a bond, track the amount of debt a registrar is accumulating, or ultimately completely cut off the registrar from the registry if bills are not paid.
There are a number of strategies available to reduce this risk to registry operators.
A further benefit of the post bill pay model is that it offers the most flexible platform for registries and registrars to implement promotional offers, discounts, credits for marketing and other commercial pricing strategies.
Essentially, each registry operator can apply their own discounting or promotional strategy as credits towards invoices, without requiring back-end registry operators to manage these. This means registry operators do not have to rely on their registry services provider to custom build promotions into their registry system, or pay expensive development costs.
Impact on new TLD applicants
I strongly recommend all new TLD applicants to consider the post bill pay model for their registrar payment process.
As described above, this model reduces the cash flow burden for registrars, makes your TLD more appealing to them and allows each registry operator to negotiate their own terms with each registrar.
Remember, registrars will be a crucial element in the success of many new TLDs. The barriers to entry will be a key parameter reviewed by registrars when making decisions about which TLDs to integrate with first and a post bill payment model will go a long way to reducing these barriers.
If your back-end registry provider does not offer a post bill payment model, it may not be too late to switch.
This article by Chris Wright, Chief Technology Officer, ARI Registry Services, was sourced with permission from: