You are viewing the PKP Support Forum | PKP Home Wiki

Ruling Out Non-Paypal Payment Links

General inquiries about the PKP.

Moderators: jmacgreg, btbell, michael, bdgregg, vgabler, barbarah, John

Forum rules
The Public Knowledge Project Support Forum is moving to http://forum.pkp.sfu.ca

This forum will be maintained permanently as an archived historical resource, but all new questions should be added to the new forum. Questions will no longer be monitored on this old forum after March 30, 2015.

Ruling Out Non-Paypal Payment Links

Postby reflections » Tue May 28, 2013 6:30 pm

Colleagues, should I be afraid, very afraid, to try to program a non-Paypal system into OJS and OCS so that we can use the preferred shopping cart vendor our university now uses and the one they plan to use in the future? I don't need advice on using OJS PayPal, I need to know if I'm on target in worrying about the options!

Reflections: Narratives of Professional Helping, about to publish its first online issue after 17 volumes as a beloved peer reviewed journal, is published by Cleveland State University School of Social Work with the copyrights for past and future issues held by Cleveland State University. It is mission critical to get our paid subscription system up and running prior to the publication of our first issue in late June, which is when we will notify hundreds of accredited programs, advertise through National Association of Social Workers to 200,000 members, etc..

As you know, OJS allows either (1) true open access journals (no registration required), or (2) free registration (no payment), or (3) paid subscriptions, and all permit instant access. At first we were going to try (2). Although I duly respect true open access, our original authors intened to publish their most intimate thoughts about practice in a small circulation print journal; we wish an intentional readership, and we don’t want authors worrying their content will be searchable on Google. On our site, only author name, titles, and abstracts will be searchable.

At this time, we have 60 reviewers and dozens of authors and special issue co-editors who are trained in OJS. Hundreds of hours of work have gone into perfecting our installation. Frankly, I can’t even conceive of moving out of this environment.

Recently, we determined, and many stakeholders consulted agree, that we need to have paid individual subscriptions if we want to have a firm long-term financial plan. These will be $18 a year, less than half the earlier print cost. We need to implement this in the next few weeks. We have an on campus account of the kind that has been successfully linked to by PayPal at another college. I'm told that that will be relatively easy to implement:

In order to implement subscriptions, we have as I see it four choices. Am I exaggerating the cons in implemented 2-4? Am I biased in favor of the OJS built-in system?

1. OJS software’s built in Paypal capacity, which would involve individual subscribers easily paying and being immediately subscribed to the content. This we could to ourselves or by piggybacking on the PayPal account set up in the College of Business. Pro 1: Easy to implement using the above information. Pro 2: Paypal is now under its current ownership one of the world’s most widely used and most secure payment systems, and allows use of all major credit cards. Cons: It would be another instance of a payment mechanism the University would like to move away from eventually, in favor of a planned system being implemented for continuing education and other functions where the university is selling to the public.
2. Our existing standalone shopping cart payment system, not integrated into OJS except as a link: Set up a link from our journal website that would permit payments through the existing ShopNet system, which now accepts Visa. Pro: Could be set up fairly easily by IST for a small fee, and the funds would flow to to our subscription account. Cons: This would require manual intervention to invoke subscriptions. We’d have to daily ascertain who had entered a new subscription and manually register them. We would have no way to annually renew them easily from within the system. This is not feasible.
3. Our existing university shopping cart payment system, integrated into OJS: Set up a link from our journal website that would permit payments through the existing ShopNet system, which now accepts Visa, and alter the OJS installation to essentially append the PayPal system with a link to the external provider that we use with ShopNet. Pro1: Eliminates the manual intervention con of (2) above. Pro2: It is hypothetically possible and would comply with the apparent high level administrative preference not to use PayPal. Con 1: Unlike Paypal, this doesn't doesn’t permit use of American Express. Con2: Very expensive to program, dozens and dozens of hours of coding, troubleshooting, etc.. Con3: We couldn’t possible get this set up prior to publishing our first few issues, meaning we’d have to start free and then add on subscriptions, which isn’t a great way to begin publishing. Con4: Like there would be bugs galore. Con5: Programming of this kind is very individually idiosyncratic, and is hard to replicate if that programmer is no longer available. Con6: It means giving someone other than the vendor and I system level access to our vendor’s server and its installation; our vendor would likely not agree to that and we might have to switch vendors and pay IST to install the software on CSU servers where our programming consultant could operate with IST permission. This doesn’t sound feasible!
4. The planned new system integrated with PeopleSoft and with OJS. Pro: Keeps all external sales in one payment system, integrated with PeopleSoft. Cons: Time delays; uncertainty of future of PeopleSoft at CSU; lack of eligibility for the cost of this of the kind funded by the 15% “tax” on continuing education, plus all of the Cons of (3) above.

