Rails - Aug 2006 - Monthly billing and payment processor recommendations?

Hi,

I''m setting up a site that will bill on a monthly basis.  I would
rather not have to worry about storing customer credit card
information.  Does anyone have recommendations on payment processors
that offer monthly billing services?
  I don''t want to go the paypal route as I want the user to stay on
the site.  I''m hoping to find an API to integrate with.  I have
contacted Cybersource and while they have a killer API, they don''t
provide Ruby integration yet.  I know some have used the Cybersource C
bindings but this seems messy.

Anyone out there have advice to share?

Thanks,
Zack

On 8/7/06, Zack Chandler <zackchandler@gmail.com>
wrote:
> Hi,
>
> I''m setting up a site that will bill on a monthly basis.  I would
> rather not have to worry about storing customer credit card
> information.  Does anyone have recommendations on payment processors
> that offer monthly billing services?
>   I don''t want to go the paypal route as I want the user to stay
on
> the site.  I''m hoping to find an API to integrate with.  I have
> contacted Cybersource and while they have a killer API, they don''t
> provide Ruby integration yet.  I know some have used the Cybersource C
> bindings but this seems messy.
>
> Anyone out there have advice to share?
>
> Thanks,
> Zack
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
Send bluepay.com an email and tell them what you''re doing.  I met a
rep at a conference, and apparently they do something where they store
CC info on their servers, and you basically just send a request to
them and say, "Bill account #4 for $40" and it happens. 
They''re a
full merchant account provider and gateway, if I remember correctly.

I think with authorize.net (available through basically every merchant
account provider) you can just set up recurring billing.  The downside
to that is that you can''t really offer coupons or allow people to
easily upgrade their plans without reentering info.  Once you set up a
recurring payment, it''s done, kind of like paypal''s
subscriptions.

On my site, I use two servers.  Each server stores half of a number,
encrypted.  When I want to bill a customer, server A asks server B for
the second half of the number and then sends it off to the gateway.
This way the entire number isn''t stored on a single server. 
It''s
worked very well for me, and because there''s no actualy single CC
number stored somewhere, it passes Visa''s CISP compliance.

I got my merchant account through loudcommerce.com, and use linkpoint
as my gateway.  I highly recommend asking them any questions you might
have.  Even if you don''t intend to sign up with them, they are
EXTREMELY helpful and knowledgeable.  When I was getting set up they
offered to do any billing programming I needed, but I was pretty much
done on that end anyway.  But that gives you an idea of the extent of
their service.

Pat

>
> On my site, I use two servers.  Each server stores half of a number,
> encrypted.  When I want to bill a customer, server A asks server B for
> the second half of the number and then sends it off to the gateway.
> This way the entire number isn''t stored on a single server. 
It''s
> worked very well for me, and because there''s no actualy single CC
> number stored somewhere, it passes Visa''s CISP compliance.
Storing the number like that doesn''t make you CISP compliant. 
It''s
pretty much impossible for a merchant to store cardholder data and be
cisp compliant because of all the requirements.

Chris

Snacktime,

Yeah - I''ve been reading through all CISP data security requirements
and it is a lot to confront!  I find it hard to believe that with
ecommerce being around as long as it has, that no one (that I have
found yet) has a simple open API that can do recurring billing.

One interesting read is Tobi''s post at:
http://blog.leetsoft.com/2006/03/14/simple-encryption.  This seems
like a reasonable way to implement the store-it-yourself method.

Any other thoughts?
Zack

On 8/7/06, snacktime <snacktime@gmail.com> wrote:
> >
> > On my site, I use two servers.  Each server stores half of a number,
> > encrypted.  When I want to bill a customer, server A asks server B for
> > the second half of the number and then sends it off to the gateway.
> > This way the entire number isn''t stored on a single server. 
It''s
> > worked very well for me, and because there''s no actualy
single CC
> > number stored somewhere, it passes Visa''s CISP compliance.
>
> Storing the number like that doesn''t make you CISP compliant. 
It''s
> pretty much impossible for a merchant to store cardholder data and be
> cisp compliant because of all the requirements.
>
> Chris
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On 8/7/06, snacktime <snacktime@gmail.com> wrote:
> >
> > On my site, I use two servers.  Each server stores half of a number,
> > encrypted.  When I want to bill a customer, server A asks server B for
> > the second half of the number and then sends it off to the gateway.
> > This way the entire number isn''t stored on a single server. 
It''s
> > worked very well for me, and because there''s no actualy
single CC
> > number stored somewhere, it passes Visa''s CISP compliance.
>
> Storing the number like that doesn''t make you CISP compliant. 
It''s
> pretty much impossible for a merchant to store cardholder data and be
> cisp compliant because of all the requirements.
>
> Chris
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
You''re right.  I reread my dialogue with my merchant account provider,
and if you split the data up like that then you don''t need to be CISP
compliant.

