Check out the LimeSurvey source code on GitHub!

Creating a "payment" question type

5 years 6 months ago - 5 years 6 months ago #64120 by starmonkey
Hi Guys,

Today I am looking into adding support for taking credit card (and offline) payments during the process of filling out a survey in LS. I have decided on adding a new question type to handle this via a jQuery dialog/popup (similar to the file upload question type, which I have some experience with). This will house an iframe which will load the payment gateway php page.

Basically I just wanted to bounce the idea off you guys, and see if there is anything important I'm missing.

Some project background:

We have a (tweaked) version of 1.91 RC2 in production. We've effectively setup LS as an "application form" style system, so the use-case is that applicants will have to pay some cash to finish their application and be eligible for consideration.

There is also a requirement for the applicant to choose "offline" and settle it independently of the system, i.e, mailing a cheque, possibly for multiple appforms together - some applicants may be part of the same organisation which will handle payment for them (so I want that org to mail off one cheque, then admin staff will process/bank the cheques, and flag them as approved).

I haven't quite decided on the business-process for this yet - i.e, will the applicant be allowed to "complete" their application with an offline payment still "pending approval", or can we leave the payment "question" to the last page and make having an "approved" transaction a requirement to final submission. That sounds reasonable to me. Not sure yet how that works from a a technical perspective, but the admins will update some kind of flag that the front-end will make use of.

The payment gateway we're looking at using (SecurePay) has an XML/POST API, which is easy to implement in PHP through the use of PHP5's SimpleXML library (I've done this recently for another client, it's fairly easy).

I was thinking later we could add some global-config page(s) for entering unique payment gateway details (username + password basically), but that can wait - for now I can just use a config file for this client.

The whole system will be switched over to using HTTPS, so taking credit card details should be secure.

So, what are my questions? I guess, does this sound reasonable? I know that adding question types in 1.x is clunky, so I'll have to allocate a reasonable block of time for all the fiddling involved.

Other issues to consider will be the administration of payments - storing transaction data and then displaying that for admins to review etc. But I can defer those UI's in priority: as long as we're taking payments and keeping track of all the data, we can build other interfaces later.

Anyway, any advice, pointers etc would be most appreciated!
Last Edit: 5 years 6 months ago by starmonkey.

Please Log in to join the conversation.

5 years 6 months ago #64121 by jcleeland
SO is the plan that you will ask a question, then palm the user off to the SecurePay system to handle, and then wait for them to be returned to your survey from the SecurePay website with a positive/negative result? Will you be recording creditcard details using LimeSurvey, or just the securepay authorisation information?

I've been working on a "guide" to adding question types, so feel free to use that as a starting point.

Note that this is most definitely not a completed page :-)


Please Log in to join the conversation.

5 years 6 months ago - 5 years 6 months ago #64124 by starmonkey
Hi Jason,

Thanks for replying.

The plan is to handle taking the details ourselves, then send that as xml data over HTTPS (using cURL) to SecurePay, which will return XML as a result. I'll then parse that (using SimpleXML) and update the LS question so that it has been "answered" (depending on the result of course).

So the user won't be redirected or anything.

Thanks for your link - I'll have a look over it later today.

Last Edit: 5 years 6 months ago by starmonkey.

Please Log in to join the conversation.

Imprint                   Privacy policy         General Terms & Conditions         Revocation information and revocation form