Authorize.net CIM

[Jesse Proudman]

Has any one modified ActiveMerchant to work with Authorize.net's CIM
release from about 2 weeks ago? If not, would any one be interested
in bundling this into Active Merchant? We've got development funds
for whomever can make it happen.


--

Jesse Proudman
Blue Box Group, LLC

p. +1.800.613.4305 x801
e. je...@blueboxgrp.com

[Tobias Lütke]

Cool that they offer this service now. too bad that they didn't extend
AIM to work with it like trustcommerce does.

Still this may be worth implementing.

--
Tobi
http://shopify.com - modern e-commerce software
http://typo.leetsoft.com - Open source weblog engine
http://blog.leetsoft.com - Technical weblog

[CptOatmeal]

I'm taking a shot at implementing this. I was wondering if anyone
would like to weigh in on what the public API should look like.

Currently, I have a gateway class with the non-standard :
create_profile
create_payment_profile
create_shipping_profile

and the corresponding get/update/delete methods.

I have seen a recommendation stating that it would be best to
represent this as the three methods #store, #unstore, and #authorize.
While this could work (depending on the options supplied to each
method,) I'm not sure if this is any better than having a different
method for each action.

The system is already fairly non-standard, as the CIM has more complex/
different functionality than most of the gateway's handled by
ActiveMerchant.

Any thoughts?

-Thanks
CptOatmeal

[Cody Fauser]

Tobi and I just discussed the best way to go with CIM. We're thinking
that what you're suggesting is the best way to proceed. We can keep
all of the functionality of CIM in an entirely new gateway, and then
later on implement purchase(), authorize(), store(), and unstore()
methods in the current AuthorizeNetGateway in terms of the new gateway
you're writing.

This way someone wanting the entire functionality of CIM has access to
it, but we can still provide a consistent API for those that don't
need all of the features. Sound good?

--
Cody Fauser
http://shopify.com - e-commerce done right
http://www.codyfauser.com - blog
http://www.oreilly.com/catalog/rjsrails - RJS Templates for Rails

[CptOatmeal]

Perfect! So I'll just put this all in an AuthorizeNetCIMGateway <
Gateway with the appropriate methods.

I as also thinking of possibly making a plugin that represents the
customer profile data like an AR model.
After all, the API is basically just a set of CRUD operations on a
remote data store. All the normal methods
would work, they would just access remote data behind the scenes.

On Dec 6, 10:40 am, "Cody Fauser" <codyfau...@gmail.com> wrote:
> Tobi and I just discussed the best way to go with CIM. We're thinking
> that what you're suggesting is the best way to proceed. We can keep
> all of the functionality of CIM in an entirely new gateway, and then
> later on implement purchase(), authorize(), store(), and unstore()
> methods in the current AuthorizeNetGateway in terms of the new gateway
> you're writing.
>
> This way someone wanting the entire functionality of CIM has access to
> it, but we can still provide a consistent API for those that don't
> need all of the features. Sound good?
>

[Cody Fauser]

Sounds great. You may want to make it the AuthorizeNetCimGateway, as
horribly ugly as that is, so that
ActiveMerchant::Billing::Base.gateway(:authorize_net_cim_gateway) will
work. Or is there something nicer?

[Cody Fauser]

Should be: ActiveMerchant::Billing::Base.gateway(:authorize_net_cim)

[patrick...@gmail.com]

Has there been any progress on this effort?

My company is currently working on cleaning up the ARB patches and
hope to have them submitted tomorrow. Unfortunately, we are becoming
increasingly concerned that ARB won't be flexible enough for our
purposes. We would prefer not to store CC info if we don't have to so
CIM would be the next option.

If we need it, I'll be happy to implement CIM according to the
recommendations above, but I would rather not duplicate effort.

- Patrick Joyce
http://pragmati.st

