I have a bit of a conundrum with my Rails application. It looks like the model we are going to use for billing is per-use as opposed to a subscription basis (at least initially). While we've already implemented Recurly's Transparent Post API (great product), it's likely overkill.
We could simply establish a free plan with no monthly charge and then initiate one time transactions. This satisfies the level of PCI Compliance we are looking for and also allows returning customers to have their credit card information stored by a third party.
To further complicate things, there may be a requirement in the future for subscription based plans in addition to the per-use billing. I am looking for some advice about whether to stay with the recurring billing platform or whether I might want to simply use ActiveMerchant, not store credit cards and deal with the change in PCI Compliance (onus is on us and not a third party). Also wondering if there is another tool that handles one-time repeatable transactions without having a subscription plan?
You could use ActiveMerchant with Authorize.net CIM or Braintree to store the card info for you (for the PCI compliance) and run transactions for whatever amount at whatever time based on the token you would get back from either of those. That wouldn't preclude from adding on the recurring billing later -- you would just start charging against those stored tokens on an automated basis.
The SaaS Rails Kit (which I wrote) takes this approach for doing both the recurring billing and one-off transactions.
Related
Implementing Paypal for a UK based NGO where they are selling certain services plus accepting donations.
I am using REST API for selling services which is working well but do we use the same API for Donation as well. I would like to handle Gift Aids as well. I dont see any payment type option within the API.
If I use the standard Donation button, how do I get the transaction Id and other values back so that I can save them in my system.
There is no real technical difference between donations and payments for goods and services. (The donations button is just a few cosmetic differences on top of a regular website payments standard or EC payment experience.) The REST is not yet as feature rich as the older payment flows and may not have those same cosmetic tweaks available, but you can definitely use either the REST or the classic API for both services and donations.
I would recommend not using both REST and classic together on your site; you will encounter many annoyances due to differences in the underlying models. It is not just the initial payment integration that is different; the payment IDs are different, the APIs you can use to manage the payment lifecycle are different etc.
As one such example, to answer your question #2 you cannot get REST-style payment IDs for non-REST transactions. You get back classic transaction IDs in the payment redirect or the DoEC API response, depending upon which integration you use. You also get classic payment IDs if you integrate IPNs (whereas with REST you would integrate webhooks... the differences keep coming!).
I'm looking at the possibility of setting up limited acceptance of debit cards online. However, as I research, I see that there are huge differences in the interchange rate between debit cards that are regulated under the recent Durbin amendment and those that are exempt. Depending on my merchant account fee structure, this could give us wildly different costs based on how the transaction gets categorized.
If I'm using authorize.net as the gateway, is it possible to use their API to determine the categorization of the card on the interchange with just an authorize transaction? (and thus accept only cards that I know can be processed cheaply, and give an "i'm sorry" message to everyone else). Is there any other way to identify them without actually making the charge on the card?
Unfortunately there isn't. The rates used to process a transaction are determined at transaction time and are not available via any API. You can only find out what rate was charged by viewing the reporting offered by the merchant account provider.
Before jumping in I'd like to know what all of my options are, and, if possible their pros and cons.
The two I know of are using ActiveMerchant, or the paypal_recurring gem, but will they satisfy these requirements?
Ability to accommodate monthly and annual billing
Ability to suspend, cancel accounts etc
Deal with out-of-date card details or failed payments
The to-do list for the paypal_recurring gem includes 'adding support for IPN' - how will not having this impact functionality?
I know there is the railskit SaaS but I'd rather code something myself as the railskit is still on 3.2.1.
I know there are services like cheddergedder/chargify etc, but do they tie you in? Are they US only? Are they worth considering - or are they usually just aimed at non-developers?
Thanks in advance.
I just finished going through this, so I'll try to shed some light on your options. I ended up using Paypal Express Checkout for all recurring purchases through Paypal. We had a custom-rolled recurring billing setup that charges a customer's credit card monthly through Authnet, but had to switch because we needed an international solution, and Paypal was one of the only ones that supported the currencies we needed, and wasn't entirely a nightmare to code.
You can use ActiveMerchant for recurring billing with this plugin, though keep in mind that it is not officially a part of ActiveMerchant, and therefore is subject to break if ActiveMerchant changes how it handles certain things. Because of that, I ended up using the paypal-recurring to handle communication through Paypal, and then rolled my own IPN parser, with help from Railscasts. Another link that helped me a lot was this, though all the :txn_type values ended up being different.
With regards to that last link, here are the 4 :txn_types that I specifically watch out for:
express_checkout - first postback.
recurring_payment_profile_created - sent on first postback when the user first subscribes.
recurring_payment_profile_cancel - sent if user cancels subscription from Paypal's site.
recurring_payment - Money has been transferred to your account. This is what I wait for before I renew their subscription on a monthly. This post also comes with payment_status, which needs to be completed.
The other stuff you mentioned, like handling failed payments and out-of-date cards, is handled through your Paypal account.
Just a word of warning - the only reason I ended up using Paypal is because it is universally recognized and trusted, and it accepted international currencies. There is an enormous amount of documentation on their site, and most of it is redundant, confusing, and entirely too long. My recommendation is to make sure you really want/need to deal with recurring payments, as they are difficult to implement correctly and can be more trouble than they're worth.
I'm currently looking at Ryan Bates example of Stripe. They are a California based company that uses/offers the features you have listed.
www.stripe.com
They only charge when you receive money. I think that they are 3% plus $0.30 per successful transaction. Much better than some other companies that have a monthly minimum. Right now you have to have a bank in the USA to use their services as a merchant. However, anyone can use your site with out of the country credit cards.
The SaaS Kit is now tested with Rails 3.2.2. :) It doesn't support IPN yet, but it's on to the todo list. With all the info here in one spot, I suppose I have no excuse not to get it done. :)
I'm building a marketplace application:
The customer pays the seller on the marketplace
The marketplace takes a cut of the payment
I would have a payment processing system with the following features
The cut and the 100%-cut are sent directly to the marketplace and seller accounts (ie, I don't want to have 100% on the marketplace account and then to forward the 100%-cut to the seller)
I would love to have a UI as much integrated with the marketplace website as possible. This implies that the customer in the worst case has to put only name, surname and credit card number on the payment processor interface (the ideal would be a payment interface totally integrated with our website)
I don't want to force the customer to register to any third party service
It should work nicely with Ruby on Rails
It should work for non US-based companies and should support multicurrency payments
What are the options out there?
Thanks.
I'd recommend you look at our product Balanced. It's built to solve exactly this problem so I think it's a good match.
At a high level payments in are done via credit card like a normal payment processor, funds are deposited into an escrow account which is a sum of all funds collected - all funds disbursed. When you're ready to push funds out you can currently pay out via next-day ACH (US only) but we're building out international support which sounds like it would be useful for you.
I believe it matches your other requirements:
there is no requirement to send users offsite, they do require accounts but you can create and edit them via the API.
Balanced has an excellent ruby gem
You can split up the payment, taking a cut from the proceeds as profit
Balanced provides you with a merchant dashboard for you and your customers to get a head start but you can build the exact same thing via API access.
One area where it's not going to meet your requirements is multi-currency charges. Currently you'll need to charge in USD and convert.
Check out https://github.com/drhenner/ror_ecommerce It doesn't have all the features you want but will give you a big head start.
Basically active merchant will connect to most gateways. You need to add the custom code. Look at the video for more help http://ror-e.com/info/videos/1
I've written a subscription based web app that I want to charge (by credit card) a monthly fee. There are 3 different plans and once they sign up, they should be billed that amount, automatically, every month until they cancel. Is there an easy way to set this up (some sort of online service maybe?).
You can use Paypal's merchant service to provide reoccurring charges for a subscription.
Pretty easy to implement, they provide plenty of examples and even a sandbox to get you up and running.
There are now some service providers that take care of your billing and subscription needs. You use their API and they handle billing and subscriptions for you. Their services work with payment systems like PayPal and Authorize.Net.
Take a look at the following sites:
Chargify
Spreedly
Cheddargetter
I would suggest not using Paypal or Authorize's recurring payments directly. Their APIs are brutal, and the functionality is very rudimentary. It may work fine for when you're just starting out, but if you ever want to change anything down the line, you'll be in trouble.
I work for CheddarGetter, so I'm biased, but you should check us out.
Our competitors are not as robust or flexible, but they are definitely better than using Paypal or Authorize.net directly.