On WhitePages.com they have a mechanism in place that facilitates payment by entering your telephone number. After you enter your number, you get an SMS that instructs you to enter "GO" in order to complete the transaction. Following that reply with the purchase you've made, you get another message suggesting that for a certain monthly fee you can use the service in an unlimited fashion. I had not seen anything with quite those dynamics before and I'm curious of what service(s) one would use to construct a payment system like this for a Ruby on Rails app?
I am particularly interested in a platform that allows this kind of payment from as many countries as possible as I currently use Twilio for SMS messaging on another app.
Without knowing the full details of what WhitePages.com offer it sounds like they're using Premium SMS as a method of collecting payment from a mobile.
After you've entered your telephone number, they'll send you a text with the originator set to a premium shortcode (rather than from a long number). The reply you send back to the premium shortcode is deemed your acceptance to be charged more than your standard network SMS rate. The amount of the charge can vary but should be made obvious to subscribers before they are charged. This Mobile-Originated reply text (MO) is what causes the charge to be taken from your mobile telephone number bill.
Premium subscription services can then subsequently generate further charges whilst the user is still subscribed by sending messages from the premium shortcode. The act of receiving these messages causes a charge to be applied to your mobile telephone bill. These are deemed Mobile-Terminated texts (MT).
Premium SMS is not a simple solution for collecting payment for a number of reasons.
You often only receive a small percentage of what the user is being charged on their bill as the mobile networks keep a cut for offering the service.
As this relies on premium shortcodes you may have to accept you'll have different numbers for each country you want to operate in as you'll have to organise premium shortcodes in each country.
There's different regulations regarding Premium services that you need to be aware of in each country. For example, users need to be able to unsubscribe / opt-out of premium services once subscribed so premium services often have to comply with receiving 'STOP' and 'STOP ALL' messages from users.
As far as I know, Twilio doesn't support premium shortcodes at this time. There are other SMS Gateways which do support premium SMS but you won't get a single solution to fit any country you wish to operate in. Interacting with this kind of system is usually no more complex than sending and receiving normal SMS so the task of creating this with a Ruby on Rails app should be no more complex.
Normal SMS is pretty much globally universal. Premium SMS is an additional country specific feature.
Related
By default, Twilio trial accounts can only send SMS to numbers that are listed as Verified Caller IDs in the Twilio console. These numbers have to be added manually, and require a verification message before they can receive SMS. This is an excellent feature for development, as it prevents accidentally sending SMS to wrong numbers.
My problem, is that I am developing for a client whose account is already out of trial status. I don't want the software in development to be able to send text messages to any number, because there is a risk of sending dev messages to the client's actual customers. However, we need to be able to send to some numbers for testing. Is there any way to turn the trial behavior back on? That is, can we somehow configure Twilio to only allow sending SMS to verfied numbers, even if it is not a trial account?
If this isn't possible, I think I can query the Outgoing Caller IDs resource from my program to verify the recipient number against the list before sending. However, this puts the responsibility back on my development team, and the possibility for mistakes remains. I'd like to be able to block the behavior at the Twilio level.
This behavior is only applied for trial accounts, however I'll pass this feedback on internally.
You'll need to replicate this behavior yourself for your applications using an upgraded account.
As you mentioned, you can query the Outgoing Caller IDs to get the phone numbers you have already verified with Twilio and use that as an accept list.
However, for your use case, you can store and fetch the accept list using whatever way is most convenient for you, like in code, file, database, etc.
Depending on your needs, you could embed this logic directly into your app, or use a single shared library, or create a web API that all other apps have to use to send texts.
Good luck! We can't wait to see what you build!
Update after getting internal feedback.
You can create a new trial account, even with the same Twilio profile, which would give you promotional credits and the same verified Caller ID limits again.
The promotional credit should last you a long time for test scenarios.
There is any way for send text message to mobile number by any free service.
I have done that by twilio, but I don't want to purchase any thing,
Is there any in-build functionality in rails, to send text message in phone number like email ?
There is No build-in functionality in rails for sending text messages.
Instead of that you can use third party services. (msg91, sendgrid,
gupshup). In that Per account they will give 100 free sms per month.
You can use that service without buying anything.
If you want to send more messages you have to purchase paid services.
.
I've been working with Twilio to program SMS functionality on my app, and it seems that Twilio works best with US numbers and not so well with international numbers. I've done some research and have learned about an August 16th fiasco that resulted inthe SMS functionality being shut off by Twilio. Also through testing I have learned that some international carriers are not supported by Twilio. So some of my friends abroad aren't receiving my Twilio SMS messages.
Can anyone provide further insight into this issue? Is international SMS well supported by Twilio? If not, how many carriers and which ones ARE supported? Finally is there a better SMS service provider that can guarantee full support for all if not the more prevalent carriers internationally?
Thanks for the support everyone and any clarification on this issue.
Good questions all - this information can be kind of hard to find on our website right now. If I'm picking up what you're putting down correctly, you're curious what kind of availability Twilio SMS has internationally and what the deliverability is like.
The matrix on what kind of Twilio service is available where can get a little complicated (which we have here a little buried in our FAQ: http://www.twilio.com/help/faq/phone-numbers/which-countries-does-twilio-have-phone-numbers-in-and-what-are-their-capabilities), but for SMS it breaks down like this:
Twilio phone numbers that can send and receive SMS are available in the US, Canada and the UK.
US and Canadian numbers can send and receive to 190 countries to over 1,000 carriers. To see what the pricing for each country and carrier per message, check out this page: https://www.twilio.com/sms/pricing
UK numbers can currently send and receive SMS reliably within the UK. As the numbers themselves are geographic, some international carriers do not allow messages to be sent or received to them. This might be a possible root cause for some of the deliverability issues you experienced.
All other phone numbers we make available in other countries only have support for Twilio Voice - these numbers cannot send or receive SMS at all.
I'm not aware of any SMS related incident on 16 August, though we did have intermittent service interruption the week before on 9 August lasting a little under 90 minutes. For future reference, we communicate all our service issues on an independently hosted status board here: http://status.twilio.com/ Any issue, root cause and resolution are posted there for your review.
Finally, if you have a specific question about a number, deliverability to a particular carrier or handset, or would just like to share a cool hack, I definitely encourage you to engage one-on-one with our support crew at help#twilio.com or come meet one of my fellow developer evangelists when you're out at a programming event. We'd love to see what you're working on and if there is anything we can do to help.
Thanks Kev!
Rob - devangel at Twilio
I have a slightly different issue, but my discussion of the problem addresses some of the questions here. In essence, if you want to SMS internationally without upgrading, your limitation is that you can only text to numbers that have been manually verified through this website. You have to log in, use a US phone number, and then "Verify" your international numbers. By upgrading your account you no longer have to manually verify each number.
Twilio is very strong in USA, however, you may try to use several SMS suppliers for delivery of your messages internationally. Also, if you would like to test a delivery of your messages to a certain country where you do not have a testing mobile phone number, you can send it on telqtest.com testing numbers.
Actually I'm developing an iOS application for specific mobile operator,
The app will be free , and some content need to be paid so the operator
need users to pay via Premium SMS or IVR (interactive voice replay),
But after make some search i found that Apple maybe will reject the app.
because the need all payment being done via there system i.e via in-app purchase
or paid Model .
What is the ways to solve this problem , and How can i achieve this (Premium SMS ,paid IVR) ?
The bad news is: you can't ship an app that is solely based on paid sms from within the app. As this article on arstechnica states:
Content providers can continue to offer outside subscriptions that are accessible via an iOS app, so long as no external links to outside purchasing mechanisms are built into the app. If subscribers can pay for content within the app, it must use in-app purchasing APIs, though content providers are now free to set whatever price they like.
If you really want to deploy paid text messages, you could integrate in-app-purchase with a high price. Additionally you offer paid text messages at a lower price(Users send a text message via their ordinary message app to a number you tell them via your web page or ad or any other way). So users will tend take advantage of the lower price and will send text messages. An obstacle will be, that Apple won't allow a reference to the cheaper payment method from within the app. So it depends, on how you inform your users about your app and payment methods.
So I'm trying to figure out how companies are able to provide free phone numbers to their users like Skype and Google Voice? I tried doing some research on who maintains a list of available phone numbers like ICANN and found NANPA (North American Numbering Plan Administration). It doesn't look like you can purchase a block of phone numbers from them.
So if I wanted to purchase bulk telephone numbers and provide a service where I could give my users a free number, do I just call AT&T and purchase from them?
Any help or direction would be greatly appreciated.
I'm trying to figure out how I can provide a phone number to my users so I can deliver text messages to them (outside of a cell phone number). Like how users are assigned a phone number from eFax and anyone can send them a fax.
My assumption is that eFax purchased a block of phone numbers from a provider which then assigns to users to receive fax messages. If you own the number, the routing should be fairly simple.
So maybe the direction is to provision the number in real-time as users sign up and pay that fee (whatever it may be).
I'll check out your link to bandwidth.
Check out http://www.bandwidth.com or http://www.voip-info.org/wiki/view/Bandwidth.com.
Bandwidth.com has an API for real-time provisioning. I'm not sure about the cost though.
Essentially, you don't even have to purchase them. You just need to be a (registered) telephone company. That's a bigger burden than you probably expected, but I expect Skype and Google did this. For smaller companies, it may be wise to outsource this, but you'd want to find a partner that isn't competing with you. AT&T wouldn't sound like the best partner if you're going to sell VOIP to consumers.