On Dec 6 2007, 12:47 pm, "Cody Fauser" <codyfau...@gmail.com> wrote:
> Should be: ActiveMerchant::Billing::Base.gateway(:authorize_net_cim)
>

> On 12/6/07, Cody Fauser <codyfau...@gmail.com> wrote:
>
>
>
> > Sounds great. You may want to make it the AuthorizeNetCimGateway, as
> > horribly ugly as that is, so that
> > ActiveMerchant::Billing::Base.gateway(:authorize_net_cim_gateway) will
> > work. Or is there something nicer?
>

> > On 12/6/07, CptOatmeal <shalev.nessai...@gmail.com> wrote:
>
> > > Perfect! So I'll just put this all in an AuthorizeNetCIMGateway <
> > > Gateway with the appropriate methods.
>
> > > I as also thinking of possibly making a plugin that represents the
> > > customer profile data like an AR model.
> > > After all, the API is basically just a set of CRUD operations on a
> > > remote data store. All the normal methods
> > > would work, they would just access remote data behind the scenes.
>
> > > On Dec 6, 10:40 am, "Cody Fauser" <codyfau...@gmail.com> wrote:

> > > > Tobi and I just discussed the best way to go withCIM. We're thinking

> > > > that what you're suggesting is the best way to proceed. We can keep

> > > > all of the functionality ofCIMin an entirely new gateway, and then

> > > > later on implement purchase(), authorize(), store(), and unstore()
> > > > methods in the current AuthorizeNetGateway in terms of the new gateway
> > > > you're writing.
>

> > > > This way someone wanting the entire functionality ofCIMhas access to

> > > > it, but we can still provide a consistent API for those that don't
> > > > need all of the features. Sound good?
>
> > > > On 12/5/07, CptOatmeal <shalev.nessai...@gmail.com> wrote:
>
> > > > > I'm taking a shot at implementing this. I was wondering if anyone
> > > > > would like to weigh in on what the public API should look like.
>
> > > > > Currently, I have a gateway class with the non-standard :
> > > > > create_profile
> > > > > create_payment_profile
> > > > > create_shipping_profile
>
> > > > > and the corresponding get/update/delete methods.
>
> > > > > I have seen a recommendation stating that it would be best to
> > > > > represent this as the three methods #store, #unstore, and #authorize.
> > > > > While this could work (depending on the options supplied to each
> > > > > method,) I'm not sure if this is any better than having a different
> > > > > method for each action.
>

> > > > > The system is already fairly non-standard, as theCIMhas more complex/

> > > > > different functionality than most of the gateway's handled by
> > > > > ActiveMerchant.
>
> > > > > Any thoughts?
>
> > > > > -Thanks
> > > > > CptOatmeal
>
> > > > > On Dec 3, 10:32 pm, "Tobias Lütke" <tobias.lue...@gmail.com> wrote:
> > > > > > Cool that they offer this service now. too bad that they didn't extend
> > > > > > AIM to work with it like trustcommerce does.
>
> > > > > > Still this may be worth implementing.
>
> > > > > > On Dec 3, 2007 9:00 PM, Jesse Proudman <je...@blueboxgrp.com> wrote:
>
> > > > > > > Has any one modified ActiveMerchant to work with Authorize.net'sCIM
> > > > > > > release from about 2 weeks ago? If not, would any one be interested
> > > > > > > in bundling this into Active Merchant? We've got development funds
> > > > > > > for whomever can make it happen.
>
> > > > > > > --
>
> > > > > > > Jesse Proudman
> > > > > > > Blue Box Group, LLC
>
> > > > > > > p. +1.800.613.4305 x801
> > > > > > > e. je...@blueboxgrp.com
>
> > > > > > --
> > > > > > Tobihttp://shopify.com - modern e-commerce softwarehttp://typo.leetsoft.com-Opensource weblog enginehttp://blog.leetsoft.com-Technicalweblog
>
> > > > --

