[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