I currently work at a school and have an idea to create an app that allows students to contact a grown up (for example, the principle) anonymously through an app. The app would quite simply consist of a contact form. I am trying to find out the best, and easiest way to achieve this without setting up servers with a separate API. Does anyone have a suggestion on how to achieve it? Is there any way to set up an e-mail form with a pre set recipient and a built in sender-account? Please guide me in the right direction.
You would need to implement an SMTP client. You can use open source code like skpsmtpmessage
It's likely that their example app could be your solution.
Your biggest problem will be the deployment. You definitely need to pay an $99/y developer account and add all the students device ID's to your account (with a maximum of 100 devices/y) or register all of them as beta tester (I don't know the limitations).
Probably this isn't doable so easily, as it seems you don't have iOS developing experience so far. Maybe you can find something on the app store that works with self hosted databases. But you definitely need to host some kind of webApp/API.
You may want to give Appygram a try to handle the back-end if you are able to set up the contact form itself. While it's a separate hosted API, at least you don't have to build/manage it.
Appygram is a free web service that would allow you to configure all the details such as which adults could be contacted, their point(s) of contact (i.e. email address), and it would process and send all the submissions for you. All your app needs to do is send a form post request.
A nice thing about having this information outside of the iOS app itself is that you can change the contact details on the fly without requiring an update to the iOS app itself. Whether you use Appygram (which, since I contribute to it, I am slightly biased toward!) or something similar, I would say that since this is for students, I would recommend a solution that would allow you to update your configuration without requiring app updates.
Finally, I'd second what Julian said. The challenge here could be with deployment. One possible alternative would be to make this a mobile-friendly web page accessible only via student login or on the school network (or both). Would probably be easier development-wise and wouldn't require installs nor the hurdles that Julian described with device registration, etc. And, Appygram would still work with this setup as well.
Good luck!
I'm making a site for a coaching company, and they've requested that we somehow keep card information on file (I informed them that that is a big no-no, and most payment API's will handle that side of things for us) so that we can charge the cards 'on-demand'. For example, the person shows up to a coaching session, types in a pin, and it charges their card for one session.
Best case scenario- this also works for an online store as well for payment processing. Once the card is on file, they can create a card, punch in their password, and they are good to go.
We are currently using Authorize.net with Ruby on Rails. I'm still fairly new to the development world, and this is my first time needing to handle payment processing. As far as I have seen, there isn't as much documentation as there should be. They would prefer not to use Stripe, as it has high per-charge fees, and most of our fees are $8-$15, and they also want to avoid PayPal, as it has been known to freeze accounts for no good reason.
Storing credit card information on your side is not practical for two reasons - security and cost (PCI compliance). Your best option is to use Stripe or Braintree.
Both offer great libraries and work as payment aggregators (no need for a merchant account with a bank to start processing payments).
https://stripe.com/docs/api#cards
https://developers.braintreepayments.com/ios+ruby/sdk/server/payment-method-management/create
For Authorize.Net, you would use Customer Information Manager for secure data storage. http://developer.authorize.net/api/reference/starting_guide.html#customerInfoManagerID
I am trying to create a donation centre of sorts in Rails for a non-profit, using PayPal, and am wondering if I should start from scratch or use an existing eCommerce gem/platform.
I want to:
- list various "products", or donation types that a user can select, customize and pay for
- be able to send/serve downloadable files to a donor, depending on their donation type
- keep track of donors, donations and various custom bits of data the user enters
- add hooks to add donors to mailing lists, push donation notifications to social media, etc.
Basically, I want something that looks like a store and supports digital products, but processes donations instead of sales through PayPal.
Does anyone have experience using Spree (or something similar) to accept donations? I can't seem to find evidence that this works without a lot of hacking.
Thanks!
There are several ways of doing this, but each will require you to roll up your sleeves and get into the code. I would recommend, especially if you are learning rails, using Daniel Kehoe's "railsapp - Ruby on Rails Membership Site"
http://railsapps.github.com/rails-stripe-membership-saas/
It is a great tutorial and building block for what you are wanting to accomplish. Don't just copy/clone it and use it out the box, I would run through the tutorial to get a better understanding of what is going on and how you can customize it to meet your needs. It uses Stripe, for payment processing.
I am in my sophomore year of programming in general and Ruby on Rails more specifically. I have created several apps and finally have one that I would like to start charging for. I have never implemented something like this before and I feel like (from what I have read) most of the docs provided are a bit over my head. I don't mind diving in but before I did I wanted to get some opinion from those more experienced about what is the simplest way to implement a model for charging my User a month fee for use. Two notes:
My App contains Users already and I will be introducing a new section of the app which I only want to give access to those who pay.
I don't mind sending them to a third party page for payment.
From what I can find, it seems like both PayPal and Chargify do a decent job of providing help for this type of integration. What are your thoughts about which type of solution is best for a newbie to this space.
I'll admit I'm biased since I'm one of the founders of Chargify :-).
But before that I helped build 7-8 companies, most recently Engine Yard, and I really, really wish we'd had something like Chargify back then. I remember thinking, "Man, we need something like 'Basecamp for Billing'... it should be simple, sign up with a credit card, define products & pricing, and get going". So I found the Chargify/GrasshopperGroup folks and joined the team.
Chargify takes it up a level from what we found with payment gateway offerings and things like PayPal... with Chargify, you define products, prices, coupon codes, metered-usage units, etc., and let Chargify do as much as you want. The system emails your customers when their cards get declined or expire, and directs them to a URL to fix the problem, etc.
Billing gets complex as a business grows. I tell callers that if their needs are really simple, then they may indeed be okay with Auth.Net's ARB service or another like it, but as soon as your needs even begin to get less simple (ie, customers change plans mid-cycle and want proration), then Chargify really makes your life easier.
And as Rails folks ourselves, we're always working to make the service better, so you'll get more and more services as time progresses. And you can actually call us 24/7 and get someone on the phone! Our Level 1 phone team knows the product better and better each week and can send the call to Level 2 if they don't know the answer.
So, you're getting a good piece of software, plus a good team who's here for you to develop new features and provide support if you need it.
Sorry this sounds like an ad; it is, partly, of course. But it's also just a reflection of my frustration trying to build this at earlier companies, and my enthusiasm for being part of Chargify now and helping merchants not focus on recurring billing :-).
http://www.braintreepaymentsolutions.com/
At a previous place of employment, we used Brain Tree, and I only heard good things about it though I wasn't (and still aren't, but trying) a programmer at the time. It seems to be a little bit more expensive than the big guys - but has more freedom as well.
It might be worth looking into.
Charging System or Billing System?
Talking with a number of folks building businesses in the Ruby community, I thinks it's important to note that simply collecting customer payments and scalable billing are two rather unique animals. Today's SaaS companies are not always aware of the difference.
Hitting credit cards for $39.95 on a monthly basis is something most of the "payment tools" mentioned here do well. Yet, when one needs to incorporate a complex billing algorithm (charge model), client contracts, promotional codes, freemium, tiered, rollover or metered usage, or integration with other internal systems, They need more than a payment machine. They really need a "smarter" billing system that leverages a payment gateway, but does far more than simply hitting cards on a monthly basis.
Also, if one has a significant number of clients or volume a system that scales is key. For research check out more mid-tier billing systems like http://www.metanga.com or http://www.zuora.com.
To take payment you're going to need a few things:
A bank account to put the money in
A payment gateway
An SSL certificate (this can be tricky if you're in the cloud)
The beauty of products like chargify or braintree is that they give you a nice API for dealing with card events like expiry or failed payments and can sometimes also act as a payment gateway.
I integrated with cheddar getter (https://cheddargetter.com/) in an afternoon. There's a ruby gem (https://github.com/ads/cheddargetter) and they have a payment gateway service, but I haven't used that so don't want to comment on its value.
Payment is an annoyingly complicated process and you have to pay everyone down the chain, the hardest part is making sure your service is competitively priced but not priced in such a way where you're not making any profit.
Here's some more links you might be interested in reading:
http://www.activemerchant.org/
http://recurly.com/
I've used PayPal's Express Payments with ActiveMerchant before, because there's no buy-in cost; PayPal just takes their slice of each transaction, so I don't have to worry about paying fees to a ton of different providers. The downsides are well-documented, though, as well - specifically, if PayPal decides that you're doing something shady and decides to freeze your money, you're up the creek without a paddle. That's a calculated risk you have to evaluate, though.
You might look at Saasy if you don't want to roll your own full solution, though. It seems to integrate well with existing apps.
ActiveMerchant is definitely the way to go to get integration with PayPal or any of the creditcard gateways like Braintree (highly recommended) or Authorize.net (good and cheap). The SaaS Rails Kit, which I authored, uses it as the basis for a full recurring billing solution that you can integrate with your app.
Regarding your follow-on question about PayPal, ActiveMerchant makes it easy to use their API or IPN to get information back about the transaction status.
I've had a ton of experience with this and the first question that you need to ask yourself is "how important is recurring billing?" If recurring billing is a requirement then by all means use Chargify, Recurly or the like. They are all pretty good.
If, however, you are simply looking to outsource your payment process (as I typically am) so you don't have to deal with PCI compliance (which is a nightmare) then you have a lot LESS viable options IMO. You can use PayPal, Amazon or Google Checkout, but they all have downsides. PayPals user experience is terrible and many people get confused by it believing they need a PayPal account to complete the purchase. Google Checkout REQUIRES the user to either have or create a Google Account, which is ridiculous and Amazon is ok but like Google Checkout requires an Amazon account.
WePay is my personal favorite right now for outsourced billing but is very lean and you have to use their checkout process. Their staff and API is awesome though.
What I would LOVE to see if a Chargify-like solution that is focused on ONE OFF sales. Something that let's me host the entire checkout process on THEIR PCI Compliant server but allows me to customize not just the look and feel but form. If I wanted to ask for extra info, like a username and password, I can. If I don't need shipping address, I can remove it. If I only want the CC number, CVV and exp date without billing address I can do that, etc.
But to the best of my knowledge that does not currently exist. Don't use Chargify for one-off transactions. While they support it the checkout process is VERY clunky for one offs (displays things like $0 setup fee, which means nothing when someone is buying a shirt or one time downloadable material and is merely confusing).
Good luck!
I have a site where members write specialized articles. I'd like to allow my members the option of putting up a PayPal button to charge their readers for these articles.
Basically, I'd like to set it up so that a member can choose to charge for content or not. If they choose to charge for an article, then their reader must pay via PayPal before they can view the article.
What is the best way to do this?
Most PayPal website tutorials are geared towards how to integrate PayPal to sell items on one site and don't really cover how to allow a site's members to charge others.
I'd just like for members to use Website Payments Standard. I'd like to make it very simple for them to take payments. Just enter their PayPal email address into our admin console and our site will take care of everything else.
Do I need to have the member setup IPN to get this to work? Or can just adding their PayPal email be enough.
Anyhow, any tips or tutorials you could point to would be great. Also, I'm using rails if that makes a difference.
Thanks.
You touched on what my suggestion would be - have them specify their IPN URL to a resource on your site that would process the transaction and allow access to the article if appropriate.
Another option would be to process those payments yourself, then at the end of the month, say, use the Mass Pay feature to send money to all the authors. I'm not sure what your tax liability would be in this situation however - IANAL.