Linda
asked this on May 10, 2011 10:05 am
Hi, I would like to implement Chargify solution, however found
this old example written in Rails 2 and haven't updated since
2009
https://github.com/npverni/chargify-demo.
Can you provide a Rails 3 example code, or better yet to do a Railscast like video to walk through the solution? Your potential customers will appreciate this!!!
Do Chargify engineers go to ROR hackathons in Boston? If so, i would like to meet them to guide me through a smooth implementation. Thanks.
Comments
Hello Linda,
Thank you for contacting Chargify.
I am forwarding your message to our technical sales team for their review.
Regards,
Hey Linda,
Yeah, that old app is pretty old, was written quickly by a guy who wanted to work for us (we later hired him). But it's not a supported app.
What I can do is tweet a link to this ticket and see if some Rails folks can help. Want me to try that? If so, do you have a Twitter username that I can include in the tweet?
Thanks.
--- Lance
Hi Lance,
My twitter handle is @sagenaut8. It would be neat that Chargify has an updated ruby sample code since it is written in ROR. Thanks.
Linda
Any responses to this? Lance, I have to say, that's a pretty weak response. You should be making it as easy as possible for developers to add your product to our apps. I think it would be great if you got one of your staff(or hired someone specifically) to create a screencast for developers who may be unfamiliar with the code.
Thanks
Jason
Hi Lance, i totally agree w/ Jason. Chargify will beat all competitors if one of your ROR developer can make a 30 minute videocast plus having some sample code. Easy to implement is so crucial given every provider provides similar features. Linda
Linda/Jason,
There is a good tutorial (not a screencast unfortunately) that was provided by a Chargify user. It's available here.
I'm the guy who wrote the .NET api wrapper, but I've been playing with RoR since coming to help the guys with support. I'll see about doing a screencast of this tutorial (or something similar) in the soon future, just depends on time.
Hope this helps :)
-- Kori (@djbyter)
Thanks Kori, appreciate the response. That tutorial is good but its not for the api which is really what developers would need. Not meaning to be contentious here, but I don't understand why Lance and the management at Chargify aren't making it a priority to get all the tools developers can use to try to add Chargify to their client's applications. Am I missing something? It seems like it should be a no-brainer, you have crazy rails talent there I'm sure, someone could probably put it out in a few days.
Thanks again for response Kori
J
Hi Kori, this is for hosted page. Agree w/Jason and look forward to your upcoming toturial for API integration. Linda
Hi Linda & Jason,
Believe me, I'd love to have this done asap, but at 475 merchants now, the demands are all over the map. Far more merchants want, for instance, more coupon functions or a hosted end-user portal that requires no programming at all, or a PHP sample app (PHP is now our largest segment).
It's the same problem as just about any growing business... 'x' resources, 100x desires from customers :-) So there are many good things that have to wait.
--- Lance
Hi Lance,
I plan to go ahead w/ the easier hosted solution. Will your team
@railsconf to help me out?
Thanks,
Linda
Hey Linda,
Our developers will be there and happy to chat, but they're hard to get for more than a short chat because they'll be in sessions all day long.
But go ahead and reach out to @moklett @npverni and @jwhitmire on Twitter and they can let you know their availability.
Thanks.
--- Lance
Thanks, Lance
No prob.
I know they're trickling in, cause I see tweets and pics from them roaming around Baltimore already. Oh, actually, that last pic was of the Statue of Liberty, so that particular person is still with his wife & children in NYC :-)
--- Lance
I may bump into them @bohconf tomorrow. I followed the great tutorial
that Kori sent me about the hosted page, however still not made it
work yet
http://blog.formedfunction.com/post/4022209767/how-to-integrate-cha...
I organized a ROR hackfest in NYC yesterday and worked w/ several
senior developers on this, yet still no recurring billing running for
my "change the world" app yet.
http://www.meetup.com/ruby-75/events/17366477/
I understand that your largest customer segment is php now, however w/
your root in rails and the surging popularity of rails, chargify can
super-power its revenue by investing a little in ROR integration
tutorial.
Linda,
Yeah, we'll def do something around this, just need to allocate time/resources.
Now, I know there are hundreds of merchants who used Rails to integrate to Chargify :-). Do you want me to tweet this ticket out and see if anyone can lend a hand? That works a lot, actually.
--- Lance
Hi Linda,
Just seen your message and thought would point out this piece of example code that someone put together a while ago, it should help you handle the integration of the webhooks which will allow your app to react to various events that happen on chargify.
https://gist.github.com/601151
It's only one part of the integration, but every example helps, right!
Scott
Thanks, Scott!
We're working on a Rails 3 sample app, too, so hopefully everyone's contributions will help.
Hi,
I may be late here, but I have made a blog post and updated the above mentioned gist to be rails 3 compatible. It revolved around the webhooks functionality specifically. http://www.redguava.com.au/2011/04/rails-3-chargify-webhooks-and-ho...
I have just about completed integration of the chargify api into my rails 3 web app, so happy to chat with anyone that has questions, can find me on twitter @jfriedlaender
In my Rails 3 shopping cart at checkout I’m currently calling a confirm action in my PurchaseController:
def confirm
@new_subscription = Chargify::Subscription.create(…)
end
Does anyone know what calls I should make to integrate webhook responses to confirm the subscription went through and how I can do this while the user waits?
Thanks!
@Dan: we'll soon be publishing some "best practice" guidelines, and one of them is to not use Webhooks in situations that require the user to be waiting. We're constantly working to make Webhooks "near instant", but the fact of the matter is that you are better pulling information while the customer waits rather than waiting for a push.
Your `@new_subscription`, if created successfully, will respond with 'true' to 'valid?' and is a real subscription and contains all of the information about the subscription. If the signup was unsuccessful, that call will give you an object that is not 'valid?' and will contain the errors from signup. If it is valid and successful, it also contains an ID that you can use to save to your own database, thereby linking the chargify subscription to the account in your own app.
Webhook pushes remain a great way to keep your app in sync with Chargify in a passive manner - when the customer is not waiting.
Thanks for your reply, @Michael. It's a bit of help and I'm very much looking forward to the best practices document.
I'm still concerned, however, because latency in the above scenario isn't actually my main concern with webhooks -- my main concern is that they are unreliable (for sync or otherwise). If my server is down, the transmission gets corrupted, there is a problem on your server, etc then webhook events may not be sent and captured. I have been told by one of your developers, actually, that they should actually never used as the only form of updating accounts for this reason. Therefore I'm concerned that it isn't "a great way to keep your app in sync", actually and do wonder what would be the best way.
I wish there was code published in ruby which would make event synchronization easy.
If there was, for instance, an api call where I could retrieve the latest events from your server, for instance, that might be a straightforward solution, perhaps?. My understanding is that to be reliable, I currently need to make api calls via cron jobs, but I'm not sure how to wrote those calls to detect just new events that need to be processed. Thanks!