Adding a Credit Card Processor

[system]

Hello,

I’d like to add support for a new credit card processor called Elavon, and have a few questions.

1. Where in the code should I look for hooks to do CC transactions and settlement?

2. Is there support for an ‘xtuple daemon’ of sorts? In my use case, I envision my websites connecting to an xTuple server on the back end, and the
   xTuple server does the actual CC transaction. I’d rather NOT duplicate this functionality… however, if it’s possible to implement the CC transactions
   as a shared library, then I could write a CC daemon that uses the same shared library as the main xTuple application.

Thoughts?

Cheers,
-Josh

[changx]

Posted by: gmoskowitz

Josh,

To add a new credit card processor you need to

  add configuration options to the configureCC window,

  add a couple of lines to getCreditCardProcessor() in the CreditCardProcessor class to allow the rest of the app to retrieve an instance of your cc processor,

  and subclass CreditCardProcessor (creditcardprocessor.h).

Your subclass should at minimum overload handlesCreditCards and the do* methods: doTestConfiguration, doAuthorize, doCharge, … These aren’t documented very well so you’ll have to read a lot of code to make your implementation work.

There are three different examples in the GUI client code already: authorizedotnetprocessor., yourpayprocessor., and externalccprocessor.*. Both Authorize.Net and YourPay use HTTP to talk to a web service. The common code is implemented in the CreditCardProcessor class. External processing uses an application window to collect information from the user (the processing occurred ‘externally to the application’ and this is just a data entry step for tracking).

Currently there is no xtuple daemon to handle credit card transactions. The message building and network communication are all done inside the main application.

If you’ve already set up your development environment (see the Developer Zone in the Docs section of the website), this should be enough to get you started.

Gil

[system]

Thanks, Gil.

I’m going to need to write the credit card daemon in any case. Does xTuple have anything on the timeline for such a thing? Or, if I did this myself, how should I design it in such a manner that it would ‘fit in’ with any ideas or plans xTuple (the company) has for this application?

Do the currently existing credit card components use anything outside of QtCore? I need to ensure that I can share the code between my daemon and the GUI app, but you can’t run Qt apps as daemons (i.e. without X11) if you use anything outside of QtCore.

Cheers,
-Josh

[jrogelstad]

Josh,

Could you please clarify why a daemon is necessary? We are typically reluctant to add components to xTuple that add complexity by requiring additional services and libraries outside the client and Qt toolset because over the course of time a high number of moving parts makes the application difficult to maintain and administrate. Not to mention that we put great effort in to the credit card module the last time we did major work on it to make sure it could accept additional processors using sub classes as Gil described. Assuming you’d like your code to get back to the core, we would much prefer if you could follow the existing paradigm so all credit card processors work the same way.

We do use the cURL library, as described in the development environment set up, to process credit cards. Though I believe that is used only for the YourPay processor at this time. Ironically, that library is exactly the sort of thing we don’t like to include in builds, but it was a necessary evil at the time. We hope that some day we will be able to rely exclusively on Qt tools.

John

[system]

I agree 100% John on the ‘keep things as simple as possible’ requirement. Here’s the devil in the details: I’d like to service CC auth requests from my website from within the xTuple application. This presents two problems as a) xtuple GUI app does not have the capability to service inbound requests, and b) even if it did, requiring xtuple to run full time means running X11 on a server (or VNC) with a user logged in.

My plan is to write the credit card processor in the normal way, as Gil described, to put into xtuple core. This new CC processor will be compiled into and work with xTuple GUI app exactly as the others do today.

After it is working in the GUI app, I’ll create a standalone version of the CC processing infrastructure that can listen for requests. Granted, I could just duplicate the database calls and CC auth interface using different code, but for maintainability sake I’d like to have the same code running in the GUI app and daemon. In a perfect world this would mean a shared library, but compiling just a bit of the application into a shared library means increased maintenance headaches… so using the same source is a better idea.

[BC_Wilson]

Josh,

Kudos for undertaking a challenging addition to the software!

Since we’re in the middle of an effort to set up our own online store and take payments that will ultimately be stored in our internal implementation of xTuple ERP, we have thought a bit about the credit card processing requirements as well. After considering our options we decided to rely on the credit card processing capabilities of an existing online shopping cart, rather than construct a new realtime payment API.

