Online credit card processing

[Ben Knight]

What's a good way to process credit cards from our Rails application?

I like PayPal because of it's name recognition but I don't like the fact
that the user must leave our site; we are hoping for a tightly
integrated look-and-feel. We might also offer both, PayPal and our own
major credit card processing (see attached example screen shot).

I've heard of other names such as ActiveMerchant, ActiveNet,
TrustCommerce and UsaEPay, etc. Of course, there is also Google
Checkout and I believe Amazon has introduced a new payment processing
service.

Any help would be greatly appreciated. Thanks!

Attachments:
http://www.ruby-forum.com/attachment/1793/creditcardprocessing.jpg

--
Posted via http://www.ruby-forum.com/.

[jmhirsch]

Ben,

We use ActiveMerchant. It acts as a abstract API to most of the
popular online processing gateways. It's offer support for both
gateways which host the html and also sending data to the gateway as a
background post. We are using it to process to Authroize.net,
Braintree, and Paypal. If you are looking for a merchant account as
well I would recommend looking into Braintree as their customer
support is superior to Authorize.net.

Lastely, keep in mind that if you want to collect the customers
payment information only on your site, you are responsible for making
sure your application is PCI DSS complaint which are the security
standards from the credit card companies. There are hefty fines (>
$500,000) if you have card data stolen from one of your sites.

Many of the payment gateways that ActiveMerchant services have
solutions to accept data in a secure manner.

Good Luck!

Justin Hirsch

On Apr 26, 10:44 am, Ben Knight <rails-mailing-l...@andreas-s.net>
wrote:

[Ben Knight]

Thanks a bunch, Justin. This is very helpful!

Your credit card stolen comment reminds me of another question, hope you
don't mind. Do you guys store the credit cards on your site (e.g.
similar to amazon)? We aren't planning on storing credit cards at this
point and even though it's inconvenient for customers, we'll ask them
for this info each time.

What are your thoughts on storing credit cards versus not?

Thanks,
Ben

jmhirsch wrote:
> Ben,
>
> We use ActiveMerchant. It acts as a abstract API to most of the
> popular online processing gateways. It's offer support for both
> gateways which host the html and also sending data to the gateway as a
> background post. We are using it to process to Authroize.net,
> Braintree, and Paypal. If you are looking for a merchant account as
> well I would recommend looking into Braintree as their customer
> support is superior to Authorize.net.
>
> Lastely, keep in mind that if you want to collect the customers
> payment information only on your site, you are responsible for making
> sure your application is PCI DSS complaint which are the security
> standards from the credit card companies. There are hefty fines (>
> $500,000) if you have card data stolen from one of your sites.
>
> Many of the payment gateways that ActiveMerchant services have
> solutions to accept data in a secure manner.
>
> Good Luck!
>
> Justin Hirsch
>
> On Apr 26, 10:44 am, Ben Knight <rails-mailing-l...@andreas-s.net>

--
Posted via http://www.ruby-forum.com/.

[Hassan Schroeder]

On Sat, Apr 26, 2008 at 12:29 PM, Ben Knight
<rails-mai...@andreas-s.net> wrote:

> What are your thoughts on storing credit cards versus not?

I'm not Justin :-) but --

As he said, the liability is very high; unless you have a lot of money
to put into security -- initial and ongoing -- it's IMHO not worth it.

However, be aware that if you need to reverse (refund) a transaction,
your CC gateway (e.g. Authorize.net) may require something like the
last 4 digits of the card as well as the transaction ID they issued.

So see what's required for all potential interactions, not just the sale.

FWIW!
--
Hassan Schroeder ------------------------ hassan.s...@gmail.com

[Matt White]

If you need to store payment info for repeated use, I recommend that
you look into TrustCommerce and their Citadel product. It lets you
store payment info in their systems, and they provide you a payment
key you can use for repeated charges. Great for subsciption type
services, as it saves you from the security hassle while allowing you
to charge customers without asking them for a card every time. I'm
currently using their tclink library for php on a site, and i believe
they have one for ruby as well...

good luck!

matt

--
Matt White
-----------------------
Thermal Creative
http://blog.thermalcreative.com

[Ben Knight]

Thanks, Hassan and Matt.

[Kyle]

We use PayPal Website Payments Pro for both regular PayPal
transactions and credit card transactions. We need to have PayPal as
a normal payment option in our business, and it made sense to use it
for both credit card and PayPal transactions. Customers don't leave
our site unless they have to log into a PayPal account to get their
money. Also, I found their NVP (name-value pair) API to be easy to
work with.

We don't store card numbers. PayPal will let us issue a refund
without having a number. The only time that this has been a problem
is when I have suspected fraud. Card companies won't do anything for
you if you don't have the full account number, it seems, even if
you're trying to tell them that somebody is obviously using a stolen
card on your site. Other than that, I'm glad to be free of at least
that liability.

-Kyle

On Apr 26, 10:56 pm, Ben Knight <rails-mailing-l...@andreas-s.net>
wrote:

[Alain Ravet]

Ben

> I like PayPal because of it's name recognition but I don't like the fact
> that the user must leave our site;

I like being redirected to Paypal: that way I know for sure that my
credit card data won't be stored on a poorly secured HD.
If your site is a well known brand with good reputation, that's another story.

Alain

[chris]

There are a lot of bad stories in regards to PayPal. Has anyone had
any, that someone who is thinking about including a PayPal payment
option should be aware of? I have a hard time fully trusting some of
the stories on other sites that endorse a single alternate payment
solution.