Pat

> You''re right.  I reread my dialogue with my merchant account
provider,
> and if you split the data up like that then you don''t need to be
CISP
> compliant.
Whoever told you that doesn''t know what they are talking about.
Every merchant has to be cisp/pci compliant.  There are no exceptions.
 Merchants that use payment gateways and don''t store cardholder data
don''t have to do anything because it''s done by the payment
gateway.
If you as a merchant store cardholder data, you could store each digit
of the card number on a different server and you would still have to
be compliant.  Besides, just splitting the cardnumber isn''t really
getting you anything.  If anything it''s probably just increasing your
risk.

Look, I''m just trying to inform people about the facts.  I''ve
either
ran or worked for payment gateways for the last 10 years, and I''ve
personally managed a number of cisp audits as well as designed a lot
of infrastructure that is used to run payment systems.

On 8/7/06, Zack Chandler <zackchandler@gmail.com>
wrote:
> Snacktime,
>
> Yeah - I''ve been reading through all CISP data security
requirements
> and it is a lot to confront!  I find it hard to believe that with
> ecommerce being around as long as it has, that no one (that I have
> found yet) has a simple open API that can do recurring billing.
>
By open api you mean an open source application of some type?  There
are a number of payment gateways that have good recurring api''s.  I
doubt you will find an open source solution.   I actually contemplated
doing something like that myself a while back, but with cisp/pci now
in place there just aren''t enough end users that could actually use
it.  The added infrastructure needed just isn''t worth it when you can
get the service from a payment gateway.  I also have the copyrights to
working software that connects to all the processing  networks.  But I
couldn''t release that as open source either because most of the
networks have NDA''s and contracts that preclude releasing any source
that implements their protocols.


> One interesting read is Tobi''s post at:
> http://blog.leetsoft.com/2006/03/14/simple-encryption.  This seems
> like a reasonable way to implement the store-it-yourself method.
>
> Any other thoughts?
> Zack
I''ve seen that, it''s a good way to encrypt the data, but
encryption
doesn''t give you security.

Snacktime,

By open API I mean a method to setup customer profiles and a billing
cycle all through an API that can be called via simple posts over ssl.

Authorize.net only allows setting up recurring billing this through
their web interface at the moment.  Their sales rep told me the API
will be updated in November to enable recurring billing calls.

Verisign has been swallowed by Paypal and I have heard bad things
about reliability since this transaction.

Cybersource has a ton of functionality built-in to their API but is
not open in the sense that it can not be called from ruby code.  It
can only be called through their SDK in ASP/COM, .NET, Java, C, PHP,
and Perl.  So unless you want to delegate to the C bindings in ruby
you are out of luck.

As for your last point that encryption doesn''t give you security, I
mostly agree.  It does though put you on the path to CISP compliance.
I really wonder what  percent of rails sites, even the big boys like
Basecamp, store credit card info correctly/securely/compliantly.
Makes you wonder...

Zack

On 8/7/06, snacktime <snacktime@gmail.com> wrote:
> On 8/7/06, Zack Chandler <zackchandler@gmail.com> wrote:
> > Snacktime,
> >
> > Yeah - I''ve been reading through all CISP data security
requirements
> > and it is a lot to confront!  I find it hard to believe that with
> > ecommerce being around as long as it has, that no one (that I have
> > found yet) has a simple open API that can do recurring billing.
> >
>
> By open api you mean an open source application of some type?  There
> are a number of payment gateways that have good recurring api''s. 
I
> doubt you will find an open source solution.   I actually contemplated
> doing something like that myself a while back, but with cisp/pci now
> in place there just aren''t enough end users that could actually
use
> it.  The added infrastructure needed just isn''t worth it when you
can
> get the service from a payment gateway.  I also have the copyrights to
> working software that connects to all the processing  networks.  But I
> couldn''t release that as open source either because most of the
> networks have NDA''s and contracts that preclude releasing any
source
> that implements their protocols.
>
>
>
> > One interesting read is Tobi''s post at:
> > http://blog.leetsoft.com/2006/03/14/simple-encryption.  This seems
> > like a reasonable way to implement the store-it-yourself method.
> >
> > Any other thoughts?
> > Zack
>
> I''ve seen that, it''s a good way to encrypt the data, but
encryption
> doesn''t give you security.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