Michael A. Dover, M.S.S.W., Ph.D.
Editor, Reflections: Narratives of Professional Helping Website Here Journal Here
School of Social Work
Cleveland State University
2121 Euclid Ave.
Chester Bldg. Room 326
Cleveland OH 44115-2214
UPS/Fed Ex Shipping Address:
Substitute 2300 Chester Avenue for the Euclid Ave. address.
Office: (216)687-3564
Fax: (216)687-5590
Email: m.a.dover@csuohio.edu
Faculty profile: http://tinyurl.com/ylmhvko

“You can not be a social worker unless you believe in social change and are willing to do something about your beliefs.” – Richard Cloward

"Always think that any one of us can bring some portion of misery to an end." – Carol Mowbray
Posts: 23
Joined: Tue Jun 05, 2012 9:03 am

Re: Ruling Out Non-Paypal Payment Links

Postby asmecher » Wed May 29, 2013 8:26 am

Hi Michael,

Your situation probably isn't uncommon, unfortunately -- it sounds to me like many universities are (understandably) trying to prevent the proliferation of different finance-handling systems.

As you've pointed out, half measures are unlikely to be very satisfactory, so I'd focus on #1 and #4. The viability of #4 depends on a number of variables that I'm not specifically familiar with regarding Peoplesoft's payment handling. We've written OJS's payment processing code to be plugin-based, and PayPal support is one such plugin that gets included with the OJS codebase. There are other payment processing plugins in the plugin gallery that could provide good code examples too.

The question is to what extent Peoplesoft's payment processing tools are ready to "play nice" with outside systems. By reputation I understand that Peoplesoft is a bit of a walled city: it's not so interested in working with outside systems as it is in strengthening its own grip. If they don't have good interoperability potential and some measure of developer documentation, you'll have trouble doing much of anything with it. If they do, then a several-week blitz on payment plugin development could deliver, if you've got a developer on hand to do it.

Obviously #1 is the easiest solution, if it's politically possible. Keep in mind that you could launch with PayPal payment processing and later switch to another plugin; OJS uses these plugins for payment fulfillment only, so only payments that were specifically in progress when you changed plugins would be affected.

Alec Smecher
Public Knowledge Project Team
Posts: 10015
Joined: Wed Aug 10, 2005 12:56 pm

Re: Ruling Out Non-Paypal Payment Links

Postby reflections » Fri May 31, 2013 5:19 pm

I have been "managing from below" and think I now have the path clear, conceptually. I'm fact checking as I make recommendations to the key parties above me. I now have a plan for a plan, at least, for resolution of the question of how to be able to sell Reflections subscriptions. Does the below make sense? You see, it eliminates the possibility that an editor or department could abscond with funds and it makes centralized accounting possible. At the departmental level, one additional security measure is that the "publisher" say the Chair as well as the editor would have the OJS password, so at any time she/he could double check that the Paypal link within OJS hasn't been redirected to the editor's personal account or something.

Of course, the final answer could be no, but there appears to be a commitment on all parts to make this work. The fallback plan would have to be setting up an external nonprofit authorized by CSU to collect subscriptions on behalf of Reflections and deliver all proceeds to the university. Instead, according to the current vision, Reflections will be the guinea pig in an effort by the University to ascertain the proper mechanisms that would need to be in place for units to use PayPal to do such things as sell online journal subscriptions, collect dues for professional associations they host, collect registrations for conferences such as the CCCOSW that we host, etc.. The lessons learned about use of PayPal within the OJS environment will be transferable to use of PayPal generally, including by other colleges or units on campus.

This work will take place steadily over the next few months. It will involve General Counsel amendments to the Paypal contract to make it compatible with Ohio law; Auditor approval of the methods of confirming the accounting; Controller agreement to the plans developed for how to reconcile spreadsheets of subscribers generated from within the OJS software with the spreadhsheets Paypal produces each time the Controller downloads the latest income, etc..

Basically the way it would work is this, as I imagine it, based upon what I understand at this point.

