Hosted payment form and then process varying recurring transactions

[richarddavies]

Hi!

Our website charges a varying monthly amount to our customers, but we would rather not host any payment forms ourselves.

We would like a system in which Authorize.net host the credit card entry form for the initial payment transaction, and we can then charge a varying recurring amount against that same card.

For our UK website, we already achieve this with WorldPay (using a FuturePay Limited Agreement, as described at http://www.rbsworldpay.com/support/kb/bg/recurringpayments/rpfp1000.html) and with Sage Pay (using Repeat transactions, as described at http://www.sagepay.com/help/faq/what_is_continuous_authority). In both cases, the initial payment transaction is made on a hosted payment form, but we get back an ID which we can use to charge future recurring amounts.

I'd appreciate any advice on the Authorize.Net equivalent?

As far as I can tell, the Customer Information Manager (CIM) API is the only way to charge a varying recurring amount to a customer. However, it seems that if we use the CIM API then we have to host the payment pages on our own website and then pass the credit card details to Authorize.net using the CIM API.

Is there a way to use one of the hosted payment forms, such as Simple Checkout, Direct Post Method or Server Integration Method, and automatically save the details of successful payments into CIM, so that we can then process future payments against these details?

Or is there a way to repeat a successful transaction made in Simple Checkout, Direct Post Method or Server Integration Method?

Thanks,

Richard.

[stymiee]

As of right now the only way to handle varying recurring payments is to use CIM. Authnet has a large to do list which may include setting up CIM account through SIM, etc, so if those come to fruition that will change in the future.

[richarddavies]

Thanks - very helpful.

So if I want to make varying recurring payment, then it sounds like I have to take the credit card details via a payment form hosted on my own website, so that I can then pass these into CIM?

If I have to do that, then is there really any advantage to using CIM rather than just storing the credit card details in a local database my side and submitting them via AIM each time I want to take a payment?

Presumably I'd need full PCI compliance for my webserver whichever I did?

Thanks,

Richard.

[stymiee]

Use CIM. Not only are there fewer PCI compliance issues to worry about but you won't be a target for hackers. If your server is compromised you leave yourself open to lawsuits and possibly criminal liability depending on where your business is located. It's always a bad idea to store credit card information on your server. If anyone tells you otherwise they are giving you very bad advice. 

[jeffshaikh · Accepted solution]

CIM is definatley the way to go, as is stores the credit cards on the authorize.net server, BUT it does absolutely nothing to help with PCI compliance or reduce the merchant liability . The only way (right now) to get the data into CIM is through XML or SOAP submitted from the merchants server.  If the merchants server "touches" the cc data,  the merchant server and application is inside the scope of PCI compliance.

Not all security compromises involve access to stored data on the server. CIM will not protect the merchant or data from vunerabilites that involve accessing sessions, or data during transmission like session highjacking, XXS, code injection, CSRF, etc.

To truely secure the data we need to integrate CIM with SIM. So the cardholder data does not touch the merchant server.

[richarddavies]

I think that this last post is probably the correct situation.

This seems a big flaw in the Authorize APIs if you can't do CIM and be PCI compliant!

I note that WorldPay, for instance do better - you can create a FuturePay agreement (their equivalent of both ARB and CIM) based on an initial payment taken through their hosted payment forms (their equivalent of SIM).

There are other big advantages in setting up CIM from a SIM transaction - for instance the initial SIM transaction could be 3D-Secured (assuming SIM supports this), whereas it's hard to see how a CIM transaction can ever be 3D secure, since the whole point it that it takes place in the background without user intervention.

[eternicode]

---

@jeffshaikh wrote:

To truely secure the data we need to integrate CIM with SIM. So the cardholder data does not touch the merchant server.

---

Agreed.  If we could somehow tell SIM that it should create a CIM profile and post-back the profile's ID to us somehow, that would vastly simplify situations like this.

[psrichmond]

Any update on this?  Has authorize.net created a solution to use SIM to create a CIM record?

[stymiee]

Not yet

[robdowns]

Just wondering if the solution to this was to create a seperate hosted page for CIM? (using .GetHostedPageProfile in the API)

Or if there would eventually be more integration with the SIM transactions so the two sets of customers would not need to be treated seperatly?

The hosted page for CIM might solve the OP's orginal issue. It looks like this may have been added recently since it's in the documentation, but you need to update the API service in the Sample Code to see this feature....

Anyway, just wondering about this, and sorry for posting to an older thread...

Thanks!