Credit Card Charging within OpenEMR

OpenEMR Development
1

anonymous wrote on Friday, February 04, 2011:

We have implemented the option to charge credit cards within the payment pop-up screen. If enabled it will show options once a credit card type is selected to enter in the credit card information. It will then charge the card and deduct the amounts in OpenEMR appropriately.

For anyone who wishes to use credit cards within the program must contact us for an ID and key. Then once we give them this information it’s inputed into the globals.php and then enable credit card transactions option there as well. The cost is a $99 setup fee and then $17.95 per month, plus $0.10 per transaction.

This ability will eliminate a lot of practices from having to have a separate credit card system and then deduct it manually from OpenEMR.  Also this solution is much cheaper than other credit card companies.

Commits: https://github.com/ehrlive/openemr/commits/cccharge

Regards,
Chris
www.ehrlive.com

2

anonymous wrote on Friday, February 04, 2011:

Brady,

This is our first time using GIT please ensure that we did it properly.

Thanks,
Chris
www.ehrlive.com

3

stephen-smith wrote on Saturday, February 05, 2011:

Your second commit (111a) it just a “fix” for its parent.  At this point in development, you should use git rebase to squash them together into a single commit.

I don’t think the source code is the right place to advertise your services.  I’d prefer that comment to be dropped.  Especially since the code doesn’t appear to depend on getting service though EHRLive.  It does depend on having a merchant account through Authorize.net / CyberSource.  That information should be included in a comment describing the CCCharge class in library/cccharge.php, at least.  I think “CCCharge” is a bit generic for something that only works with one IPGS, but that name can certainly stay at least until we have code to support more than one way to process cards (with may or may not be a different IPGS).

library/js/jquery.validate.js - Is this not included in library/js/jquery121.js, library/js/jquery-1.2.2.min.js, library/js/jquery-1.3.2.js, or library/js/jquery-1.4.3.min.js?  Do we really want to have to track security issue on 4-5 different versions of jQuery?  I really like jQuery, but it is simply unsustainable to have each page/patch check in yet another version.

library/js/script.js - This needs a better name.  “script.js” is redundant, yet almost entirely information-free.  “ccpanel-controller.js” is much more descriptive, but that’s just one example, and I could be reading the code incorrectly.  (I haven’t been doing JS / jQuery that long.)

interface/patient_file/front_payment.php - There are a dozen or so untranslated strings.  Virtually everything that the user sees needs to go through xl().  Anything that’s not a literal or otherwise known-safe needs to be passed through htmlspecialchars() before being used as the value of an HTML attribute or the textual content of an HTML page.

I hope we can get this cleaned up and included.

Your git tree is mostly okay.  Your “master” branch is pointing at the wrong commit - it includes one of the commits from your branch.  You should set your master branch to 1ea6, unless you intend to have it diverge from the main development history.  After that you can do the rebase I suggested above with

git rebase -i master cccharge

, which will open an editor.  You will change the “pick” action on the second commit to “f” (= “fixup”) and close the editor and that will squash the two commits together.

4

anonymous wrote on Saturday, February 05, 2011:

Stephen,

From my understanding merchants have to go through an authorized reseller. We charge the rate that authorize.net advertises. If people support our code and want a way to re-reimburse us for our efforts they should go through us…

This wasn’t a funded project, so revenue from our referrals was how were were to make our money back. So I do think a mention that they should go through us is in order especially since I see some other options in the globals.php that point to other vendors for other services.

Regards,
Chris

5

anonymous wrote on Saturday, February 05, 2011:

Actually, scratch that, you can go directly to authorize.net and sign up for an account. But our monthly charge is actually lower than what Authorize.Net charges if you go directly to them.

-Chris
www.ehrlive.com

6

stephen-smith wrote on Saturday, February 05, 2011:

I’m still against advertisements in the source code.  I think the source code is probably one of the worst places to advertise, anyway.

I think some place in the wiki would be a good place, especially since your rates are better than going to Authorize.net directly.

Perhaps add some general documentation, written in a vendor-agnostic HOWTO style, about he new feature would make a good new page to link from http://wiki.oemr.org/wiki/Main_Page#User_Manuals.  In the section about how to acquire a valid login key and transcation key for Authorize.net you could link to a commercial support page *exclusively* for OpenEMR vendors that have an existing reseller relationship with Authorize.net like http://wiki.oemr.org/wiki/OpenEMR_Commercial_Help/Credit_Card_Processing.  Of course, since you are the only vendor I know of that provides that service (and at *good* prices), EHRLive would be the only on on the CC Processing page.

I’m not averse to advertising.  Many people that want to use OpenEMR are best served by contacting one of the community members that does commercial support, so it should be easy for them to find EHRLive and others.  But, the source code is not the best place to do that.

7

stephen-smith wrote on Saturday, February 05, 2011:

I’ve done most of the editing to the wiki.
http://wiki.oemr.org/wiki/Credit_Card_Processing_Inside_OpenEMR
http://wiki.oemr.org/wiki/OpenEMR_Commercial_Help/Credit_Card_Processing
http://wiki.oemr.org/wiki/Main_Page#User_Manuals
http://wiki.oemr.org/wiki/OpenEMR_Commercial_Help#EHRLive_-_OpenEMR_Solutions_Provider
http://wiki.oemr.org/wiki/OpenEMR_Commercial_Help#Feature-Specific

I think you can safely drop the advertising from the source code; only developers would see it anyway.

Of course, if I made some mistake on the wiki (does this go under User Manuals?) please fix it up.  Thanks!

8

bradymiller wrote on Monday, February 07, 2011:

hi,

I put review comments in your github code. Note can’t do a full review until it’s testable (the modification of the sqlconf.php file doesn’t allow this). Let me know when that’s fixed and I’ll do a full code review.

thanks,
-brady

9

anonymous wrote on Monday, February 07, 2011:

I thought I did it right, sorry, trying to learn GIT myself to handle some of the commits. Anyways, in the authorizenet branch, there are 2 commits (12f95 and 23851). The 12f95 is the bad commit and has files in it that I didn’t want to track. So I ammended the commit (or so I thought) and remove the files that I did not want to track. I think that is ok to do since the only real file that you don’t want to include is the sqlconf.php. So If I don’t track it it should be ok. So the 23851 commit is perfect (so I think). Can I do with just remove the 12f95 commit?

10

bradymiller wrote on Monday, February 07, 2011:

hi,

To clean this up try the following (note I always create a new branch before doing anything than can “break” your commits, although anything that is committed can always be salvaged via reflog command):
git checkout master
cp sites/default/sqlconf.php …/
git checkout authorizenet
git checkout -b authorizenet_2
cp …/sqlconf.php sites/default/sqlconf.php
git commit -a -m “quick fix for sqlconf.php file”
git rebase -i HEAD~3
((For the bottom two entries change ‘pick’ to ‘fixup’, and then save; this will combine all three commits into one))
git push origin authorizenet_2

Don’t remove authorizenet branch either from github, since useful for reviewers to look at previously reviewed code. Also, note all of this work is done in a new branch to avoid ruining your original branch. I don’t think there is a way to not track a file (can use gitignore, but then that file won’t exist when users try to use your repo).

Let me know if any problems.

-brady