> > > > Cody Fauserhttp://shopify.com-e-commerce done righthttp://www.codyfauser.com-bloghttp://www.oreilly.com/catalog/rjsrails-RJS Templates for Rails

[Jesse Proudman]

We hired some one to build the app and it has been 95% completed.
The only problem we're having is that if you loose the token the user
was stored under, there doesn't seem to be any way to fetch it back
and if you try to re-add the user. Besides that, it's basically
ready to go.

Thanks,

Jesse Proudman
Blue Box Group, LLC

p. 800-613-4305 x 801

>>>>> Cody Fauserhttp://shopify.com-e-commerce done righthttp://

>>>>> www.codyfauser.com-bloghttp://www.oreilly.com/catalog/rjsrails-
>>>>> RJS Templates for Rails
>>
>>> --
>>> Cody Fauser
>>> http://shopify.com- e-commerce done right
>>> http://www.codyfauser.com- blog
>>> http://www.oreilly.com/catalog/rjsrails- RJS Templates for Rails
>>
>> --

>> Cody Fauserhttp://shopify.com- e-commerce done righthttp://

[patrick...@gmail.com]

Excellent. Please let me know if there is anything I can do to help
(rdocs, tests, etc.)

I look forward to seeing the patch.

- Patrick Joyce

On Jan 19, 1:21 pm, Jesse Proudman <je...@blueboxgrp.com> wrote:
> We hired some one to build the app and it has been 95% completed.
> The only problem we're having is that if you loose the token the user
> was stored under, there doesn't seem to be any way to fetch it back
> and if you try to re-add the user. Besides that, it's basically
> ready to go.
>
> Thanks,
>
> Jesse Proudman
> Blue Box Group, LLC
> p. 800-613-4305 x 801
>

> >>>>> Cody Fauserhttp://shopify.com-e-commercedone righthttp://

> >>>>>www.codyfauser.com-bloghttp://www.oreilly.com/catalog/rjsrails-
> >>>>> RJS Templates for Rails
>
> >>> --
> >>> Cody Fauser

> >>>http://shopify.com-e-commerce done right
> >>>http://www.codyfauser.com-blog
> >>>http://www.oreilly.com/catalog/rjsrails-RJS Templates for Rails
>
> >> --

[Mason]

Any word on CIM integration? I've been tasked to duplicated the work
that's apparently been started here. It would be awesome if I had a
bit of good luck on timing.

Mason

On Jan 19, 11:21 am, Jesse Proudman <je...@blueboxgrp.com> wrote:
> We hired some one to build the app and it has been 95% completed.  
> The only problem we're having is that if you loose the token the user  
> was stored under, there doesn't seem to be any way to fetch it back  
> and if you try to re-add the user.  Besides that, it's basically  
> ready to go.
>
> Thanks,
>
> Jesse Proudman
> Blue Box Group, LLC
> p. 800-613-4305 x 801
>

> On Jan 18, 2008, at 10:26 PM, patrick.t.jo...@gmail.com wrote:
>
>
>
> > Has there been any progress on this effort?
>
> > My company is currently working on cleaning up the ARB patches and
> > hope to have them submitted tomorrow. Unfortunately, we are becoming
> > increasingly concerned that ARB won't be flexible enough for our
> > purposes. We would prefer not to store CC info if we don't have to so

> >CIMwould be the next option.
>
> > If we need it, I'll be happy to implementCIMaccording to the

> >>>>> Cody Fauserhttp://shopify.com-e-commercedone righthttp://

> >>>>>www.codyfauser.com-bloghttp://www.oreilly.com/catalog/rjsrails-
> >>>>> RJS Templates for Rails
>
> >>> --
> >>> Cody Fauser

> >>>http://shopify.com-e-commerce done right
> >>>http://www.codyfauser.com-blog
> >>>http://www.oreilly.com/catalog/rjsrails-RJS Templates for Rails
>
> >> --

[Jesse Proudman]

It's for the most part done. There are a few bugs that exist on
Authorize.net's side that we're trying to work through.

