Hi Jacques On Mon, May 5, 2014 at 9:23 AM, Jacques Le Roux <[email protected]> wrote: > Did not read all, just to be sure: did you read > https://cwiki.apache.org/confluence/display/OFBIZ/Subscription > Yes.
This thread basically reduces to whether or not more of what is required had been developed/deployed since that was written. The answer appears to be no. But let me ask you, to what extent has the ecommerce system in OFBiz been checked against PCI compliance requirements? I ask because some processors will not even give you an account (or let a gateway connect, in order to function as a reseller) unless you can prove (via documentation from the PCI audit) that you're PCI compliant, while others eliminate the need for PCI compliance by forcing the merchant to use their plugin that basically ensures that none of the customer's payment information passes through the merchant's machine (the merchant can collect contact information as usual, but never gets even so much as the BIN and last four digits of the credit card, let alone the CVV and expiry date). If it hasn't been done, I would suggest that a suite of PCI scanning and audit tools, and documentation as to how to self scan, so as to reduce the burden/cost for a merchant aiming to become PCI compliant. Cheers Ted > Jacques > > Le 05/05/2014 14:38, Ted Byers a écrit : > >> Hi Raj >> >> On Mon, May 5, 2014 at 1:35 AM, Rajbir Saini <[email protected]> wrote: >>> >>> Ted, >>> >>> I am sorry for the confusion and half information. May be I was too quick >>> in >>> replying. Regarding example in OFBiz, there are an example but it is more >>> about the subscription of newsletters. That could be a good starting >>> point >>> and that is the place I have started. >>> >> Ah, OK. So the material I saw isn't so out of date after all. >> >>> I think key to the implementation is putting together your data properly. >>> SubscriptionResource is the most important entity and it has most of what >>> you need. Your product type should be digital goods to make the >>> subscription >>> work. >> >> OK. That is straight forward. >> >>> You may need to write a fulfillment service to fulfill the orders >>> depending >>> upon your fulfillment process. For recurring billing, there are two ways >>> to >>> handle it. Auto and manual. For auto billing, your payment processor must >>> support it and if this flat in your subscription entity is set to true >>> and >>> auto renewal service is schedule, it will create an order which will be >>> auto >>> approve the order and charge the credit card etc. For manual, you will >>> need >>> to write your own code and action is user initiated (e.g. a renew >>> subscription link on profile page). >>> >> OK. I would have thought that this would have been developed and >> included, for it to be said that subscriptions and recurrent billing >> are available out of the box. So, If it is the case that I develop >> and deploy a subscription based service using Wordpress (not a simple >> newsletter) and Perl (say, something that allows users to prepare meal >> plans and evaluate whether or not the meal plans so created meet the >> nutritional requirements of each member of the household without >> breaching their nutritional constraints imposed by various chronic >> diseases), I would have to develop a service within OFBiz to connect >> the two (and manage access to the service according to what has or has >> not been paid). >> >> For autobilling, it can be said it is only partly developed. I work >> mostly in developing transaction processing services for ecommerce >> merchants, and the vast majority of processors I deal with do not >> support it. Yet, the president of the company I work with wants to >> offer it since most of the merchants he deals with need it. That is >> why I will have to design and develop a vault at some point this year. >> >> If a merchant's business model requires rebilling (as do subscription >> based businesses), use of either a processor that supports it, or a >> vault, is essential. This is about PCI compliance. For, say, book >> sellers, PCI compliance is easy, since there is no need to store a >> customer's payment information. But, with rebilling, the customer's >> payment information must be stored somewhere, and that means a vault >> maintained either by the merchant, a third party vault service (and >> this is feasible ONLY if that service has integrated into the >> processor you're using), or the processor. There is, thus, a way to >> go before rebilling can be said to be fully supported out of the box. >> And, I half suspect that creation and deployment of a vault may almost >> be a separate project as a properly constructed vault shouldn't even >> be on the same local subnet as the server running OFBiz (it requires a >> segmented LAN, and a machine that provides an API to which OFBiz can >> submit customer payment information for subsequent use in processing >> rebills). >> >> Cheers >> >> Ted >> >>> Thanks, >>> >>> Raj >>> >>> >>> On Monday 05 May 2014 07:53 AM, Ted Byers wrote: >>>> >>>> On Sun, May 4, 2014 at 10:11 PM, Rajbir Saini <[email protected]> >>>> wrote: >>>>> >>>>> Ted, >>>>> >>>>> By the way why should contens of a web site has to be related to Ofbiz? >>>>> Contents of a web site are to be related to a business and not the >>>>> OFBiz. >>>>> >>>> No, of course not. But just showing the url for a businesses website, >>>> with out some explanation, leaves open the question as to the purpose. >>>> >>>> I would have expected either a statement that the site is deployed >>>> using OFBiz, and a pointer to those parts that deal with the original >>>> request about support for recurrent billing and subscriptions, or >>>> information on it about OFBiz related to the original question. >>>> >>>>> The site in question is 100% OFBiz. Only addition is URL rewriting and >>>>> we >>>>> use Apache HTTPd and mod rewrite to do that. >>>>> >>>> OK. But you should have said so. If you had, I would have said >>>> nothing. Or rather, I probably would have just asked you what you did >>>> to support the subscription business model and the matter of rebilling >>>> customers. >>>> >>>> There is no real conflict here. But now that matter has been >>>> clarified, can you tell us what you did specifically to support >>>> subscriptions and rebilling? Everything I have found to date is >>>> dated, and seems to be from before support for commercial >>>> subscriptions was added to OFBiz. >>>> >>>> Cheers >>>> >>>> Ted >>>> >>>>> On May 5, 2014 7:24 AM, "Ted Byers" <[email protected]> wrote: >>>>>> >>>>>> On Sun, May 4, 2014 at 9:36 PM, Rajbir Saini <[email protected]> >>>>>> wrote: >>>>>>> >>>>>>> You can have a look at http://www.webovs.com/ >>>>>>> >>>>>>> >>>>>> What does this site have to do with the question of subscriptions and >>>>>> recurring billing? >>>>>> >>>>>> If you're claiming that site uses OFBiz and has deployed code that >>>>>> supports subscription and rebilling, then it would be useful to >>>>>> provide an URL that lets us examine the code. >>>>>> >>>>>> The content of that site does not appear even to be related to OFBiz, >>>>>> let alone support subscription and rebills. >>>>>> >>>>>> Cheers >>>>>> >>>>>> Ted >>>>>> >>>>>>> On Monday 05 May 2014 03:33 AM, anon wrote: >>>>>>>> >>>>>>>> Hello everyone, >>>>>>>> I have a small application in grails that I would like to port to >>>>>>>> ofbiz >>>>>>>> to >>>>>>>> take advantages of things like billing, payment and other things. >>>>>>>> But >>>>>>>> before >>>>>>>> I set out to do it, I was wondering if there was an example in ofbiz >>>>>>>> of >>>>>>>> an >>>>>>>> application where users can subscribe to different plans like >>>>>>>> "basic", >>>>>>>> "professional", "enterprise" with recurring billing, so I can see >>>>>>>> whether >>>>>>>> the switch is worth it. >>>>>>>> Thanks for your help. >>>>>>>> >>>>>> >>>>>> -- >>>>>> R.E.(Ted) Byers, Ph.D.,Ed.D. >>>>>> [email protected] >>>> >>>> >>>> >> >> > > -- -- R.E.(Ted) Byers, Ph.D.,Ed.D. [email protected]
