[pmwiki-users] [pmwiki-devel] ZAP shopping cart question
The Editor
editor at fast.st
Wed Nov 8 13:47:57 CST 2006
On 11/8/06, Crisses <crisses at kinhost.org> wrote:
> On Nov 8, 2006, at 1:14 PM, The Editor wrote:
> It needs to generate separate carts for each merchant, since the
> payments would be separate. Amazon.com is somewhat similar -- when
> you buy used books, they generate your order as one, but your card/
> payment is charged separately for each of the merchants. That's
> where some of the inspiration comes from.
Yes this should work just fine. I'll do it for the next release.
> It is certainly complex. I'll agree with that. But there's more
> complexity for the programmer -- on the user end it only gets complex
> when setting up a complicated store.
>
> Here I'm selling one product, with 2 size options:
>
> (:cart XES1 seller=XES pmt=PayPal;info at example.com tax:)
> (:item XyZ name="Product Name" desc="Product description"
> pic=http://example.com/products/pic.gif:)
> (:pic http://example.com/products/pic2.gif:)
> (:options QHI name="Size" select=1:)
> (:option 8oz name="Small" default amt=123.45:)(:optionend:)
> (:option 20oz name="Large" amt=10.50:)(:optionend:)
> (:optionsend:)
> (:itemend:)
> (:cartend:)
Mine might be as simple as changing (:zapcart itemcode:) to (:zapcart
itemcode|size:)
> > 3) The javascript function can be modified by any programmer fairly
> > easy to calculate shipping and taxes any way desired. You could also
> > specify the javascript file in a SDV (or perhaps in the markup), so
> > different checkouts could use different approaches. Defined in a
> > local config file.
>
> I personally find this absolutely unacceptable, especially where
> membership or downloads may be concerned. If someone is not hand-
> calculating the order, people can mess with the functionality of the
> JavaScript, and perhaps send through orders with lower prices --
> maybe even $0.00 or $0.01. It's one of the big failings of browser-
> scripting.
Are you talking about a security vulnerability or a poor programmer
setting it up wrong? I mean, javascript is not that complicated
though it is a bit weak on math. The way my script works, users
cannot edit the line totals, only the quantity. And it recalculates
onblur so you always have the exact total. I could have php calculate
the total, and may do that first anyway for non Javascript browsers,
but it would be quite limiting
Forget headers should not be a big problem if that's what your
thinking because this uses ZAP's session variables helps to ensure
authenticity. Let me know if I'm missing something. I certainly
don't want something that is risky to use.
Actually, on second thoughts, if the total is changeable you have a
potential that that value could be forged. Which suggests it might be
best to have a preview page, and an actual finalization page. The
first could be edited by javascript. The second would be set in
stone. Would that solve the concern you are addressing? A bit of
trouble perhaps, but probably worth it.
> I'm very hesitant about the JavaScript portions. For updating totals
> on a page, sure, but for anything critical before payment I would not
> be happy. I would think any order needs to be checked before it's
> sent to the payment processor.
See my notes above on the possibility of a preview markup, and a
checkout markup. The disadvantage is, an admin that wanted to modify
the price calculation system would have to do it twice--one in
javascript and one in php, for the two different phases. Not ideal.
But agree that for downloads and access fees, it might be necessary.
> > 6) As for options for items, I don't know any *easy* way to do that.
> > But without too much trouble, each variations of an item could be
> > stored as a separate item, and a special code could be put in the
> > zapcart markup that would create a pulldown menu with options. A bit
> > of coding but not much.
>
> I'd like to see that. Not every store needs to be as complicated as
> my proposal.
I think I can do this much. Will try for the next release...
> Also, if we work with similar mark-ups, if someone wanted to upgrade,
> it wouldn't be as hard.
I think we are probably talking about pretty different approaches.
The ZAPcart's markups are next to nothing. And the item list storage
is just a single page of lines like (:item: name|cost:). So, not too
much I even have available to change.
> > 8) I suppose a way could be set up for ZAP to handle inventory control
> > (in stock or out of stock) but I have no idea how, and would probably
> > rather not tackle that within the ZAPcart module. It seems it would
> > be for a more industrial strength application with direct tie in's to
> > a company's database. Something way out of ZAP's limited scope.
>
> That's out of scope for what I was thinking also -- at least for
> now. Once you get into that, you might as well drag a database into
> it. Once I try to cram my concept into a database, it becomes much
> more complicated. That's one of the nice things about the wiki
> version -- nearly arbitrary data nesting.
Well, I'll stop the wheels from turning on this one then. Though I
might want to find a way for an admin to flag an item as out of stock.
It might be changing that item to (:item: ITEM--OUT OF STOCK|0:)
> PayPal has a subscription service. I don't fully understand how it
> works yet, but they will create recurring payments and send
> subscription info to your website (through a specific URL on your
> site). I would want to tie in subscriptions to the authentication
> module I've (re)created. Mine uses databases, but it should be able
> to be done without a database. So I would do this by, for example,
> having a wiki url divert to a specific recipe function -- that
> function accepts the PayPal information and changes the user's
> privileges accordingly.
>
> So it's similar to the PayPal Payments Pro, I think -- where you send
> an order to PayPal, and PayPal returns verification to your site that
> the customer has indeed paid. I've looked at the documentation, and
> they have some code samples, but I have to go over it again more
> thoroughly at some point.
>
> I'm not interested in pay-only sites, but I had a customer who is.
> What I need is like you said: elevated privileges for a price. So
> someone pays and is added to a privileged group with additional
> access to other features. When their subscription runs out, PayPal
> renews them or their access to the privileged group is removed.
I didn't know about this. I should look into it some more and see if
there's a way to get that url to update zap stuff. It seems using
ZAPget I could get the info from the url, I could construct a zap form
based on that info, with appropriate conditionals, etc. And I've
learned how to trigger a form submission onload by embedding it in a
gif. (How the zapcart works). This could make paypal's notifications
trigger automatic zap forms to enable whatever you wanted.
Keep me posted if you find more info. I would be interested in trying
to set up a snippet for this in zap if you can find out the exact
spec's on what they send you.
> I'd love to accept other methods of payment, but services such as
> PayPal are very cost effective compared to some credit card
> merchants. So, one thing to be careful about in developing these
> modules is to indeed make them modular -- separate the payment method/
> processor from the code, so that people can create other plug-ins for
> other merchant services.
>
> I would be doing this as an add-on for the new AuthUserDBase that has
> stand-alone features. It probably comes right after I add the
> ability for the module to control groups -- I was able to do it for
> vBulletin, so I'm sure I can do database-to-wiki group conversions.
I suppose that could be added to ZAP by making the zappay directive
configurable also in a wiki page. Ahhh, love that PmWiki flexibility
thing!
Cheers,
Caveman
More information about the pmwiki-users
mailing list