I liked Instwallet very much for it's URL only usability.  My philosophy in using it was for spending money only.  I always knew that a whole range of possible issues existed, and am not complaining bitterly about my loss.  I am pursuing the failure vigorously, but for different reasons.

My feeling about URL access is that a whole range of issues from a different but overlapping set exist with other solutions also.  Losing one's password is high among these.  I see no reason why it could not be reasonably secure and well managed on the back end.  The 'killer app' for me was not needing to provide an e-mail addy, SMS, etc, and the lack of a password made that smooth.

---

Here are the things I would look for:

 - A team which is well known and respected (this failed in the case of ~davout though.)

 - A good description of the back-end to architecture.  Opens-source if possible.  I think the pro's outweigh the con's, but it is debatable.

 - A good understanding of the funding.  Limited hot-wallet with occasional funds exhaustion is preferable to insolvency on failure.  Fees going into an auditable pool to be re-distributed absent failure would lend some credibility.  Or even let the user select thier preference on limits.

 - A documented recovery plan in case of failure.

 - A 'lock out' URL which, if visited, would lock the account.

 - A 'recovery token' which could be used to unlock a locked account or prove ownership of a URL

 - A 'maximum exceeded warning' mechanism whereby a user could be reminded that the service is for limited funds.

 - I've already forgotten some of the stuff I thought of.

I'll use your service without any of this stuff for minor spending, temporary funds shuffling, and new user demonstration purposes.  As always, with the anticipation that you guys could rip me off at any time.  Also with the full knowledge that you could be logging my IP's, transactions, etc.  Just as was the case with Instawallet.