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]
