Forum: Ruby on Rails Adding payment to an app: how hard and risky is it?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
B45eab4f18aa1bb2a44d6e657531a642?d=identicon&s=25 Alain Ravet (aravet)
on 2006-02-14 14:07
Hi all.

I have never implemented online payment and it's the only thing that
keeps me from accepting a project for a UK based client. (I must reply
quickly!)

While I can afford spending an extra week - or 2 - to learn/try/tune the
payment system, I must be sure to succeed before I accept the contract.
If you've already been through that path, any hints, links and/or
starting points are welcome.

Requirement:
1/ work for U.K. users (buyers)
2/ at the minimum, allow payment with a Visa card.


Alain
3ccecc71b9fb0a3d7f00a0bef6f0a63a?d=identicon&s=25 Kent Sibilev (Guest)
on 2006-02-14 16:28
(Received via mailing list)
Alain,

I've changed our electronic payment provider about tree times already.
Each time it took me no more than two hours to write an integration
code. Don't be afraid, just make sure your provider has a web based
API available.

Cheers,
Kent.
F3dc06f587d1ff4c7366b102bfda9204?d=identicon&s=25 David Mitchell (Guest)
on 2006-02-14 20:40
(Received via mailing list)
Kent,

The obvious questions:
- why did you change providers?  What marks a good one from a bad one?
- who are you using now (as they're presumably the best in your
experience)?

Thanks in advance

Dave M.
8c49880a7f274947b01d576c5828a5f6?d=identicon&s=25 Lon Baker (spdemac)
on 2006-02-14 20:50
Kent,

It is as hard and risky as your client chooses to make it.

Using something like Paypal, with Instant Payment Notification, has less
risk and is relatively easy.

Storing actual credit card data and handling processing completely
inside the application has much higher risk and is much harder.

The client in the end needs to make the decision, weighing the customer
experience, acceptable risk and development costs.

All my applications take the Paypal with IPN route, simply because I
want to focus on what I do best, and not worry about storing extremely
sensitive information.

Using the shared experience and contributions of the Rails community
most of the technical aspects are easy to overcome quickly.
4bd34a2216dc8bdbf1f017f64e4d59e8?d=identicon&s=25 Kyle Maxwell (Guest)
on 2006-02-14 21:04
(Received via mailing list)
On 2/14/06, Lon Baker <lon@speedymac.com> wrote:
> The client in the end needs to make the decision, weighing the customer
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

DO NOT store credit card information.  That opens you to a world of
security problems and auditing expenses.

For me, I run Verisign Payflow Pro, and it was easy to setup and
integrate.

--
Kyle Maxwell
Chief Technologist
E Factor Media // FN Interactive
kyle@efactormedia.com
1-866-263-3261
Ba3a00606eb530dcab2c4a6a59bf366d?d=identicon&s=25 Alain Ravet (Guest)
on 2006-02-14 21:26
(Received via mailing list)
Kent,

   > I've changed our electronic payment provider about tree times
already.
   > Each time it took mKent,e no more than two hours to write an
integration

It's not surprising that modular design would make this happen.  But
it's only about changing the last ring of the chain.

The main questions remain:
 - How hard is it to add payment to a web app (when you know nothing
about it)?
Another way to ask it is :
 - What's the simplest way to add electronic payment to a Rails web app?

and also
 - How risky is it (traps to avoid?).

Alain
Ff43001ac5fe9805aa6ca2e89d3b7b5d?d=identicon&s=25 Jake Janovetz (janovetz)
on 2006-02-14 21:32
Kyle Maxwell wrote:
> DO NOT store credit card information.  That opens you to a world of
> security problems and auditing expenses.
>
> For me, I run Verisign Payflow Pro, and it was easy to setup and
> integrate.

How does one avoid this with recurring payments?

   Jake
91eb330fb36d1e03c856574dfb77d2bc?d=identicon&s=25 Thibaut Barrère (Guest)
on 2006-02-14 21:44
(Received via mailing list)
Hi Alain

I would not recommend storing credit card information unless you are
in a shop which has the ressources and expertise required to deal with
this kind of things (which is usually not the case in places I've
seen! well, that's a very specific job).

Instead you could have a look at providers such as
http://www.bibit.com/ (which I've used) or
http://www.atosworldline.com/UK/offerings/payment.htm (which I only
know by the number of sites here in france who delegate the payment to
atos).

When I used Bibit, it was relying on an XML API to create
transactions. The general idea is : after creating a transaction, you
get a dedicated URL (bibit hosted) where your customer is redirected
to enter payment details (you don't even want to have access to that
information). The user is then redirected to your website etc.

Also that's just an opiniated view I have, but a (non-small) european
ecommerce site should not rely exclusively on paypal, and should go
the credit card road to ensure a broader coverage.

hope this helps!

