how exciting to spark such interest
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
