Symphony.

Hello,

I wonder if anyone has ever built an e-commerce site with Symphony?

From my experience Symphony is just perfectly suited for building complex product catalogues with different categories, prices etc.

But how about the payment process? I find it very difficult to embed even simple bits of PHP into Symphony’s XML code.

Has anyone ever tackled this?

The requirements are pretty simple: A handful of products payable via PayPal and/or credit card.

There are currently two payment related extensions out there, maybe Joseph and Max can provide more information.

I find it very difficult to embed even simple bits of PHP into Symphony’s XML code.

You’re not supposed to embed PHP into XML. Create custom events or datasources and have them create the necessary XML containing the end result you want to incorporate into your pages.

OK, thanks for your input. I just find it difficult to get my head around the concept of custom events in Symphony. I am working on it though!

Can someone actually point me to an e-commerce website that has been built in Symphony? Would be interesting to see…

Have a look at the showcase: http://symphony-cms.com/explore/showcase/?query=shop

Hey Nils :-)

Yes, I did that earlier. You can find some great works of (Symphony-) art in there. I don’t find the e-commerce examples very convincing though. I would imagine that it requires quite a bit of tweaking and twisting to get the ordering process working in Symphony. The only site that I find convincing is from your wife by the way :-)

I recently integrated Buckaroo in a Symphony site. Didn’t quite make an extension of it yet, but I might just do that in the future…

But indeed, the zen of Symphony means that you will need to create sections for your categories, products, orders, customers etc. and combine extensions out there to fit your need.

I’ve been thinking a while however to create a webshop ensemble which covers all this, but haven’t quite found the time yet to put it all to work. Perhaps a nice project for when S2.2 is out.

@kanduvisla, I have a data model for an ecomms system, it needs fleshing out a lot more, and then the workflow needs figuring out, xslt etc etc, but like yourself, I never have the time to do it. I wasn’t going to do any integrations, other than maybe some more payment types.

I was going to do a very simple front end as a white label to show the capabilities of the backend, to avoid worrying about design too much, I have the CSS framework ready too.

Maybe this would be a good collaboration project for 2.2, and made available on the downloads section as an ensemble. The documenter extension could be used to thoroughly document the workings in the backend…

It’s a big project though, I think.

@designermonkey, i would be very interested in helping out with an ecomm site/system with symphony. email me if you’re interested - wtdtan [a] gmail.

Although old, at work we have SecurePay and eWay extensions that someone might find useful.

I’ll tidy up the eWay one at some stage in the near future and put it on github.

We’re actually in the process of estimating and planning a large ecommerce site on Symphony, so should something come of it I’ll post some details of how we accomplished it.

Heh, when I looked at the Paypal Payments commit history to see how you’d done things, I saw the initial commit was Secure Pay…

When 2.2 is out, and also the Members extension (which my model relies on) then yes @wtdtan, I may just contact you! :o)

@designermonkey @wtdtan: I would also be interested in helping out with this project. It would be a great statement of the power of Symphony. Extensions we might use could be:

• shopping cart
• members
• payment processing (perhaps a new extension for this which spans multiple payment options?)

Wow, this would be a huge leap for Symphony. Being able to build e-commerce sites would take Symphony to a whole new level. I just wish I wasn’t such a n00b, so I could hack together my own extensions. But I probably need another year or so to do that.

The only e-commerce site built in Symphony that I really like is this one made by Johanna. It looks like an awful lot of work though and it would be great to have an extension for this or to automate it in some way.

PayPal and cash in advance may suffice for most purposes. Credit card payment is a whole new beast I suppose.

PayPal and cash in advance may suffice for most purposes. Credit card payment is a whole new beast I suppose.

In general, implementing credit card payment isn’t much more complicated than implementing PayPal. You’ll need a payment provider (e.g. 1&1 iPayment) anyway, and their APIs are quite similar to services like PayPal.

Besides, you can also accept credit card payment via PayPal or Moneybookers (Skrill), but to my knowledge their fees are fairly high.

My e-commerce payment systems integrated with Symphony are not plug-and-play.

I was going to update my PayPal/USPS/Shopping Cart extension that I created for Take on life, but I’m really not satisfied with my approach.

I’m working hard to improve my PHP skills now and some new extensions will come out of it.

That’s where most of the hard work would come in, providing solutions for all the different payment gateways APIs. I don’t think that one extension should be provided for all, rather one for each gateway.

I have many, many ideas for this, but absolutely no time to do any of it. The stuff I have at present, I’ll put on Github, that way anyone who wants to lead development of this can do, and I’d be happy to add them to the repo as contributors.

providing solutions for all the different payment gateways APIs. I don’t think that one extension should be provided for all, rather one for each gateway.

I disagree, I think one extension should handle payments. The different type of payment options could be plugins for this extension. I think this is a more solid way to deal with it, since then you would only have one extension that deals with the payment status (this could be a dropdown with options like 'pending', 'approved', 'cancelled', etc...), and which has configuration when you create the field type (just like when you create a textarea and you can choose a text-formatter, you should be able to choose a payment-gateway when you create a payment-field). This could be a multi-selectbox if you have multiple payment gateways that you use.

How would a payment gateway be a field type? Payment would have to take place through the events system. A button for each payment method that fires a different event on the frontend?

I do like the idea of an extendible extension...

The field payment could be a (readonly) selectbox which will be set to a specific status by an event. I implemented a payment module this way on a website of a client of mine. I created an orders-section with a field of 'select box', and a custom event which changed the value of the field according to POST-data sent from the payment gateway.

I believe something like this could be wrapped in an extension:

• Provide a field 'status', so you can see in your 'orders'-section if the order is already payed or not.
• Create a event which includes a payment-module which handles the POST-data and does some checking (this is the extendible part of the extension)
• The included file returns a status, with which the event sets the payment status.

You most possibly also want to execute some other logic, like sending an e-mail to the manager of the site, the client, the distribution center, etc... Not quite sure if the payment-gateway is the place for this. I think you should let another event perform actions according to the success- or failure-status of the payment-event.

I was considering using the Status Field extension to do the status with (I wonder who wrote that?).

We have to remember that we shouldn't do 'everything' within the payments processing. I envisage lots of separate extensions here with lots of custom events too, this isn't going to be a simple implementation with a few massive extensions IMO.

The payments should possibly be a simple affair, like the Paypal Payments extension, building an almost duplicate one per gateway, or making one master extension which contains the code to log the transactions (as Paypal Payments does) which is extended by specific gateway extensions, or actually maybe one extension with lots of little libraries in it for the gateways, that way being easily extendible by adding new libraries.

Thinking on this, the latter would be better ;o)

After a thorough read of the thread again, I think we may be in agreement about the Payments extension. One extension, many libraries for gateways. Maybe then the Status Field extension could be rolled into this as read only with set statuses.

Hey, I really like where this is all going you know, we may have a good set of e-comms extensions and workflows out of all this!