Thibaut Barrère
--
[blog] http://www.dotnetguru2.org/tbarrere
119af50160cabfe1fb6f2f05f5018c64?d=identicon&s=25 James Ludlow (Guest)
on 2006-02-14 21:44
(Received via mailing list)
On 2/14/06, Jake Janovetz <jake@janovetz.com> wrote:
> Kyle Maxwell wrote:
> > DO NOT store credit card information.  That opens you to a world of
> > security problems and auditing expenses.
> >
> > For me, I run Verisign Payflow Pro, and it was easy to setup and
> > integrate.
>
> How does one avoid this with recurring payments?

VeriSign offers it as a service.  I would imagine that others do as
well.

I've never set any of this up, but this thread got me interested in
the topic so I've been looking up some details.

-- James
119af50160cabfe1fb6f2f05f5018c64?d=identicon&s=25 James Ludlow (Guest)
on 2006-02-14 21:47
(Received via mailing list)
On 2/14/06, Thibaut Barrère <thibaut.barrere@gmail.com> wrote:
> Also that's just an opiniated view I have, but a (non-small) european
> ecommerce site should not rely exclusively on paypal, and should go
> the credit card road to ensure a broader coverage.

PayPal accepts credit cards from non-members.

-- James
91eb330fb36d1e03c856574dfb77d2bc?d=identicon&s=25 Thibaut Barrère (Guest)
on 2006-02-14 21:47
(Received via mailing list)
> PayPal accepts credit cards from non-members.

Well - then I change my opiniated view :) Thanks for the tip.
678aa0aabf79a4933b7efc6d585dc141?d=identicon&s=25 Matt White (Guest)
on 2006-02-14 21:53
(Received via mailing list)
I'm in a similar situation... I'm considering building a site where
clients
can "one-click" purchase items for download, which would require some
type
of payment information storage. Is it possible to set up some type of
pre-authorized payment with the gateway, and then rely on the gateway to
store the info? This may be a totally crazy concept, but I've read some
things that lead me to believe that this was a possibility. It's similar
to
taking recurring transactions, except that they are charged when they
buy
something instead of on a fixed schedule.

Thanks!

Matt
91067c65f1bfedaaa22972fff95b3274?d=identicon&s=25 Wiebe de Jong (Guest)
on 2006-02-14 22:20
(Received via mailing list)
Hi everybody,

This is my first post to this list since joining yesterday.

There are two ways of doing this with Verisign's Payflow Pro.

Recurring Billing

Verisign does have a recurring billing feature. You'll have to pay extra
for
it, but if you want something simple it is the way to go. After you
submit
the initial transaction, you can get rid of the credit card info.
Verisign
will automatically bill the customer a fixed amount every period. Lots
of
options for setting it up make it versatile.

I didn't like the batch process part of it though. They gather up all
your
recurring transactions planned for the day into one batch. You get the
results of the batch in an email that you would have to then manually
process somehow. I didn't like the lack of control.

Referenced Billing

Well, that is what I call it anyway. After you submit the initial
transaction, you can get rid of the credit card info. Verisign gives you
a
reference id that points to that transaction, which you can safely store
in
your database. When your application decides it is time to bill again,
it
can submit another transaction without having the customer involved.
This
transaction will not contain any credit card data, because you don't
know
it. You do include the reference id from the first transaction though,
and
Verisign uses the credit card data from the referenced transaction in
this
transaction. The nice thing here is that your system gets immediate
feedback
as to the outcome with no manual processing! Also, you don't have to pay
extra for the recurring billing feature.

It doesn't matter if some hacker steals your database and gets the
reference
id values. There is no way to use them to get the credit card data.

Wiebe de Jong
Ff43001ac5fe9805aa6ca2e89d3b7b5d?d=identicon&s=25 Jake Janovetz (janovetz)
on 2006-02-14 22:23
James Ludlow wrote:
> VeriSign offers it as a service.  I would imagine that others do as
> well.
>
> I've never set any of this up, but this thread got me interested in
> the topic so I've been looking up some details.

I use Authorize.net for an online store but it doesn't use recurring /
automated billing.  Authorize.net supports this feature, but I haven't
used it.

Has anyone used Authorize.net with a Rails app?

I assume the little guys like Basecamp, TextDrive are using something
like a payment gateway with automated billing -- but store the last
4-digits to display to the user, correct?

   Jake
91067c65f1bfedaaa22972fff95b3274?d=identicon&s=25 Wiebe de Jong (Guest)
on 2006-02-14 22:23
(Received via mailing list)
Yes. This is definitely possible.



See the 'Referenced Billing with Verisign's Payflow Pro' portion of my
previous post.



Wiebe de Jong



  _____