We recently relaunched this site in Drupal, as you know, and our store will run on the Ubercart module. We’ll let Ubercart do the credit card processing and export the completed orders to an xml file that can be imported into xTuple. There is an Ubercart add-on module called uc_edi that allows you to generate xml exports in custom formats, and xTuple has a mechanism for importing xml data to generate customer and sales order records. We’ve tried this in a sandbox and it works very well (I’ll be documenting this process later for anyone interested in how to integrate Ubercart and xTuple in this manner).

The only reason to set up a real-time payment API that I can see would be if you don’t intend to use existing software that can already do the job. We were able to meet our requirements quickly by combining available open-source tools and using an xml data exchange, rather than coding a payment gateway.

Either way, if you continue with the process I’d be very interested to see what you come up with. The xml import solution was fast and available, but a real-time payment gateway might be more elegant. I’m sure there would be interest from other users in such an extension as well.

Cheers.
BC

[system]

On a side note, I noticed in Qt 4.5 that the Qhttp object supports ‘post’. Is there a compelling advantage to using Curl for this purpose, over the built-in Qhttp post? (Is ‘post’ available in Qt 3?)

[jrogelstad]

We’d love to dump cURL if Qt has the tools to do it now. We haven’t investigated the latest versions of Qhttp enough to know whether that is doable at this time. If you’re digging around with Qhttp please keep abreast of what you find. We’re experimenting with upgrading to Qt 4.5 right now.

[gmoskowitz]

QHttp supports POST but nobody involved in xTuple ERP has solved the problem of YourPay’s required certificate-handling: The current implementation is dependent on curl’s -E option. There was no point in having two versions of the HTTP sending routine when it wouldn’t eliminate the dependency on cURL.

Gil

[petebisson]

You can’t easily get similar behaviour to curl -E (enforce use of local certificate) with QHttp.

The Qt default SSL configuration assumes no local certificate, and there does not seem to be an easy way to change this for QHttp.

The new class QNetworkAccessManager (introduced in 4.4) is the current recommendation for new development work.

http://doc.trolltech.com/4.4/qnetworkaccessmanager.html

To enforce use of a local .pem certificate, you need to build a QSslConfiguration using the required certificate, and you can construct a QNetworkRequest using this SSL configuration.

I haven’t looked at the individual CC processors in any detail, but I assume from the earlier posts that the other payment processors don’t require a pre-issued client certificate.

If that is the case, the other processing services should be happy with the default SSL configuration.

Or you can do it the hard way, simply using a raw QSslSocket constructed with the same SSL configuration

Another thing I keep idly wondering about is the best way to deal with third-party processors like Paypal or Google Checkout.

In the usual use of these, for example on a website shopping cart, you never get the CC details at all - just an authorization number and transaction reference.

As website orders are pre-paid before the order gets received, a quick and easy way to enter the payment details while processing the S/O would be useful.

I’m trying to think of a sensible way to incorporate this into a work flow, and I mention this here as they “feel” like they should go with CC processing from a user perspective.

Bright ideas welcome

Pete

[gmoskowitz]

Pete,

Thank you.
The QSslConfiguration::setLocalCertificate (const QSslCertificate &certificate) is the piece I hadn’t been able to find last time I looked at cURL replacement.

xTuple ERP currently supports three credit card processors:
[list]
[] Authorize.Net - HTTPS with no client certificate
[] YourPay - HTTPS with a client certificate
[*] External - manually record details for CC processing done with some external software or device
[/list]

We wrote the External processor for testing the bits that are common to Authorize.Net and YourPay, then realized that it’s well suited for recording the cases you cite - web carts and Paypal and card swipers and … It expects to find a credit card number defined for the Customer but you can fake this with one of the test numbers defined by the CC processing companies.

Gil

[gmoskowitz]

Josh,

To answer your questions, since the conversation has drifted:

No, we don’t have a timeline for a credit card processing daemon. Someone else raised the possibility a year or so ago (user zzzzz?) but the rationale wasn’t compelling at the time. As for ideas tossed around internally, we’ve talked about moving the encryption from the db server into the client to avoid the problems of people not using VPNs and SSL connections like they should, the problems coordinating a CC daemon with the GUI client, and adding yet-another-moving-part that needs to be administered by users and maintained by developers.

