At Nexmo we've been powering similar solutions for a lot of apps through our SMS API. However, we've just released a higher-level API that leverages our SMS / Voice APIs to make this kind of number verification easy to implement. Ours includes multiple deliveries and channels (falls back to a voice call if needed). We're looking for early adopters, would love to have you take a look: https://docs.nexmo.com/index.php/verify
Disclaimer: I do a bit of part time dev evang for Nexmo.
Nexmo should be pretty good across the board as it pertains to what delivers best (direct to carrier model: http://blog.nexmo.com/post/4690069179/directsms). In that way, Nexmo is trying to solve the issue you're having.
Have you had any issues with deliverability and Nexmo (where another provider delivered better)? Nexmo actually provides some tools to automatically optimize traffic based on client conversion ratios.
I haven't had very good luck with Nexmo and deliverability. I wanted to migrate all my traffic there, but had to stop after a few %-tests resulted in increased failure rate. I do still use them for some areas/networks they seem to do better with. I also appreciate their good customer service.
Sorry to hear that. I am part of Nexmo helpdesk and we are here to help you address any issue you are seeing. Can you share with us more info on the issues? message IDs? phone numbers? account? best is that you drop us a ticket at nexmo.zendesk.com and we would love to assist!
I'm sure the team would appreciate the feedback as to where the deliverability was less than another provider. Also, might want to ask about the recently added tools to use your conversion stats to help route traffic.
There are pros/cons to any language. If you're developing something web related, PHP is certainly worth considering (especially in your case, as you have experience with it).
Just a few quick thoughts:
PHP is - in most cases - very tightly coupled to the HTTP request. This can be good or bad depending on what you're building. Doing a lot of offline processing? Probably bad. Serving up web pages? Probably good.
There's no (or little) state with PHP (you do have the session, which can be pushed to memcache), so - generally speaking - running your application across a bunch of web nodes isn't too hard to implement (even scaling the horrible legacy style code that helps give PHP a bad reputation shouldn't be too hard). This may or may not be important to you.
There's really no one true way with PHP - it can be used for a simple 10 line script, or for a large scale web application. If you like (or need) that kind of flexibility, it could be a good choice.
Bottom line is - it's certainly sill worth considering, just know why you picked it (or whatever other language/platform you use).
That said "it's what I know" or "I wanted to try something new" aren't necessarily bad reasons.
Good points. I feel I should point out that you can use PHP independent of any web server by using the command line interpreter (CLI) version. This is, for example, how we run PHP cron jobs where I work.
True. Not a strength for the language though - if that's a big part of what you do, then I'd consider something else. That said, I've built plenty of applications that used PHP on the command line or as a daemon.
Right now I'm a contract developer (building web applications for clients) - if that wasn't possible (and, since it seems like a cop out, I'll ignore non-internet related programming) I'd likely be a carpenter/tinkerer (building physical things for clients).
CloudMine (https://cloudmine.me) recently updated their dashboard, and while I haven't had a chance to really work through it all, it looks pretty nice.s
Since it's backend as a service, allowing access to view/edit/troubleshoot the data is key.