Thanks,

Jesse Proudman
Blue Box Group, LLC
p. 800-613-4305 x 801

[patrick...@gmail.com]

Blue Box was kind enough to put there work up at http://code.google.com/p/activemerchant-cim/

After reviewing their code, Ian Lotinsky and I didn't think that the
Blue Box code was going to get into the trunk (owing to a dependency
on the XMLSimple gem and other reasons outlined in our patch
submission). So we did a fresh implementation.

Our current patch is very much a draft, but we wanted to get it out
there and get feedback as soon as possible.

Please see Issue 103 (http://code.google.com/p/activemerchant/issues/
detail?id=103) for details.

- Patrick Joyce
http://pragmati.st

> >>>>>>> Cody Fauserhttp://shopify.com-e-commercedonerighthttp://

> >>>>>>>www.codyfauser.com-bloghttp://www.oreilly.com/catalog/rjsrails-
> >>>>>>> RJS Templates for Rails
>
> >>>>> --
> >>>>> Cody Fauser

> >>>>>http://shopify.com-e-commercedone right
> >>>>>http://www.codyfauser.com-blog

> >>>>>http://www.oreilly.com/catalog/rjsrails-RJSTemplates for Rails
>
> >>>> --

[jeff_wigal]

It looks like the CIM support was committed a few days ago. I am very
excited to take this for a spin!

-Jeff Wigal

On Feb 1, 8:32 pm, "patrick.t.jo...@gmail.com"
<patrick.t.jo...@gmail.com> wrote:
> Blue Box was kind enough to put there work up athttp://code.google.com/p/activemerchant-cim/

>
> After reviewing their code, Ian Lotinsky and I didn't think that the
> Blue Box code was going to get into the trunk (owing to a dependency
> on the XMLSimple gem and other reasons outlined in our patch
> submission). So we did a fresh implementation.
>
> Our current patch is very much a draft, but we wanted to get it out
> there and get feedback as soon as possible.
>
> Please see Issue 103 (http://code.google.com/p/activemerchant/issues/
> detail?id=103) for details.
>

> - Patrick Joycehttp://pragmati.st

>
> On Jan 29, 4:39 pm, Jesse Proudman <je...@blueboxgrp.com> wrote:
>
> > It's for the most part done. There are a few bugs that exist on
> > Authorize.net's side that we're trying to work through.
>
> > Thanks,
>
> > Jesse Proudman
> > Blue Box Group, LLC
> > p. 800-613-4305 x 801
>
> > On Jan 29, 2008, at 1:33 PM, Mason wrote:
>

> > > Any word onCIMintegration? I've been tasked to duplicated the work

[bpa...@gmail.com]

If I use CIM do I need to use ARB for recurring billing? I read the
documentation for both but still not sure why they have two APIs. TIA.

On Mar 19, 10:41 am, jeff_wigal <jwi...@gmail.com> wrote:
> It looks like theCIMsupport was committed a few days ago.  I am very

> > > >>>>>>>>> Tobihttp://shopify.com- modern e-commerce softwarehttp://

[patrick...@gmail.com]

The two APIs do slightly different things.

ARB is for simple subscription management. If you're charging a card
the same amount at a given time interval then you probably should use
ARB.

CIM is to store credit card information so that you can charge
arbitrary amounts at any given time. The canonical example would be to
store CC information at an online store so that customers don't have
to re-enter it each time they make a purchase. It is much more
flexible than ARB and can also be used for recurring payments. So, if
the amount you charge varies, or you need to charge at irregular
intervals, then you need to use CIM. If you want to have recurring
payment with CIM then you will need to implement your own recurring
logic.

The createCustomerProfileTransaction in CIM does have a
recurringBilling attribute that can be either TRUE or FALSE, but it
isn't clear what that does and we didn't implement it.