Yes, the current implementation uses components outside QtCore. External cc processing is a GUI (see my reply to Pete on getting rid of the cURL dependency for more info) and creditcardprocessor.cpp refers to it in the getCreditCardProcessor() factory. I think the basic creditcardprocessor.{cpp,h} and its subclasses for Authorize.Net and YourPay are all core + QSql, so your idea should work if we can rewrite the factory without (hardcoding names && #include externalcardprocessor.h).

Gil

[petebisson]

No, thank YOU.

I had never even considered using the CC test numbers - which is stupid, as I have used them before on other projects. In fact a whole string of 4’s sprang to mind the second I read your post!

In my defence, it was a few years ago - I’ve slept since then…

I’ll play with this some more, as that trick gives me an instant workaround for the CC number screen.

I might still want to extend the functionality further, but that will require dusting off the Paypal developer account and catching up with the latest revision of the API.

(Her: “Wouldn’t it be better if I could click the transaction number and see all the details from Paypal?”. Me: “Yes dear.”

Seriously, there could be significantly improved support for Paypal, but I need to consider exactly what that would require on the xTuple side, and where it all needs tying together.

I’ll let you know when you’ve finished the EDI stuff

Speaking of which, does the batch manager need to be a GUI app? My development servers don’t run an X environment, and I hear there is this idea about creating an external daemon for Credit Card processing …

Cheers

Pete

[jrogelstad]

Unfortunately the Batch Manager does need to be a GUI app. We’ve discussed turning it into a service several times, but the hang up is that Qt requires xwindows to generate the pdf reports that Batch Manager creates, which is its main job. We’d have to completely re-implement the rendering and printing of reports with some other tool that doesn’t require a GUI environment to make it work, which would be a significant effort that would also impact OpenRPT and xTuple ERP significantly. While we’d like to see Batch Manager converted to a service, of the many projects that come across our radar we think this one hasn’t warranted enough benefit to justify that level of effort. As it is, all the folks we have running that tool seem happy with the GUI app.

[petebisson]

Thanks John,

That makes perfect sense, and it’s about what I expected the answer to be.

It’s not an issue for me really, as the batch manager doesn’t seem to
care where it runs from.

I just run it on a client machine and connect it to the server and it
seems quite happy with that.

Handy things local area networks

@Josh: Sorry for drifting so far off-topic, but one thought led to another …

Cheers

Pete

[system]

Gil,

Keep in mind that I am not suggesting to run all transactions through the CC daemon. Let me see if we understand each other.

What you are talking about above, would consist of this workflow:

xTuple GUI -> connect to CC daemon -> connect to PostgreSQL and Authorize.NET (or whatever)

What I am talking about is the CC daemon as an add-on. The xTuple GUI would continue to run as it does today, connecting directly to PostgreSQL and the CC processor. It would not connect to the CC daemon.

The CC daemon is an outside part that would act just like an xTuple GUI instance in connecting to PostgreSQL and CC processor.

This would provide less moving parts for those cases where the user does not require full-time auth…

–josh

[unexpectedly]

@joshuak: It is common in the industry not to settle batches – then any auth’d charges automatically settle at midnight. Obviously, this is dependent on the processor.

@BC Wilson: Ahhhh, nice. I’m not particularly fond of learning another CMS, but I like this idea. I’m wanting my company to leave QB+Windows and go all linux…

[gmoskowitz]

Josh,

Yes, the CreditCardProcessor class will still work without the QMessageBox and OrReport calls, but removing them would remove functionality others have explicitly requested and possibly paid for. If you want to use this class in a daemon, the best path is probably to #ifdef the appropriate code blocks with something specific to the GUI module and compile the file a second time for linking with the daemon. You’ll also have to #ifdef out the references to ExternalProcessor.

Review yourpayprocessor.cpp and authorizedotnet.cpp too, but they seem QtCore after a quick glance.

Gil

[system]

Gil,

qq. In looking over the creditcardprocessor.cpp, the only references to non-QtCore things I see are a reference to QMessageBox, and report functions (which I suspect require Qt GUI routines). Will the creditcardprocessor.cpp work if these are removed?

Cheers,
-Josh

[system]

Dumb question - where is the code to settle batches?