Agreed. Do one thing; do one thing well; and play well with others. I think we should keep to this mailing list for a while longer to get maximum exposure. More than likely, there will only be a few dedicated threads in the short term, which people can choose to ignore if they want. But we get the benefit of keeping such an important topic in the widest circle.
Sid Bachtiar wrote: > Hi, > > Are we going to have a separate mailing list for developing this plugin? > > I've implemented Paypal on a Symfony project. There are basically 3 > different types in Paypal that I think also should be the case with > other payment systems: > > 1. Direct payment where people who are making payment are not > redirected to the payment gateway website. > 2. Redirect payment where people who are making payment are redirected > to the payment gateway website and may or may not return later. > 3. API call which is for recurrent payment and other types like > refund, mass pay, query transaction details, etc. > > No, we should not build yet another generic open source online shop > solution! Instead, we should be building plugins and writing articles > on how to integrate with these systems (Zencart, Wordpress, Drupal, > etc). > > A payment plugin is sorely needed in Symfony, but payment plugin != > online shop solution. > > On Sat, Jun 27, 2009 at 3:08 AM, Antoine > Leclercq<[email protected]> wrote: >> Alright, >> I'm preparing the project tools so that we can start working together and >> continue discussing in a more structured way. >> You'll find a new plugin (hopefully it won't be another empty shell) on >> * http://www.symfony-project.org/plugins/sfPaymentPlugin >> The GitHub page is available on >> * http://wiki.github.com/letscod/sfPaymentPlugin >> Following this thread, I think it's pretty obvious that we have to start >> building an interface class as well as a dispatcher class (as @Lee >> suggested). I think they can be both located in a single plugin >> sfPaymentPlugin. >> The specific processing needed by the various payment options will then be >> taken care of in individual plugins (sfPaymentPayPalPlugin, >> sfPaymentAmazonPlugin, sfPaymentGoogleCheckoutPlugin, >> sfPaymentPayboxPlugin...) in which the main class will be implementing the >> interface defined earlier. >> IMHO, if we want to strengthen the payment solution on Symfony, and >> eventually start developing a open source online shop solution (that was my >> dream this morning), existing payment plugins (i.e. sfAtosPaymentPlugin, >> sfPaymentSIPSPlugin) should be reviewed and updated to work using the same >> system, therefore we can define a standard for online payment under Symfony, >> but this might well get pretty unmanageable... I haven't had time yet to >> review them in detail... +1 item to todo list. >> Regards, >> Antoine >> LetsCod >> On Fri, Jun 26, 2009 at 3:45 AM, [email protected] <[email protected]> >> wrote: >>> I think Simon Cast has a point, >>> a) Paypal is crucial, but Amazon Payments is building traction, (it’s >>> a solid affordable solution for many vendors) >>> b) Support reoccuring payments. [I am thinking through the adapter >>> pattern as each provider that supports it will have a different >>> implementation. >>> >>> I would like to contribute to this project, [Just not as the lead, as >>> I don't have the dedication at the mo] But I could definitely >>> contribute as I have some good ecomm experience, and symfony really >>> needs this (as it can boast about so much other stuff at the moment) >>> >>> Be sure to sign me up when this project gets kicked off. >>> >>> On Jun 24, 5:48 pm, Marijn <[email protected]> wrote: >>>> On Jun 19, 7:43 am, Antoine Leclercq <[email protected]> >>>> wrote: >>>> >>>>> Hi back, >>>>> Alright, I'm back to Beirut and ready for real stuff. Symfony Live >>>>> conferences were awesome and there were lots of nice level talks. >>>>> @Marijn : Nice approach. We'll definitely go for wider solution in >>>>> order to >>>>> provide a standard way to process transactions. I need to dig a bit >>>>> more on >>>>> existing online payment solution before starting, hopefully next week. >>>>> Let >>>>> me know when you publish your code. It could be a start. >>>> I just returned from my holiday and have a ton of things to do. I >>>> guess this will take a little longer but maybe I'll just put the >>>> current stuff online as is. Send me a message if you're interested in >>>> having a look. >>>> >>>> >>>> >>>>> @AJStoneham : That's exactly what we are trying to do. I think we all >>>>> had >>>>> the same feeling when trying to find a decent online payment solution >>>>> for >>>>> Symfony... >>>>> Alright, if we want to move to a solid, active and maintainable >>>>> development, >>>>> I suggest we follow these practices : >>>>> - Public Roadmap >>>>> - Repository hosted properly (github.com seems a good solution for >>>>> open >>>>> source projects) >>>>> - Unit and functional tests OK on every commit (use sismo when >>>>> available, >>>>> integrate doc-test?) >>>>> - Updated documentation >>>>> I'll take some more documentation on online payment methods and >>>>> existing >>>>> solutions certainly next week. >>>>> Feel free to share links or snippets of code here. >>>>> See you guys later, >>>>> Antoine >>>>> On Wed, Jun 10, 2009 at 7:39 PM, Marijn >>>>> <[email protected]>wrote: >>>>>> On Jun 10, 4:47 pm, AJStoneham <[email protected]> wrote: >>>>>>> PS, sounds like your using the wrong wheel for api requests. ;-) >>>>>> What wheel do you suggest? >>>>>>> On Jun 9, 3:25 pm, Marijn <[email protected]> wrote: >>>>>>>> P.s. it makes use of sfWebBrowserPlugin to prevent reinventing >>>>>>>> the >>>>>>>> wheel for api requests but it can be injected with any object >>>>>>>> that >>>>>>>> implements a sfWebBrowserInterface >>>>>>>> On Jun 10, 12:23 am, Marijn <[email protected]> >>>>>>>> wrote: >>>>>>>>> Hi everybody, >>>>>>>>> I currently have a private plugin that manages a dutch payment >>>>>>>>> service. The approach I took was quite similar, using >>>>>>>>> interfaces that >>>>>>>>> can be implemented by any object to define transactions. I >>>>>>>>> created a >>>>>>>>> global transaction manager that manages the process that can >>>>>>>>> be >>>>>>>>> injected with any type of payment service adapter. This can be >>>>>>>>> either >>>>>>>>> hooked into the event manager or by extending an abstract >>>>>>>>> module. >>>>>>>>> Currently I also need to create an adapter for paypal payments >>>>>>>>> but >>>>>> not >>>>>>>>> with the generic paypal structure but their paypro api (or >>>>>>>>> whatever >>>>>>>>> its called). >>>>>>>>> I would love to share the code if we all agree it's structure >>>>>>>>> is >>>>>>>>> decent enough:-) >>>>>>>>> Let me know. >>>>>>>>> Marijn >>>>>>>>> On Jun 9, 10:31 am, Antoine Leclercq >>>>>>>>> <[email protected]> >>>>>>>>> wrote: >>>>>>>>>> Sorry I haven't replied earlier, I'm kind of busy during my >>>>>>>>>> trips >>>>>> to France. >>>>>>>>>> @Russen : Please join us on the plugin page so that we can >>>>>>>>>> start >>>>>> the real >>>>>>>>>> stuff next week. >>>>>>>>>> On Tue, Jun 2, 2009 at 8:45 PM, Russen <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>>> I'd love to get into some development with the PayPal >>>>>>>>>>> interface! >>>>>> I'm >>>>>>>>>>> putting aside some non-work development time this summer >>>>>>>>>>> to work >>>>>> on a >>>>>>>>>>> hand-made soap site with a friend, so this would be some >>>>>>>>>>> good >>>>>>>>>>> groundwork. If can't contribute, then at least let me know >>>>>>>>>>> about >>>>>>>>>>> progress, and I'll help with some testing. >>>>>>>>>>> -Russen >>>>>>>>>>> On Jun 1, 12:25 pm, Antoine Leclercq >>>>>>>>>>> <[email protected] >>>>>>>>>>> wrote: >>>>>>>>>>>> Hi Lee, hi all, >>>>>>>>>>>> Great for the sfPaypalPlugin, I'll take the lead. Did >>>>>>>>>>>> you start >>>>>> the >>>>>>>>>>>> development test oriented as you suggested on your >>>>>>>>>>>> previous >>>>>> email ? If >>>>>>>>>>> this >>>>>>>>>>>> is the case, even if it is just a start, I'll be glad to >>>>>>>>>>>> take >>>>>> it over. If >>>>>>>>>>>> not I'll start from scratch. >>>>>>>>>>>> About the sfGoogleCheckoutPlugin, I'll wait till we need >>>>>>>>>>>> it. I >>>>>> prefer to >>>>>>>>>>>> focus on a single solution right now but still take into >>>>>> account the >>>>>>>>>>> global >>>>>>>>>>>> online payment need. >>>>>>>>>>>> Is anyone else interested in contributing to the >>>>>>>>>>>> sfPaypalPlugin >>>>>> ? >>>>>>>>>>>> If you do, it could be interesting that we meet at the >>>>>>>>>>>> Symfony >>>>>> Live >>>>>>>>>>> event, >>>>>>>>>>>> if you go, as I will participating the 2 days. >>>>>>>>>>>> Regards, >>>>>>>>>>>> Antoine Leclercq >>>>>>>>>>>> Branch Manager @ LetsCodhttp://www.letscod.com >>>>>>>>>>>> On Mon, Jun 1, 2009 at 6:14 PM, Lee Bolding >>>>>>>>>>>> <[email protected]> >>>>>> wrote: >>>>>>>>>>>>> My PayPal and GoogleCheckout plugins kind of got >>>>>>>>>>>>> shelved. >>>>>>>>>>>>> I was planning to create an eCommerce solution - but >>>>>>>>>>>>> then >>>>>> discovered >>>>>>>>>>>>> Magento, and have been working with that a lot >>>>>>>>>>>>> recently. >>>>>>>>>>>>> I'm happy to transfer leadership of the sfPaypalPlugin >>>>>>>>>>>>> and >>>>>>>>>>>>> sfGoogleCheckoutPlugin plugins to anybody that wants >>>>>>>>>>>>> to take >>>>>> them. >>>>>>>>>>>>> On 1 Jun 2009, at 08:56, Antoine Leclercq wrote: >>>>>>>>>>>>>> There was an interested thread on the subject in >>>>>>>>>>>>>> December ( >>>>>>> http://groups.google.com/group/symfony-users/browse_thread/thread/520. >>>>>>>>>>> .. >>>>>>>>>>>>>> ) where Lee said that he was in the process of >>>>>>>>>>>>>> reviewing >>>>>> PayPal and >>>>>>>>>>>>>> Google Checkout plugins. I didn't get anything new >>>>>>>>>>>>>> on this >>>>>> since >>>>>>>>>>>>>> that time. Lee, if you are reading, that would be >>>>>>>>>>>>>> lovely if >>>>>> you >>>>>>>>>>>>>> could update us on your plans. >> > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