I''ve implemented C binding for Cybersource API sometime ago.
You might find it useful.
http://datanoise.com/articles/2006/04/07/ruby-integration-with-cybersource


On 8/8/06, Zack Chandler <zackchandler@gmail.com>
wrote:
> Snacktime,
>
> By open API I mean a method to setup customer profiles and a billing
> cycle all through an API that can be called via simple posts over ssl.
>
> Authorize.net only allows setting up recurring billing this through
> their web interface at the moment.  Their sales rep told me the API
> will be updated in November to enable recurring billing calls.
>
> Verisign has been swallowed by Paypal and I have heard bad things
> about reliability since this transaction.
>
> Cybersource has a ton of functionality built-in to their API but is
> not open in the sense that it can not be called from ruby code.  It
> can only be called through their SDK in ASP/COM, .NET, Java, C, PHP,
> and Perl.  So unless you want to delegate to the C bindings in ruby
> you are out of luck.
>
> As for your last point that encryption doesn''t give you security,
I
> mostly agree.  It does though put you on the path to CISP compliance.
> I really wonder what  percent of rails sites, even the big boys like
> Basecamp, store credit card info correctly/securely/compliantly.
> Makes you wonder...
>
>
> Zack
>
> On 8/7/06, snacktime <snacktime@gmail.com> wrote:
> > On 8/7/06, Zack Chandler <zackchandler@gmail.com> wrote:
> > > Snacktime,
> > >
> > > Yeah - I''ve been reading through all CISP data security
requirements
> > > and it is a lot to confront!  I find it hard to believe that with
> > > ecommerce being around as long as it has, that no one (that I
have
> > > found yet) has a simple open API that can do recurring billing.
> > >
> >
> > By open api you mean an open source application of some type?  There
> > are a number of payment gateways that have good recurring
api''s.  I
> > doubt you will find an open source solution.   I actually contemplated
> > doing something like that myself a while back, but with cisp/pci now
> > in place there just aren''t enough end users that could
actually use
> > it.  The added infrastructure needed just isn''t worth it when
you can
> > get the service from a payment gateway.  I also have the copyrights to
> > working software that connects to all the processing  networks.  But I
> > couldn''t release that as open source either because most of
the
> > networks have NDA''s and contracts that preclude releasing any
source
> > that implements their protocols.
> >
> >
> >
> > > One interesting read is Tobi''s post at:
> > > http://blog.leetsoft.com/2006/03/14/simple-encryption.  This
seems
> > > like a reasonable way to implement the store-it-yourself method.
> > >
> > > Any other thoughts?
> > > Zack
> >
> > I''ve seen that, it''s a good way to encrypt the data,
but encryption
> > doesn''t give you security.
> > _______________________________________________
> > Rails mailing list
> > Rails@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

-- 
Kent
---
http://www.datanoise.com

On 8/7/06, Zack Chandler <zackchandler@gmail.com>
wrote:
> Snacktime,
>
> By open API I mean a method to setup customer profiles and a billing
> cycle all through an API that can be called via simple posts over ssl.
>
> Authorize.net only allows setting up recurring billing this through
> their web interface at the moment.  Their sales rep told me the API
> will be updated in November to enable recurring billing calls.
>
> Verisign has been swallowed by Paypal and I have heard bad things
> about reliability since this transaction.
>
> Cybersource has a ton of functionality built-in to their API but is
> not open in the sense that it can not be called from ruby code.  It
> can only be called through their SDK in ASP/COM, .NET, Java, C, PHP,
> and Perl.  So unless you want to delegate to the C bindings in ruby
> you are out of luck.
Ok I follow you.  Ya there are not a lot of payment gateways that have
completely automated recurring.  You might look at Itransact,
Trustcommerce, or Netbilling.   Authorizenet has been saying they will
have an automated recurring system for a while now.  They are so big
it''s just hard for them to move that fast on anything.  I''ve
been too
busy lately to do much research on the competition.  The company I
work for Payment Online has a simple ssl post api but the setup cost
is several hundred dollars.  Our market is primarily recurring billing
and we do have one of the best feature sets but it''s not the cheapest.

