Configuring an appointment app and looking at using email to sms. The api is significantly less expensive as you just have to look up the mobile number once, get the appropriate carrier gateway address(once for every new number), and then send an email that is converted to sms via the provider. As opposed to getting charged for every sms sent.
Why is this approach much less common? I've never really seen it. I figure there must be some limitations or issues that everyone else knows about that I couldn't find.
Note: Not sending out bulk messages. It's an appointment reminder for small businesses, not used for email marketing and such.
Related
Ok I know there are many possible duplicate questions but none answers my question.
According to Apple's App Store Review Guidelines (if it is the official one) I can only find 4 rules stating anything about messaging
5.5 Apps that use Push Notifications to send unsolicited messages, or for the purpose of phishing or spamming will be rejected
6.5 Apps that use Game Center service to send unsolicited messages, or for the purpose of phishing or spamming will be rejected
21.2 The collection of donations must be done via a web site in Safari or an SMS
22.6 Apps that enable anonymous or prank phone calls or SMS/MMS messaging will be rejected
According to me these rules does not restrict auto sending a message completely, if we have user's concern of sending the SMS.
Now I want to know is there's anyway that I can auto send SMS on a scheduled time when the app is suspended, like we can fire UILocalNotification?
If Yes then how and if No then why?
I also don't want to use any third party API or some server side programming. I want to send a simple SMS from phone.
No you can not send an e-mail or SMS via the Apple provided SDK without the user sending the messages.
You could setup your own mail server of SMS server to provide a solution to this, but you will not be able to do it with the Apple provided SDK.
The reason why this is implement this way is to protect the user, since you could just send 100 SMS to some kind of server number and thus make the user unaware of the costs.
Or you app could start spamming user with email by sending email without the users consent.
I am looking at building an ordering service, this is fine but my question is how to reliably get the order to the shop. It is a fast food shop.
Are there any solid delivery options either via sms/phone or an email service that is pretty much 100% reliable.
Take a look at some of the SMS providers like Twilio who give you web based APIs for sending SMS messages. There is also an API called the OneAPI that is currently available in Canada but will be in other regions soon. You can use this to send SMS messages through a html API.
For email, take a look at some of the providers listed by programmable web, there are a bunch, for example Yahoo lets you send messages via their API.
Yes make sure call back to sender for confirmation,...
check on my DMStar CBuilder6 system.
it fetch filtered email and sms QFree ordering system.
Every minute or so will auto print out onto docket dot matrix printer as soon order received.
https://sites.google.com/site/dmsqfree/tastykebabs
or google it with tasty kebabs qfree
https://sites.google.com/site/dmsqfree/
E C and simple for small retaillers, no register of sensitive personal details needed.
Using an old Nokia Mobile with prepaid $20.00 per year(free sms) connected into PC USB port,...
cheer.
I'm using my Google Apps account (Standard version) to send single emails (automatically) to real interested customers.
The problem is that my sender email account has been suspended, because it's been considered as a "spammer" by Google.
What can I do in order to send that kind of emails from now on? I use MailChimp to send massive emails, and I've seen it has an API, called STS, for sending single emails, but it also required an Amazon SES account, so I don't know whether to invest on those services or doing something else.
What do you recommend for this case?
You should try a service that specializes in sending "transactional" emails, such as Sendgrid, Postmarkapp and Mailjet.
They have APIs and libraries for most programming languages, but in your case you just need to configure the SMTP server they rovide in your email client and you're good to go. They help you not get into the spam folder of your recipients, and help make sure you don't get flagged as a spammer
With most of them you should get some prettty powerfull analytics as well, which is a nice bonus.
I'm making a quick Google App Engine program that presents a publicly available form that users can fill out with their name and email address, then can enter a friend's name and e-mail address. The application pulls in the data via POST, then sends a pre-formatted e-mail like 'Hi, , your friend wants to invite you...'
What should I be doing to prevent spammers from exploiting this publicly facing e-mail sending program? Is there a good resource for best-practices in this field? I've spent a few hours searching, but I haven't really found anything definitive...
Principally creating a publicly available form that anyone can use to send[s] a pre-formatted e-mail is another name for creating a spam machine.
You can mitigate by making it harder for non-humans to use it, recaptcha is the typical way to achieve this.
You could send a confirmation email to the sender and require a secondary action (like clicking a link) before sending the email. Or, if you expect your users to return, ask them to sign up (with a similar confirmation) before allowing them to send email.
I would first impose some limit to the # of email addresses a specific user/IP can send. This won't solve the problem but will limit the damage in case someone does try to send spam to 1000 emails.
Second, you could try sending the emails in small batches if an user puts in a lot of email addresses. Send 5 at a time, and monitor to see if there's any spam complaints (you can probably automate this somehow). If no complaints after 2 days, keep sending the rest.
With regards an OMS, what is the best method to send a confirmation email? The 2 options I have so far are;
A script on the order page sends an email once the record is written to the database.
A scheduled task on the server, send the email, polling the database every-so-often to find new entries.
Which method do systems currently use?
For e-commerce websites, it might be better to think about the best user experience.
Given that, you would want to send the email as soon as the order is received so the user knows that they have purchased the item. The sooner it gets into their inbox, the sooner they will be happy that they have made their purchase.
I agree with Digbyswift that sending the confirmation email once the record is written to the database is the least scalable. But I would argue that if your system has gotten to the point that you are taking so many orders that your system cannot keep up, you have a wonderful problem on your hands that you now probably have resources to handle.
At PostageApp, we handle the emails of a few e-commerce websites, so perhaps you would benefit from an arrangement with an email service provider to off-load this task so that all of your resources can be spent on keeping your site up and your databases running.
Here are some great alternatives if PostageApp is not your style:
Sendgrid
Postmark
Mailjet
This is a question of scalability. Sending a confirmation email once the record is written to the database is the least scalable. The more orders that are taken , the more emails are sent potentially tying up resources.
A scheduled task is certainly better as emails can be queued up and can be sent in a separate process.
A further option which you could consider is using neither and delegating the responsibility of sending emails to a 3rd party dedicated emailing service, i.e. via an API. This is much better since your hosting does not have to consider the load and you can utilise any reporting offered by the 3rd party. Plus many services offer a free quota up to a certain threshold. This will allow you OMS and business to scale appropriately.
If you apply a message based architecture; you could just publish an order created message and have any number of subscribers respond to that event. You could create a listener that sends the email in house (bespoke option) or another listener that called the API of a 3rd party emailer to send the email on your behalf (as per #Digbyswift)
What I've always liked about this approach is
You can have any number of listeners live at any one time.
You can create a new listener and change how you send the email without needing to change/redeploy the OMS application itself.
You can take the listener(s) off line and stop / delay the sending of the email without losing any notifications or affecting the OMS itself.