From: rails-bounces@lists.rubyonrails.org
[mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Matt White
Sent: Tuesday, February 14, 2006 12:53 PM
To: rails@lists.rubyonrails.org
Subject: Re: [Rails] Re: Adding payment to an app: how hard and risky is
it?



I'm in a similar situation... I'm considering building a site where
clients
can "one-click" purchase items for download, which would require some
type
of payment information storage. Is it possible to set up some type of
pre-authorized payment with the gateway, and then rely on the gateway to
store the info? This may be a totally crazy concept, but I've read some
things that lead me to believe that this was a possibility. It's similar
to
taking recurring transactions, except that they are charged when they
buy
something instead of on a fixed schedule.

Thanks!

Matt

On 2/14/06, Kyle Maxwell <kyle@kylemaxwell.com> wrote:

On 2/14/06, Lon Baker <lon@speedymac.com> wrote:
> The client in the end needs to make the decision, weighing the customer
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org  <mailto:Rails@lists.rubyonrails.org>
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

DO NOT store credit card information.  That opens you to a world of
security problems and auditing expenses.

For me, I run Verisign Payflow Pro, and it was easy to setup and
integrate.

--
Kyle Maxwell
Chief Technologist
E Factor Media // FN Interactive
kyle@efactormedia.com  <mailto:kyle@efactormedia.com>
1-866-263-3261
374cb8ccd196db80af224b28a4f604dd?d=identicon&s=25 Chad Pytel (Guest)
on 2006-02-14 23:03
(Received via mailing list)
We have used TrustCommerce's product, "Vault", in the past.
http://www.trustcommerce.com/vault.php

It allows you to submit a customer's credit card info into "the vault"
and get back a unique ID - you can at a later date then just say "hey
vault, charge customer X for $30.00".

-Chad

Matt White wrote:
>
>     >
>     >
>     > _______________________________________________
>
>     http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

--
Chad Pytel, President
thoughtbot, inc.
organic brains. digital solutions.
----------------------------------
tel: 617.876.4780
fax: 866.217.5992
http://www.thoughtbot.com
3ccecc71b9fb0a3d7f00a0bef6f0a63a?d=identicon&s=25 Kent Sibilev (Guest)
on 2006-02-15 04:04
(Received via mailing list)
Actually I didn't change providers, my client did. I don't know
specific reasons for that. I am only interested in the technical part
of this process. From the technical prospective they are almost the
same. They all provide pretty much the same API and features like
credit card services, electronic checks, paypal services, etc.

We are currently using CyberSource. They provide SDK with C libraries
and it was just a matter of writing a small Ruby extension, nothing
serious really.

Kent
3ccecc71b9fb0a3d7f00a0bef6f0a63a?d=identicon&s=25 Kent Sibilev (Guest)
on 2006-02-15 05:59
(Received via mailing list)
Alain,

It's not hard. Most providers like authorize.net provide a simple way of
electronic payment through submitting a simple https post request with
certain parameters. When you are adding payment to your web app we just
have
to be careful by not storing credit card numbers and especially CVV
numbers
(which is strictly prohibited btw) in your database. At least try to
avoid
it.

Kent
032fdb4cd4a3c65ebb77846dfa724679?d=identicon&s=25 Joe Noon (Guest)
on 2006-02-15 07:24
(Received via mailing list)
> It's not hard. Most providers like authorize.net provide a simple way of
> electronic payment through submitting a simple https post request with
> certain parameters. When you are adding payment to your web app we just have
> to be careful by not storing credit card numbers and especially CVV numbers
> (which is strictly prohibited btw) in your database. At least try to avoid
> it.

Check out www.modernauthorize.net -- they offer the same form submit
type gateway and very cheap to start up, although there are probably
fiscally better ones if you had large volumes of processing.  They use
bluepay (but you cant get it as cheap directly through bluepay iirc),
which I've written a class for.  Its fairly simplistic and might need
some tweaking for your application, but it works well.  If you go with
them, I wouldn't mind sharing my class, just email me.

Joe Noon
23f9e65601ff85dd9d015d2245d5a99a?d=identicon&s=25 Carl Porth (Guest)
on 2006-02-15 07:48
(Received via mailing list)
On Tuesday 14 February 2006 3:23 pm, Jake Janovetz wrote:
>
> Has anyone used Authorize.net with a Rails app?
>
> I assume the little guys like Basecamp, TextDrive are using something
> like a payment gateway with automated billing -- but store the last
> 4-digits to display to the user, correct?
>
>    Jake

There is a ruby gem called Payment that might be worth looking at.  It
currently only supports one merchant, Authorize.net.  Perhaps the
adoption of
Rails might inspire more contributions to it, or even the development of
a
plugin.

Carl
0091f92762685860109bbcb02edfdf27?d=identicon&s=25 Alain Ravet (Guest)
on 2006-02-15 10:43
(Received via mailing list)
Kent
    > Alain,
    > It's not hard.

Is it so "not hard" that you could write a short
      "HowTo add Paypal payment to your app in 5 minutes"

for the wiki?
:)
The Flickr screen screencast has spoiled me.

Alain
This topic is locked and can not be replied to.