1. Reflections sets up a Subscription Type within the OJS software, choosing Online as the payment method.
2. CSU Controller’s office sets up a PayPal account for reflections@csuohio.edu or another designated email account to identify the income coming in from the Reflections stream.
a. The password for that account would likely not be known by Reflections.
b. As part of that set-up process, the CSU bank account number is provided.
c. A test deposit is made to authenticate the CSU account to PayPal.
d. I will recommend that Reflections deposit a sum sufficient to ensure that PayPal can subsequently upon request permit the transfer to CSU of all new subscription income, with any processing fee’s deducted per transaction. The initial deposit would cover the monthly flat fees and the escrow amount that PayPal requires remain in their account to cover any refunds and disputes. This way each spreadsheet’s total, divided by the number of subscribers, should equal the total number of subscribers times the subscription fee, once the per transaction fee is accounted for.
3. A system is set in place to reconcile accounts.
a. Reflections documents its ability to produce from within the OJS system spreadsheets showing who has subscribed, dates, and amounts paid during any specified period.
b. Periodically the Controller transfers funds from the PayPal account to CSU account, and a journal entry is done by the Controller.
c. For each download of funds covering a specified period (say once a month) a spreadsheet is downloaded from PayPal with the names and emails of the subscribers, amount paid, date paid, etc.
i. In some cases the emails used to pay PayPal may differ from the email used to register for Refections, but it should be possible to reconcile these (see below). The system would require the names to be the same, I believe (fact check).
d. Funds are transferred from Controller to the subscription account set up by Beth Carlton:Acct: 8405 Fund: 0891 Dept: None Program: None Class: 91644.
e. The Controller sends a copy of the PayPal spreadsheet to Reflections.
f. The person responsible for PeopleSoft operations of that account (yours truly, once I’m trained) is informed that the funds are transferred and receives a copy of the spreadsheet that the Controller got from PayPal.
i. It is unclear who will be responsible for downloading that spreadsheet, but it appears the Controller would do that. In my opinion the Controller and only the Controller would have the PayPal password, which is different than the OJS system password. In other words, only the Controller’s office or its designate could transfer funds out of or into the CSU bank account to PayPal.
ii. There is no need for anyone outside the College to have the OJS system password; we will need to have our own internal system of ensuring integrity.
g. The Reflections Editor in collaboration with whatever staff we have in place produces a spreadsheet of new subscribers for the same period as the period for which funds were downloaded.
h. A copy of that spreadsheet of new subscriptions from within OJS is made available to the Controller and would be subject to audit by the Auditor.
i. Along with that copy there is a report comparing the PayPal spreadsheet to the OJS spreadsheet and noting any discrepancies.
i. It is unknown at this time what happens when there is a refund requested or a dispute resulting in PayPal refunding money to a subscriber. I don’t know (yet) whether this results in their subscription automatically being un-entered in the OJS system, but that is a minor matter. Such occasional matters could be handled manually and noted in the report.
j. The Controller and/or Auditor’s office could periodically review and authenticate the reconciliation reports.
4. Reflections would produce quarterly reports of income and expenses for review by the Director and the Dean’s Office, and also available upon request by the Controller or Auditor.

The above procedures will certainly be clarified over time, as the planned meetings take place. I think we’ll be able to make this work, and we must make it work, since publishing online journals using the OJS system and running conferences using the sister OCS system are increasingly the state of the art in universities worldwide.

Posts: 23
Joined: Tue Jun 05, 2012 9:03 am

Re: Ruling Out Non-Paypal Payment Links

Postby reflections » Sat Jun 08, 2013 8:16 am

Our Auditor really opposed using PayPal. Desperately need advice on how to use another plug-in; we have "ShopNet":

Since you said: "Re: another plugin; OJS uses these plugins for payment fulfillment only, so only payments that were specifically in progress when you changed plugins would be affected."

Am I perhaps exaggerating? is there a way we could use this ShopNet capability in a way that plugs into OJS and registers the subscription within the OJS system?

Desperating seeking solutions.
Posts: 23
Joined: Tue Jun 05, 2012 9:03 am

Re: Ruling Out Non-Paypal Payment Links

Postby asmecher » Mon Jun 10, 2013 9:28 am

Hi Michael,

You would need to write a plugin for OJS that acts as an adaptor between OJS's code and the Shopnet services.

Alec Smecher
Public Knowledge Project Team
Posts: 10015
Joined: Wed Aug 10, 2005 12:56 pm

Re: Ruling Out Non-Paypal Payment Links

Postby reflections » Mon Jun 10, 2013 11:29 am

That is what I understood, and as previously discussed that would involve quite a bit of work, and we don't have anyone who knows how to do it.
Posts: 23
Joined: Tue Jun 05, 2012 9:03 am

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 1 guest