If so, how do you direct people to pay.
alternatively (and even better)
what would be the best way to get Moodle to have a payment option included where, for example, if an enrolment key is needed, the student is given an option to purchase a "seat" and then prompted to go to a shopping cart (i already have one) to make payment
Martin once mentioned something that i'm unfortunately not familiar with, but i learn quick
I know a few sites are already doing things like this.
i guess it could be as simple as adding in a link in the response given when a student clicks a course in which a key is needed. perhaps a link to a new window with a catalog listing of the courses available.
the cart i use would then return the person to the Moodle page of my choice.
it could be more elaborate, but i don't have enough working knowledge to offer good ideas about that.
hmm...is it possible to "hide" course pages? lots of carts provide links to hidden/protected areas of sites upon payment. that way, there's no problem with the enrolment key being passed around.
is somehow not accessible to anyone other than those people that are given access to the link. they would need both enrolment key and to know what course id. maybe the course page canhave .htaccess or something?
Currently the authentication methods aren't linked to course enrolments (only site accounts), but one way I could see this working is to have the concept of site "credits".
If credits were enabled (by the admin) then there could be an authentication method which somehow allowed students to add credits to their account, and enrolling in any course would remove credits from the student's account.
i posted a more complete explanation with some thoughts on why i think its important to have something like this just for the sake of easing confusion.
i'd like to be able to send people to "mymoodlesite.com" directly so they can view course offering in their entirety and have the option right there to choose to pay for access when appropriate, *without* them needing to know that is what is meant be the presence of the enrolment key icon.
that makes moodle a more complete conline ourse catalog & teaching facility i think
In your description for the classes requiring keys, drop the Paypal code in (shopping cart system works best, because it opens a java payment window.) you can redirect the user after payment to a page that gives the key, or when your payment center is notified, you can then email the student with the key. It's simple, and it works.
Do I leave the course key clear or do I put a code in. I imagine it will be clear.
Then, if I am correct the key could be placed in an e-mail to the client using an autoresponder.
In PayPal third party solutions there is a service which you can register for which takes care of all after sales e-mails ...I think its is called Track-it or Track-Pay.
Actually this would also work for repetitive sales using paypal.
This would be okay for personal sites but not for fussy large corporations wanting to link payments directly into merchant accounts etc.
If we can work out some kind of modular, extensible way of implementing a "gate" that replaces the enrolment key page and interacts with a variety of external pay services then I'll be interested in writing the code for it. Ideally the teacher/admin might have an interface something like the current authentication interface where they choose and configure from a list of supported external pay sites.
There's a number of details I'm still unclear on, as I'm not familiar with the features of external pay systems available.
Assuming we stick to a key-based system, it would be best if the key was unique to each user. So, when they try to enrol, a key could be generated, saved locally, sent invisibly to the external system and then, once they have paid, they get sent to a URL which enters the key into Moodle, and unlocks the gate.
Another method could be that the teacher is notified of the payment and gets a URL which adds the student to the course.
Just some ideas ...
This is a free and excellent online shopping cart system.
It supports products for download - using the free system you can upload a database file containing up to 100 unique download addresses - each of which could contain an enrolment key for a different course. Upgrade to the paid version and this becomes 350.
You don't need an online payment gateway as Mals stores credit card details in a secure area online - however, Mals does support a host of online payment processors if you require this functionality. Mals also supports PayPal.
I haven't yet played with the enrolment key sufficiently - but my understanding is that it is a per course system?
I would like a system where someone could be given a 'site-wide' account so that I could sell access to all courses with one payment - is this possible? Is this possible with the enrolment key system at present?
THOMAS: splendid idea...who needs "pretty"? that'll get me started, at least.
JAI: actually most merchant accounts have some kind of URL-based linking method, so the introduction of that code on a course page could work as well.
RICHARD: mals-e.com sounds very cool, especially for the price. looking forward to having a look.
MARIE: OScommerce, though i love it, may be overkill for many. i started to use it and had to put it aside because i just needed 10-15 items.
MARTIN: the thing is that there are so many different protocols that a payment system is its whole own beast. seem to make sense to incorporate something that already exists, no? there's a fellow working on a module called PostKart, a kart plug-in for PostNuke CMS, but he expects to make it stand along as well. it's straight to the point and clean.
the code-insert idea works for my Authorize.net merchant account, my PayPay and i imagine any other URL-based method like ClickBank, WorldPay, EFF, Verotel (pay by phone!) etc.
my cart (well, more like an E-Commerce Automation system) has digital delivery (it hides uploaded items behind expiring URL) followup autoresponders, and a million other things but what i like best is that i can just paste code and do a similar thing as the PayPal popup java.
my concern about writing up code specifically for this is that there are so many systems and the hidden pass through of the key information may not be so easily accomplished with all and certainly not uniformly. so i looked at the commonality of most payment acceptance methods and came up with these notable samenesses:
- they all send email upon purchase, hence an opportunity to send key info (as well as course introduction, instruction, etc).
- i belive almost all (including PP) are able to direct purchasers to a URL of own's choice...an opportunity to pick up a key that has been passed to a *page* for retrieval instead of to the actual system
in terms of expansibility, i like the option being able to send people to payment acceptance on a course-by-course basis. that way, if i am allowing others to offer courses on my moodle site (i'm doing a kind of personal development university with guest teachers and all) they can use their *own* payment link if necessary.
most code also seems to prohibit letting you have two different payment acceptors (like both merchant and PayPal) which is sometimes needed because merchant accounts, while costing less, place restrictions on Internet purchasing. you can lose your account or get denied having one based on whatever the criteria is.
one example of how that may affect this use is, for instance, my merchant account won't let me sell "memberships" or even services too far in advance. the logic is that if the company fails to produce, they have to pay. so my webhosting company is selling a whole-year hosting plan. i have to use PayPal because my merchant account won't allow that.
i'd say initially simpler and as flexible as possible is best.
i do like the random key idea. lowers rate of hacking as moodle becomes the most widely known learning platform ever
Here's a provider I came across recently http://www.glpayment.co.uk/
I haven't looked into it at all - but it'd be an interesting way of selling access to online content.
Sending the Enrolment Key via Email after user had make payment via Click bank.
In another word, I shall have a link in my enrol.php which will direct user to purchase for Enrolment Key via CLick Bank.
(Please don't post with the teacher/teacher account).
I am currently using a separate payment script DreamAccount to test this out. I basically use DreamAccount to process the user and let them purchase different courses. Once they have paid, I link them to a secure page with the course authorization key that they paid for and a link to moodle. I then let Moodle use an external database for users and point it to the mysql database of DreamAccount. This way DreamAccount handles the user authorization and payment processing (Authorize, PayPal, Verisign and others are available within DreamAccount)
NOW I an not currently using this in a production site, I had to pay for DreamAccount ($150) and I am not sure if it will all work the way I want....I am still in preliminary testing
Does anyone know of another good third party account management script that uses mysql that I might be able to use??