One thing you can do is go to visa''s website and in the cisp section
grab the pdf that has all of the compliant service providers listed.
Not all of the providers are gateways, but every gateway in the US is
in that pdf.  It''s also a good tool to use to tell who is just a
reseller and who actually owns the gateway.

Thanks Kent.  I had read this post and have considered going the
C-bindings route.

On 8/7/06, Kent Sibilev <ksruby@gmail.com> wrote:
> I''ve implemented C binding for Cybersource API sometime ago.
> You might find it useful.
> http://datanoise.com/articles/2006/04/07/ruby-integration-with-cybersource
>
>
> On 8/8/06, Zack Chandler <zackchandler@gmail.com> wrote:
> > Snacktime,
> >
> > By open API I mean a method to setup customer profiles and a billing
> > cycle all through an API that can be called via simple posts over ssl.
> >
> > Authorize.net only allows setting up recurring billing this through
> > their web interface at the moment.  Their sales rep told me the API
> > will be updated in November to enable recurring billing calls.
> >
> > Verisign has been swallowed by Paypal and I have heard bad things
> > about reliability since this transaction.
> >
> > Cybersource has a ton of functionality built-in to their API but is
> > not open in the sense that it can not be called from ruby code.  It
> > can only be called through their SDK in ASP/COM, .NET, Java, C, PHP,
> > and Perl.  So unless you want to delegate to the C bindings in ruby
> > you are out of luck.
> >
> > As for your last point that encryption doesn''t give you
security, I
> > mostly agree.  It does though put you on the path to CISP compliance.
> > I really wonder what  percent of rails sites, even the big boys like
> > Basecamp, store credit card info correctly/securely/compliantly.
> > Makes you wonder...
> >
> >
> > Zack
> >
> > On 8/7/06, snacktime <snacktime@gmail.com> wrote:
> > > On 8/7/06, Zack Chandler <zackchandler@gmail.com> wrote:
> > > > Snacktime,
> > > >
> > > > Yeah - I''ve been reading through all CISP data
security requirements
> > > > and it is a lot to confront!  I find it hard to believe that
with
> > > > ecommerce being around as long as it has, that no one (that
I have
> > > > found yet) has a simple open API that can do recurring
billing.
> > > >
> > >
> > > By open api you mean an open source application of some type? 
There
> > > are a number of payment gateways that have good recurring
api''s.  I
> > > doubt you will find an open source solution.   I actually
contemplated
> > > doing something like that myself a while back, but with cisp/pci
now
> > > in place there just aren''t enough end users that could
actually use
> > > it.  The added infrastructure needed just isn''t worth it
when you can
> > > get the service from a payment gateway.  I also have the
copyrights to
> > > working software that connects to all the processing  networks. 
But I
> > > couldn''t release that as open source either because most
of the
> > > networks have NDA''s and contracts that preclude
releasing any source
> > > that implements their protocols.
> > >
> > >
> > >
> > > > One interesting read is Tobi''s post at:
> > > > http://blog.leetsoft.com/2006/03/14/simple-encryption.  This
seems
> > > > like a reasonable way to implement the store-it-yourself
method.
> > > >
> > > > Any other thoughts?
> > > > Zack
> > >
> > > I''ve seen that, it''s a good way to encrypt the
data, but encryption
> > > doesn''t give you security.
> > > _______________________________________________
> > > Rails mailing list
> > > Rails@lists.rubyonrails.org
> > > http://lists.rubyonrails.org/mailman/listinfo/rails
> > >
> > _______________________________________________
> > Rails mailing list
> > Rails@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
>
>
> --
> Kent
> ---
> http://www.datanoise.com
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Thanks for the ideas Snacktime.  I really appreciate it.

Zack