We ended up implementing both the ARB and CIM patches so that we could
process recurring payments. We initially wanted to use ARB, but it
wasn't flexible enough for our needs. In the end, we used CIM and
implemented our own recurring logic. We have a cron job that runs a
script each night that checks what invoices are due and charges them.

Patrick Joyce
www.sandwichboard.com

> > > > >>>>>>>>> Tobihttp://shopify.com-modern e-commerce softwarehttp://

[bpa...@gmail.com]

Thank you. I got confused because of that recurring flag in CIM and
there is no way to specify the interval etc.

My client wants a solution that is capable of handling subscription
charges for website membership (monthly, quarterly, annual) and also
for handling purchases on his site. So, how about I use CIM to store
all the customer data and when I need to make the ARB call I can
retrieve it by using CIM? (happens in a Rake task run by a cron job).

On Apr 1, 6:30 pm, "patrick.t.jo...@gmail.com"

> > > > > >>>>>>>>> Tobihttp://shopify.com-moderne-commerce softwarehttp://

[patrick...@gmail.com]

I don't think that will work.

ARB and CIM are completely separate APIs. Furthermore, you can't get
the credit card number back out of CIM once you've put it in. (You can
get a masked version, but you can't create an ARB subscription without
the actual card number)

I think what you want to do is use CIM and charge the card via
createCustomerProfileTransaction. It sounds like the Rake task you
have running by a cron job would be a decent place to put the
recurring logic.

Patrick Joyce
www.sandwichboard.com

> > > > > > >>>>>>>>> Tobihttp://shopify.com-moderne-commercesoftwarehttp://

[bpa...@gmail.com]

Your solution also solves another problem: In ARB there is no way to
know whether the recurring charges are getting processed successfully.
Am I correct?

Thank you. I checked out your site, it looks cool. Great idea and good
execution!

On Apr 2, 6:27 pm, "patrick.t.jo...@gmail.com"

[patrick...@gmail.com]

> Your solution also solves another problem: In ARB there is no way to
> know whether the recurring charges are getting processed successfully.
> Am I correct?

I believe that you are correct. I had forgot about that, but we also
didn't see a way to check that the payment actually succeeded and that
was another factor in our decision to use CIM.

Thanks for the compliment on SandwichBoard. If you know any restaurant
owners please mention us.

Patrick Joyce
www.sandwichboard.com

[markpuck]

I use the Silent Post URL to get ack about all payments, including ARB
payments. It includes the status of the recurring payment whether it
succeeded or failed.


On Apr 5, 3:03 pm, "patrick.t.jo...@gmail.com"

[Lake Denman]

This is interesting. Could you maybe post an example of your
implementation?
It sounds like something useful!

Lake.

[markpuck]

Here is the basic entrypoint for it:

def authorizenet_postback
# log but don't process postbacks that aren't for arb
subscriptions
logger.info(params)
return render(:text => 'hi') if params[:x_subscription_id].nil?

case params[:x_response_code].to_i
when ActiveMerchant::Billing::AuthorizeNetGateway::APPROVED
handleApprovedPayment(params)
when ActiveMerchant::Billing::AuthorizeNetGateway::DECLINED
handleDeclinedPayment(params)
when ActiveMerchant::Billing::AuthorizeNetGateway::ERROR
handlePaymentError(params)
when ActiveMerchant::Billing::AuthorizeNetGateway::FRAUD_REVIEW
handleFraudReviewPayment(params)
end
end

As you can see, I'm ignoring normal payment postbacks and only acting
on ARB posts.
The parts of the params that are of main interest are:
:x_invoice_num => "123",
:x_subscription_id => "2125824",

You can lookup the user's order and write an associated payment entry
to the db with status. I have a cron job that runs at night looking
at the new payment entries and statuses, and emails people whose
credit cards have expired, etc.

-Mark

[bpa...@gmail.com]

If your server is down for some reason then you will not be able to
record the results posted to the silent post back URL. How do you
handle this case? TIA.