I ordred an item from a website but everytime they send different item when i call them they send me an sms and ask if my my bank account is linked to my UPI and ask me to forward that sms to a particular number that sms is "UBREG quSvehhySFNw1nHM2sEilU+C/GKZNT7cX3NrInL9O1DS7KNBZV5EqlcsWl6Nj5899e4HyovXbmdMoKr+thYNpA==".
Please can anyone help me out is this a legal sms or they are trying to access to my phone and then gain access on my bank account.
By this, they will gain VPN access to your mobile and will withdraw all the money. Please don't forward this SMS.
Related
Am currently developing a web application using Laravel. I have been using twilio trial account to send messages to just one verified phone number and now I want to launch the application and be able to send sms to any phone number filled on the registration page and send an sms to the user after successfully registration. How do i do this to accomplish my task and move on because I am stack and don't know what to do...
I believe Twilio has a limit on whitelisted numbers during the trial period.
Many SMS Gateway providers do this to prevent spammers.
Nexmo, where I work, has an SMS API allows you to easily send SMS messages to phones in over 200 countries.
The API is extremely reliable, safe, & easy to integrate in your application.
All you need to do is make a simple HTTP call.
After signing up for the free trial, there will be a screen in the dashboard where you are allowed to enter up to 10 whitelisted numbers during the trial phase.
Once you top up (reload your account with funds), this restriction is lifted.
Here is some more information on how to integrate it the SMS API with PHP
Could anyone tell which countries would be able to send and receive SMS AND calls to Latvia?
I can't seem to find an answer, it appears that LV numbers can't send SMS, yet I see prices on the pricing page. I'm quite confused as of which country I should get a number in (and the price).
If I get a LV number, does it mean i can send, but not receive SMS? It would be fine for my app (already built, waiting to go live).
Basically, it is a browser app acting as a soft phone (single user), so no landline involved. Is there a way to solve the country problem?
Twilio evangelist here.
Looks like we currently only have Voice enabled Latvian numbers (numbers with a +371 prefix). Buying one costs you $1 US and use can use it to have Twilio make a voice phone call from it or receive phone calls to it.
For SMS, Twilio does support sending international SMS from US numbers, so you certainly could buy a US number and use it to send text messages to a Latvian number. The pricing for that is here (scroll down to see per-carrier pricing details).
Hope that helps clarify.
I have two questions.
I am creating a website for a client I am trying to code in Twilio SMS tools for end users and for management. I have the request and response tools built so I am all set functionally. So the questions are:
A. Can I send SMS message to any phone number OR does every number I send an SMS have to be added to twilio and verified before I can freely send SMS? It would be nice if I could just collect my phone numbers from the end users and free them from the pain of the verification process.
B. If I must verify end users then can I send SMS messages to them with their verification code? Right now an automated message call is sent to the phone number that wants SMS updates and you have to key in a six digit verification code....AND then you can send that person SMS messages. The phone call is kind of awkward.
A. Once you have a regular Twilio account, you can send an SMS to any phone number. However, some phone numbers (e.g., most landlines) cannot accept an SMS. If you try to send an SMS to those numbers with your cellphone, you will probably get a message back from the carrier that the number cannot accept SMS. However, Twilio will report success in sending the message, even though the message obviously cannot be sent to that number, and you will get no indication that the message did not go through.
But, no, there is no need to specifically add the numbers as verified for them to work with Twilio.
You can use a service like https://www.carrierlookup.com/ (which Twilio told me about) to check if a phone number can receive SMS messages.
B. -- you do not need to verify end users through Twilio, although I do think there are restrictions on a Twilio trial account that will be removed once you have a paid Twilio account.
Twilio evangelist here
Once you upgrade, you can send a message to any phone number. While you are using a trial account, you have to verify a number in order to send a message to it. More info about how a trial account works is here:
http://www.twilio.com/help/faq/twilio-basics/how-does-twilios-free-trial-work
Hope that helps.
Regarding verification: Twilio has a service that allows verifying phone numbers, including format, carrier, if it's mobile or landline, etc: https://www.twilio.com/lookup
API Docs: https://www.twilio.com/docs/lookup/api
My client has a website but doesn't check emails often. He has a lot of web enquiries through the online contact form. He carries a mobile phone though. How to send contact form details that's submitted through the website to his mobile phone as SMS?
The quickest and cheapest way is to determine the email address for that person's phone. Almost every cell phone has an email address you can send to which will show up as SMS on the device. This should help you find the email address for each carrier: http://www.makeuseof.com/tag/email-to-sms/
If you want to send an actual SMS instead of an email, you could try a service like Twilio which makes sending and receiving SMS from your apps easy via a REST API. [Full disclosure: I work at Twilio, but I was a long-time satisfied customer before starting here.]
I'm trying to figure out how to set up an SMS service where users can communicate with people on phones that are not participating in my service. "TextFree" on iPhone does something like what I want to do. They let you sign up, then you can send messages for "free" to other friends that aren't part of the service.
It looks like when you sign up for TextFree, they assign you an email address [user#textfree.us]. People outside the service without MMS capabilities can't send an SMS to this user. The user must first send an SMS to them, starting a conversation. I think this is what they're doing:
Textfree signs up for an account with a bulk SMS provider, and is assigned a single phone #, like "123".
Joe signs up for TextFree, gets assigned email: joe#textfree.us.
Mary wants to send Joe an sms, but can't because she doesn't know what # to direct the sms to.
Joe sends an sms to Mary using textfree. This really just makes an http request to some textfree server. The server gets the request, and the destination # (Mary's phone).
The server sends the sms out using their bulk sms api provider.
Mary receives the sms, and sees the originator phone # as "123".
Mary replies to the sms, using this phone #, "123".
Their sms provider receives the message, and forwards it to textfree's http server.
Textfree now has to resolve that the sms received by Mary's phone # is destined for Joe (not sure how this can be done), so it can be delivered to Joe's account.
I think that all makes sense and seems feasible, I'm just not sure about that last step, how they could figure out which conversation sms' belong to. If all outside users are directing their sms to phone #123, how could I figure out which internal user the message is destined for? Is there some way to embed a unique identifier in an SMS, so that when the external user replies to the SMS, some unique ID can be embedded in there to provide that type of context to read on the reply side of things?
Long question, thanks for any thoughts!
As for the last part of your question (unique ID in SMS):
I know of no mechanism that could help you here. When replying to a short message phones only set the sender address as destination and the user is free to type the text. The headers in a short message PDU are solely for the basic transport parameters (encoding, sender-ID, ...). There is a way to define so called user data headers, but for this to be of any use for you, you'd have to be in control of most of the devices that are involved in the message delivery, including the handsets... So basically the only way I see to correlate messages with each other reliably is the use of some ID within the message text.
An alternate approach would be to rent a bunch of numbers and assign these permanently (I assume some subscription model here) to your users. This way you could use these as identification numbers within your service and forward the messages to their real phone numbers (or even a completely different media like email / instant messenger).