On 8/7/06, snacktime <snacktime@gmail.com> wrote:
> On 8/7/06, Zack Chandler <zackchandler@gmail.com> wrote:
> > Snacktime,
> >
> > By open API I mean a method to setup customer profiles and a billing
> > cycle all through an API that can be called via simple posts over ssl.
> >
> > Authorize.net only allows setting up recurring billing this through
> > their web interface at the moment.  Their sales rep told me the API
> > will be updated in November to enable recurring billing calls.
> >
> > Verisign has been swallowed by Paypal and I have heard bad things
> > about reliability since this transaction.
> >
> > Cybersource has a ton of functionality built-in to their API but is
> > not open in the sense that it can not be called from ruby code.  It
> > can only be called through their SDK in ASP/COM, .NET, Java, C, PHP,
> > and Perl.  So unless you want to delegate to the C bindings in ruby
> > you are out of luck.
>
> Ok I follow you.  Ya there are not a lot of payment gateways that have
> completely automated recurring.  You might look at Itransact,
> Trustcommerce, or Netbilling.   Authorizenet has been saying they will
> have an automated recurring system for a while now.  They are so big
> it''s just hard for them to move that fast on anything. 
I''ve been too
> busy lately to do much research on the competition.  The company I
> work for Payment Online has a simple ssl post api but the setup cost
> is several hundred dollars.  Our market is primarily recurring billing
> and we do have one of the best feature sets but it''s not the
cheapest.
>
> One thing you can do is go to visa''s website and in the cisp
section
> grab the pdf that has all of the compliant service providers listed.
> Not all of the providers are gateways, but every gateway in the US is
> in that pdf.  It''s also a good tool to use to tell who is just a
> reseller and who actually owns the gateway.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

37signals does recurring billing with Basecamp and the rest.

Someone from that camp pony up and let us know how it''s being done. I
know
they use a custom Authorize.net payment class they wrote.

- S

On 8/8/06, Zack Chandler <zackchandler@gmail.com>
wrote:
>
> Thanks for the ideas Snacktime.  I really appreciate it.
>
> Zack
>
> On 8/7/06, snacktime <snacktime@gmail.com> wrote:
> > On 8/7/06, Zack Chandler <zackchandler@gmail.com> wrote:
> > > Snacktime,
> > >
> > > By open API I mean a method to setup customer profiles and a
billing
> > > cycle all through an API that can be called via simple posts over
ssl.
> > >
> > > Authorize.net only allows setting up recurring billing this
through
> > > their web interface at the moment.  Their sales rep told me the
API
> > > will be updated in November to enable recurring billing calls.
> > >
> > > Verisign has been swallowed by Paypal and I have heard bad things
> > > about reliability since this transaction.
> > >
> > > Cybersource has a ton of functionality built-in to their API but
is
> > > not open in the sense that it can not be called from ruby code. 
It
> > > can only be called through their SDK in ASP/COM, .NET, Java, C,
PHP,
> > > and Perl.  So unless you want to delegate to the C bindings in
ruby
> > > you are out of luck.
> >
> > Ok I follow you.  Ya there are not a lot of payment gateways that have
> > completely automated recurring.  You might look at Itransact,
> > Trustcommerce, or Netbilling.   Authorizenet has been saying they will
> > have an automated recurring system for a while now.  They are so big
> > it''s just hard for them to move that fast on anything. 
I''ve been too
> > busy lately to do much research on the competition.  The company I
> > work for Payment Online has a simple ssl post api but the setup cost
> > is several hundred dollars.  Our market is primarily recurring billing
> > and we do have one of the best feature sets but it''s not the
cheapest.
> >
> > One thing you can do is go to visa''s website and in the cisp
section
> > grab the pdf that has all of the compliant service providers listed.
> > Not all of the providers are gateways, but every gateway in the US is
> > in that pdf.  It''s also a good tool to use to tell who is
just a
> > reseller and who actually owns the gateway.
> > _______________________________________________
> > Rails mailing list
> > Rails@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


-- 
seth at subimage interactive
http://www.subimage.com/sublog/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060808/559fd736/attachment.html

Verisign has recurring billing and unlike Zach, I haven''t heard
anything bad
about their reliability.  I will say that if you''re using 64-bit
servers,
get ready to write your own SDK  (unless you want to use Java or .NET).  I
have been dealing with that headache for the past week.  If I write
something flexible, I''ll try cleaning it up and releasing it.

ed


