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.
Related
I am building a service where we need to create a new phone number to each new account and later act as its Whatsapp intermediary. So every new user can have their own Whatsapp number and see chats (and interract with them) in our external app. Basically a client for whatsapp numbers. Is there a way to do it with Twilio or Vonage? I tried to but it seems like it allows to build such functionalities only with one, WhatsappBusiness account. But it doesn't allow to scale new numbers programmatically.
Twilio developer evangelist here.
We do have an alternative process for creating accounts that service other businesses through WhatsApp if you are an independent software vendor or system integrator. However, it's still not an API process. I believe this is because there is an amount of back and forth between you, Twilio and Facebook to set up, review, and approve each business account and number.
The restrictive nature of this is on Facebook's side, since they have stricter rules for how WhatsApp can be used to engage users. So I don't imagine any partner will be able to offer this process entirely through an API.
I am trying to use a Twilio phone number for Apple's two factor authentication, but when I set up the phone number on Apple's site the initial verification SMS is never received by the Twilio number. I have confirmed that Apple is able to send the text to a Google Voice number. I have also confirmed with Apple support that the message sent is a standard SMS. Is there something on Twilio's side preventing receiving the message?
This is actually by design. By default, Twilio long code numbers can't receive SMS messages from short code numbers. Look for the section titled "Are you expecting to receive SMS from a short code?" at the following link. https://support.twilio.com/hc/en-us/articles/223133447-Not-Receiving-Incoming-SMS-and-MMS-Messages-on-Twilio-Phone-Number
When I asked this question the functionality wasn't available at all, but now the feature can be requested. There are caveats. https://support.twilio.com/hc/en-us/articles/223181668-Can-Twilio-numbers-receive-SMS-from-a-short-code-
As a followup to ryechus' answer, I requested this functionality and was still not able to receive 2fa codes from apple in Twilio. Their support said:
the unfortunate limitation you're likely facing is that I have know
Apple to prevent verification codes from being sent to virtual phone
numbers.
Some services review the offered number and only send verification SMS
to phone numbers associated with genuine handsets as a measure to
protect against fraud.
Unfortunately, regardless of the Twilio configuration, in my
experience Apple will not delivery verification messages to Twilio.
Interestingly, it does work with google voice.
I'm an indie developer and love the platform but have recently discovered that you can't buy phone numbers from a trial account. I've also seen that "sandboxing" is a deprecated feature and was hoping that something similar has been created in it's place. For someone like me money is tight and I'd like to get a basic app together before having to pay for the platform.
Is there anyway that I can test these platform features without incurring a cost?
Twilio employee here.
For development, we don't charge you until you upgrade. That said, to get you started, you get one free phone number when you sign up. It is 100% yours to do with as you wish.. with a couple limitations: You can only send SMS or place calls to phone numbers you've verified with us.
Also, once you've upgraded you can still do testing and development for free with our Test Credentials. The full details are on the site - http://www.twilio.com/docs/api/rest/test-credentials - but this is probably the most important bit for you:
You use these credentials in the same way as your live credentials.
However, when you authenticate with your test credentials, we will not
charge your account, update the state of your account, or connect to
real phone numbers. You can now pretend to buy a phone number, or send
an SMS, without actually doing so.
I have a client that needs to have its volunteers purchase an IAP (A data package that is downloaded), then somehow reimburse them. The problem is that there is no easy way to do this that I think Apple will approve of. Especially for over 1500 people. I've come up with several ways of doing this with their pros and cons, which one would be best to implement and does anyone have any other suggestions on how to do this?
1) Have the client send out iTunes gift cards via email. The IAP is $7, and you can't send a gift card less than $10. Also, they would have to send them one at a time, there is no way to send bulk. Not going to work
2) Create gift codes like iTunes gift cards. My client can purchase codes in bulk via IAP (so Apple still gets their money), and store them on my web server securely. I can then implement a system to send all the codes to a single email, or individually to multiple emails. Then the volunteers can use the codes to unlock that single IAP. This would be more work on my part, but easier for my client. Something tells me Apple probably would not approve of this method.
3) Create "Credits" that the client can purchase in bulk via IAP (so Apple still gets their money), then gift either the credits or send the IAP info itself to the volunteers via a p2p bluetooth connection created with game kit. This would be harder for the client, as they would have to send each "Credit" individually. But I think Apple would be more likely to approve this.
4) Have the client send me a list of UUIDs for each of the volunteers devices. I add the UUIDs to a secure list on my server. During the purchase the a check is preformed to see if the devices UUID matches one on my server. If it is, they are marked as "all ready paid" and given the IAP data. I don't know about this one, as the only way I can see the money transfer happening is myself getting paid directly, and Apple being left out (So they probably wouldn't approve of this. I have no problem giving Apple their 30% if I could find a way to get that to work with this.
I'd go with Option 5, and create my own IAP system. Much like Option 3, but bypassing Apple all together. Add a Custom URL Scheme to you application, give it to your client to distribute. When your app is launched by its Custom URL Scheme have it open to a promo code entry page.
Your client would be able to purchase/create codes as necessary via a website that you set up for them. You would then store the codes (or create an algorithm to check generated codes against), and validate the codes as the users enter them.
Then your clients users would enter their unique code and have everything unlocked/downloaded as needed.
I have done a similar set up with promo codes to unlock the full version of my applications so I could create my own promotions, without making the upgrades free for everyone by removing/altering the IAP.
I have developed an iPhone application for a café. In the application you can order takeaway food and therefore I need a way to be sure that there are no orders in a "fake" name (e.g. a person who makes an order with a strangers name, e-mail and so on)
Therefore I have to make the user confirm the order before it's sent to the café. I am not sure what the best way to do this is.
I have been thinking of setting up an SMS gateway and when an order is placed, an SMS is sent to the the entered phone number and the user will have to send a confirmation SMS back. I am not a fan of this approach, as the confirmation is not happening in the application itself.
Then I got the idea that this might be possible with push notifications. I am not exactly sure how it would work (if you have any ideas on this, please let me hear) but since Apple writes the following in their documentation I do not really dare to rely on this for confirmation.
Important: Because delivery is not guaranteed, you should not depend on
the remote-notifications facility for
delivering critical data to an
application via the payload. And never
include sensitive data in the payload.
You should use it only to notify the
user that new data is available.
Another approach which would be very easy to implement would be to programtically retrieve the user's phone number from the SIM card but I have read that Apple rejects applications which does this.
I would like to ask if you have any ideas how I can do this confirmation? It could be one of the above approaches or a completely new. Would it be possible to do something with the unique ID that the every iPhone has?
Could you do the SMS confirmation, but only once? Keep a link of UDID and phone number pairs, and once a confirmation has been made for a pair then don't request it again? That way, regular customers will get minimal hassle.
Don't forget that the UDID for a phone number, or the phone number for a UDID, may change, if the person gets a new device or a new SIM card: make sure your code supports that.
Another approach is to validate credit card information up front as part of account setup. Then offer the option to pay now or cash n carry. This eliminate 99% of the no shows.