You have many many many other ways to have a LN address. Read here all the options: https://darth-coin.github.io/beginner/getting-started-ln-address-en.html

I personally love to use Zeus but I do not use Zeuspay. Why? Because it relays on the hold invoice method. Hold invoices could trigger anytime a force close of your channels. Also this redeem time I do not like it. I want to receive the sats straight away not having to redeem them manually.

Zeuspay was created from the pressure of nostr users that wanted a so called "self-custodial" LN address, then Zeus team come up with this method so all Zeus users could have a LN address directly into their Zeus app. And Zeuspay is some kind in the middle. I am not saying is a bad concept, only that is not suitable for SN. Even if you run Zeus with a remote node, you will still have problems. With embedded node will be even more, due to the fact that you must be online when you redeem. And many users don't know how to use persistent mode or even have the patience to wait for sync. And will do stupid things that will trigger force closures.

If you really want a 100% stable functional LN address better run your own LN address server hosted on your own hardware, with your own node. If you do not want/have your own domain, fine, read my above guide and you will find out multiple ways to have a LN address with different domains, as decoys or using a federated option.

YOU HAVE BEEN WARNED Using SN with a Zeupay LN address you will have a lot of force closures and trouble, due to the intensity of zaps and particular way of redeeming. Zeuspay is NOT suitable for using it with SN! Maybe in other cases, but not here.

And I raise again and again the whole warning about this craziness with "self-custodial zaps" on SN: Any interceptor for zaps will be added not necessary complexity that will create more trouble than good, due to the intensity of zaps in a certain period. People STILL don't know how to run properly nodes and will have a lot of trouble and will give even more trouble for SN team trying to find where is the problem. But they still do not want to see that the whole system is a MISTAKE.

Instead of dedicating more time in improving SN, they will waste time in debugging users payments and routes.