On 8/8/06, Zack Chandler <zackchandler@gmail.com>
wrote:
>
> Thanks for the ideas Snacktime.  I really appreciate it.
>
> Zack
>
> On 8/7/06, snacktime <snacktime@gmail.com> wrote:
> > On 8/7/06, Zack Chandler <zackchandler@gmail.com> wrote:
> > > Snacktime,
> > >
> > > By open API I mean a method to setup customer profiles and a
billing
> > > cycle all through an API that can be called via simple posts over
ssl.
> > >
> > > Authorize.net only allows setting up recurring billing this
through
> > > their web interface at the moment.  Their sales rep told me the
API
> > > will be updated in November to enable recurring billing calls.
> > >
> > > Verisign has been swallowed by Paypal and I have heard bad things
> > > about reliability since this transaction.
> > >
> > > Cybersource has a ton of functionality built-in to their API but
is
> > > not open in the sense that it can not be called from ruby code. 
It
> > > can only be called through their SDK in ASP/COM, .NET, Java, C,
PHP,
> > > and Perl.  So unless you want to delegate to the C bindings in
ruby
> > > you are out of luck.
> >
> > Ok I follow you.  Ya there are not a lot of payment gateways that have
> > completely automated recurring.  You might look at Itransact,
> > Trustcommerce, or Netbilling.   Authorizenet has been saying they will
> > have an automated recurring system for a while now.  They are so big
> > it''s just hard for them to move that fast on anything. 
I''ve been too
> > busy lately to do much research on the competition.  The company I
> > work for Payment Online has a simple ssl post api but the setup cost
> > is several hundred dollars.  Our market is primarily recurring billing
> > and we do have one of the best feature sets but it''s not the
cheapest.
> >
> > One thing you can do is go to visa''s website and in the cisp
section
> > grab the pdf that has all of the compliant service providers listed.
> > Not all of the providers are gateways, but every gateway in the US is
> > in that pdf.  It''s also a good tool to use to tell who is
just a
> > reseller and who actually owns the gateway.
> > _______________________________________________
> > Rails mailing list
> > Rails@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060808/368a6dc4/attachment.html

> Verisign has recurring billing ...
Anyone have more information about this?  

As far as I can tell Verisign isn''t even in the payment processing
business
any more.  A very long time ago (> a few months, internet time) they were,
but they sold the division to PayPal.  The PayPal account rep I talked to
said they don''t have a recurring billing product in production for
PayFlow.

 - James Moore

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi James,
>> Verisign has recurring billing ...
>
> Anyone have more information about this?
I''ve integrated with Verisign''s (now PayPal''s)
PayFlow Pro recurring
billing
system a few times in the past and it works great.  You just send a  
message
using their API with the dollar amount, the frequency, and some  
instructions
on how to attempt a repeat charge in the event of failure and it  
takes care
of everything for you.
> The PayPal account rep I talked to said they don''t have a
recurring
> billing
> product in production for PayFlow.
They obviously haven''t been reading their own website :)

https://www.paypal.com/cgi-bin/webscr?cmd=_payflow-recurring-billing- 
overview-outside

- --

Thanks,

Dan
__________________________________________________________________

Dan Kubb
Autopilot Marketing Inc.

Email: dan.kubb@autopilotmarketing.com
Phone: 1 (604) 820-0212
Web:   http://autopilotmarketing.com/
vCard: http://autopilotmarketing.com/~dan.kubb/vcard
__________________________________________________________________



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFE439W4DfZD7OEWk0RAkyZAKCjvBglQZ1x4AFItFDHnJVxypFHOgCfUXcE
0Yt/IoGg1DOmXwpxW5pEdhY=BZqT
-----END PGP SIGNATURE-----

My name is Jorge Espinoza, a business development manager at EC Suite. We 
specialize in on-line transaction processing and provide an all 
inclusive e-commerce toolset designed to reduce the cost of processing 
and marketing while you focus on managing your business. Our 
subscription billing service allows for flexible pricing options and 
multiple payment types. You can create, cancel, and modify 
subscriptions as needed. This offers you a more predictable cash flow 
for your business, with the added convenience to your customers, and 
the cost savings for your business. You can call me on my direct line 
at (480) 682-3271 or email at jorgee-nxG3GajcpN7owKkBSvOlow@public.gmane.org 


Zack Chandler-2 wrote:
> 
> Hi,
> 
> I''m setting up a site that will bill on a monthly basis.  I would
> rather not have to worry about storing customer credit card
> information.  Does anyone have recommendations on payment processors
> that offer monthly billing services?
>   I don''t want to go the paypal route as I want the user to stay
on
> the site.  I''m hoping to find an API to integrate with.  I have
> contacted Cybersource and while they have a killer API, they don''t
> provide Ruby integration yet.  I know some have used the Cybersource C
> bindings but this seems messy.
> 
> Anyone out there have advice to share?
> 
> Thanks,
> Zack
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 
> 
-- 
View this message in context:
http://www.nabble.com/Monthly-billing-and-payment-processor-recommendations--tp5697275p15212065.html
Sent from the RubyOnRails Users mailing list archive at Nabble.com.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---