We are not prepared to persist customer's EIN's in our systems because of the associated risks and liabilities. Does Twilio have any alternatives for registering our low-volume customers? For example, an API that our web page could interact with for our customers to register themselves?
Is there perhaps an alternative path? For example, creating sub-accounts for each of our hundreds of customers that would allow them to register on Twilio and still allow our software to interact with SMS on their behalf?
Are there any third party apps that Twilio endorses that could assist in the SMS registration for us? Or even perhaps a third party API that persists encrypted data like EINs for us and assumes that liability for us?
Thanks.
Update: I realized we have options to pursue for registration without needing to persist sensitive data like their EIN. We could inject user interaction in the middle of our current registration steps, meaning the registration steps stop at the required points in the process, our user is notified of needed data, then the registration resumes when they furnish the data. The data like EIN would be transferred directly to Twilio API without being persisted on our server. Problem solved. Still, it would be good to know if there are any good answers to my other questions. Thanks again.
Twilio developer evangelist here.
Our Messaging Product Lead says they are not aware of any 3rd party apps that help with 10DLC registrations and believe the best option is what you mentioned in your update!
Related
I recently signed up here as part of my course with some coaches. But, not many details given. wondering what is twilio and why we need and what all we can using twilio.
Really appreciate if someone can help me here to understand this product. Or at least route me to some place where i can learn more.
Twilio developer evangelist here.
Twilio provides APIs and tools for customer engagement and communication. For example, if you're building an app in, say, JavaScript or Python, and you want your app to send and receive text messages, make and receive phone calls, video calls, have in-app or in-browser chat, two-factor authentication, email, and more, you use Twilio so you can implement those features quickly.
There's other products for debugging, hosting serverless applications, building chatbots, and more--you can see all products offered here on the website.
There's also some code snippets and more details under documentation here.
jut for a background, I'm building a poc of twilio based video chat contact center and I've came upon one issue. Most of the people using the service will be anonymous customers, no logging / authentication here. Looking at the twilio api, once I produce a Token with VideoGrant I loose all control of what the javascript client does with it, for example, someone can modify my JS client to create their own room, instead of joining the one assigned by my app.
Is there any way to create VideoGrant which would allow only joining a room, preferably a single, selected room?
There is a mention of Room Events in the console, but I didn't see any docs on it, maybe it would allow to catch rooms creation and kill the unknown ones, btw is there a REST api for rooms? nothing on official REST api docs again.
Sorry if the questions are a bit vauge, I'm aware that they might not meet SO standards, but I know that few Twilio developer evangelists are active so maybe you guys can propose some best practices here or just point out to the right docs if I am dumb enough to have missed them.
Lukasz,
Rob Brazier here, PM for Video. In the next few weeks we'll be adding a new grant to the Video section of our Access Tokens that allow you to lock down access only to a specific Room.
The basic flow will be:
User visits your site.
Your app server decides what Room they should connect to.
Your app server creates a Room using whatever identifier you like as the name (using the upcoming Video REST API).
Your app server generates an Access Token with a grant for the specific Room created in #3.
Your app server returns that Access Token to the client.
Client connects using the provided token and is joined to the specified Room.
Let me know if this is clear. Thanks,
One of my clients have a situation to pay their website user directly from platform account to user. I can do it by using their transfer payment API.
But, my client want to pay to user's email so that user can have option to perform rest of the action.
I went through their API documentation but don't see anything related to do that. Does anyone have similar experience or know anything related to do that?
Stripe's API doesn't have anything like that, but it is something you may be able to build into your application.
I think you might want to contact Stripe Support and fill them in on your use case and see if they can offer you some specific suggestions.
I am building a mobile-focused web application, to later convert to hybrid, and I would prefer new user registrations confirm the user's phone number versus their email address.
I would like to send a new user an SMS with a unique code. When they first log in, they must enter that code to activate their account.
I have a custom SMS service that is sending SMS fine, and would like to know how to integrate this into the Identity registration process.
Please note that I do not wish to use SMS for routine two-factor authentication.
You can use create additional actions in your account controller
and use methods from Microsoft.AspNet.Identity.Core
UserManager.GenerateChangePhoneNumberToken
Send sms with token
UserManager.VerifyChangePhoneNumberToken
Add custom logic to authorization
There are several ways to accomplish this.
Cheap but not reliable or enterprise ready is to build an app on a device you own and have those other devices send an SMS to it. You can process the SMS and reply however you like. With unlimited texting plans, it would be fine. It's just not redundant or reliable (the phone battery could die, you may need to do updates that could interrupt service, etc.)
Work with a company like Twilio (https://www.twilio.com/) and use their SMS gateway, API and services to build, quickly and cheaply (for the most part) the type of service you are looking to provide. There are competitors to Twilio and I'm not endorsing them, just providing them as an example.
Obtain your own SMS gateway (https://en.wikipedia.org/wiki/SMS_gateway) and then do heavily integrated and customized services.
If this is just a proof of concept at the enterprise level or you don't know what your user adoption rate will be, then #1 is probably fine until you need #2. #3 is rarely the best option.
Let's say I am making a sign up form in which I asked user's twitter ID. How do I verify if the ID entered by user belongs to him/her? In case of verifying email we simply send a verification link which user has to click so how do I verify twitter ID? I have never used twitter before.
The only reliable and practical way to verify that twitter account X belongs to user Y this to do full on “3 legged” OAuth authentication. That being said, you may want to consider if you might be OK with just taking the user at their word on it.
Getting OAuth to work and securely storing the resulting tokens is much easier nowadays than it once was, but is still non-trivial.
Reasons to verify the twitter account, in increasing reasonableness:
You will be making enough server side requests, on behalf of multiple users, that you run up against Twitter’s API Rate Limiting. (Having multiple auth-tokens will allow for a higher API rate)
You need to automagically send tweets and/or follow accounts on the user’s behalf
N.B. do this as opt-in and be ultra clear about when/why you will be doing this, or you will face the justified fury of scorned users
Don’t verify the account if you’re looking to do these things:
You need to send tweets and/or follow accounts on the user’s behalf, and the user will be able to perform a browser based confirmation workflow for each of those actions; use Twitter’s Web Intents for this.
If you just want to pull in real time data for user’s avatar, bio, or recent Tweets Twitter supplies some prefab widgets for you.
All of the authenticated Twitter API Calls can be done client side with JavaScript. Twitter has a js framework, which does not require you to handle and store tokens on your server, to help you with that.
An alternate contact method for password resets, notifications, etc.
Private communication between users on twitter requires mutual following, many users probably never check their Direct Messages (or even know what a DM is), and any messages would be limited to 140 characters. Just use email for all that kind of nonsense.
If you’re just gathering this info to display it on a user’s profile page, in an “other places on the web” kind of way, integrating and maintaining all the server side OAuth pieces is likely too much bother. Just make sure you have a reasonable and clear TOS and an obvious way for 3rd parties to report any of your users who may be claiming a twitter account that is not their own.
If you’re still interested in OAuth, Twitter's Dev page has plenty of resources, including a nice overview of a generic “Sign In with Twitter” “3 legged” OAuth work flow.