Recurring Billing And Subscription

[anon]

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.

[Rajbir Saini]

You can have a look at http://www.webovs.com/

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.
>

[Ted Byers]

On Sun, May 4, 2014 at 9:36 PM, Rajbir Saini <[hidden email]> 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.
[hidden email]

[Ted Byers]

OFBiz does have some support for subscriptions, but I am not the one
to tell you how much of what is required is supported out of the box.

What I am curious about, though, is the problem of ensuring PCI compliance
 with a recurrent billing, or rebilling, business model.  Ensuring the
safety of customer payment information is not a trivial task
(basically, if you do it yourself, you have to establish a vault that
can not be accessed by any machine other than the machine that runs
the program that determines what accounts need to be rebilled and when
- that means that I would see a segmented LAN, with three sets of
non-routable IP address: 1 for the machines running OFBiz and it's
database, a second for the vault, and which ignores all traffic coming
from the first, or from the internet, and a third which includes the
machine running the rebill engine that reads the relevant rebill data
from OFBiz's database, and payment information from the vault, and
then submits the payment to the payment processor).

I would ask you to what extent are you, or have you, deployed anything
like a vault for customer payment information, or are you going to go
that route?  You could seek out payment gateway's that will tokenize
your customer's payment information, so you can use their gateway to
support rebilling, but that comes with a non-trivial cost.  But for
many, that is a viable option.  And, there are third party vault
service providers.

And I would ask the OFBiz gurus to what extent is commercial
subscription supported out of the box, or would I be correct that all
of this pretty much must be developed de novo?

Cheers

Ted



On Sun, May 4, 2014 at 6:03 PM, anon <[hidden email]> 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.
[hidden email]

[Rajbir Saini]

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.

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.

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).

Thanks,

Raj

On Monday 05 May 2014 07:53 AM, Ted Byers wrote:

> On Sun, May 4, 2014 at 10:11 PM, Rajbir Saini <[hidden email]> 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" <[hidden email]> wrote:
>>> On Sun, May 4, 2014 at 9:36 PM, Rajbir Saini <[hidden email]> 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.
>>> [hidden email]
>
>

[Pierre Smits]

Hi,

Let's divide this up so that it is more comprehensible.

1st: you want to define products (in OFBiz terminology) that can be
ordered/requested/subscribed to by users - this functionality is in place.
2nd: you want to invoice these users for the service rendered - this
functionality is in place
3nd: you want to retrieve payment for the service rendered - functionality
for integration with several payment processing providers is in place.
4th: you want to do other things - this is to vague.

Regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

[Ted Byers]

Hi Raj

On Mon, May 5, 2014 at 1:35 AM, Rajbir Saini <[hidden email]> 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 <[hidden email]>
>> 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" <[hidden email]> wrote:
>>>>
>>>> On Sun, May 4, 2014 at 9:36 PM, Rajbir Saini <[hidden email]>
>>>> 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.
>>>> [hidden email]
>>
>>
>>
>

--
R.E.(Ted) Byers, Ph.D.,Ed.D.
[hidden email]

[Jacques Le Roux]

Did not read all, just to be sure: did you read https://cwiki.apache.org/confluence/display/OFBIZ/Subscription

Jacques

Le 05/05/2014 14:38, Ted Byers a écrit :

> Hi Raj
>
> On Mon, May 5, 2014 at 1:35 AM, Rajbir Saini <[hidden email]> 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 <[hidden email]>
>>> 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" <[hidden email]> wrote:
>>>>> On Sun, May 4, 2014 at 9:36 PM, Rajbir Saini <[hidden email]>
>>>>> 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.
>>>>> [hidden email]
>>>
>>>
>
>

--

[Ted Byers]

Hi Jacques

On Mon, May 5, 2014 at 9:23 AM, Jacques Le Roux
<[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>> 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" <[hidden email]> wrote:
>>>>>>
>>>>>> On Sun, May 4, 2014 at 9:36 PM, Rajbir Saini <[hidden email]>
>>>>>> 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.
>>>>>> [hidden email]
>>>>
>>>>
>>>>
>>
>>
>
> --

--
R.E.(Ted) Byers, Ph.D.,Ed.D.
[hidden email]

[anon]

Thanks a lot for the detailed break down of the things I have to care
about. I am thinking more about using a payment gateway, since it is the
easy way out.
On 05.05.2014 04:09, Ted Byers wrote:

> OFBiz does have some support for subscriptions, but I am not the one
> to tell you how much of what is required is supported out of the box.
>
> What I am curious about, though, is the problem of ensuring PCI compliance
>   with a recurrent billing, or rebilling, business model.  Ensuring the
> safety of customer payment information is not a trivial task
> (basically, if you do it yourself, you have to establish a vault that
> can not be accessed by any machine other than the machine that runs
> the program that determines what accounts need to be rebilled and when
> - that means that I would see a segmented LAN, with three sets of
> non-routable IP address: 1 for the machines running OFBiz and it's
> database, a second for the vault, and which ignores all traffic coming
> from the first, or from the internet, and a third which includes the
> machine running the rebill engine that reads the relevant rebill data
> from OFBiz's database, and payment information from the vault, and
> then submits the payment to the payment processor).
>
> I would ask you to what extent are you, or have you, deployed anything
> like a vault for customer payment information, or are you going to go
> that route?  You could seek out payment gateway's that will tokenize
> your customer's payment information, so you can use their gateway to
> support rebilling, but that comes with a non-trivial cost.  But for
> many, that is a viable option.  And, there are third party vault
> service providers.
>
> And I would ask the OFBiz gurus to what extent is commercial
> subscription supported out of the box, or would I be correct that all
> of this pretty much must be developed de novo?
>
> Cheers
>
> Ted
>
>
>
> On Sun, May 4, 2014 at 6:03 PM, anon <[hidden email]> 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.
>
>

[anon]

  1,2,3 are what I am looking at. I intend to grow the application and I
am tired of recoding most things from scratch. I think I can go a long
way with ofbiz.
On 05.05.2014 09:45, Pierre Smits wrote:

> Hi,
>
> Let's divide this up so that it is more comprehensible.
>
> 1st: you want to define products (in OFBiz terminology) that can be
> ordered/requested/subscribed to by users - this functionality is in place.
> 2nd: you want to invoice these users for the service rendered - this
> functionality is in place
> 3nd: you want to retrieve payment for the service rendered - functionality
> for integration with several payment processing providers is in place.
> 4th: you want to do other things - this is to vague.
>
> Regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>

[anon]

Excellent read.
Thank you.

On 05.05.2014 15:23, Jacques Le Roux wrote:

> Did not read all, just to be sure: did you read
> https://cwiki.apache.org/confluence/display/OFBIZ/Subscription
>
> Jacques
>
> Le 05/05/2014 14:38, Ted Byers a écrit :
>> Hi Raj
>>
>> On Mon, May 5, 2014 at 1:35 AM, Rajbir Saini <[hidden email]>
>> 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
>>>> <[hidden email]>
>>>> 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" <[hidden email]> wrote:
>>>>>> On Sun, May 4, 2014 at 9:36 PM, Rajbir Saini <[hidden email]>
>>>>>> 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.
>>>>>> [hidden email]
>>>>
>>>>
>>
>>
>

[Ted Byers]

On Mon, May 5, 2014 at 3:21 PM, anon <[hidden email]> wrote:
> Thanks a lot for the detailed break down of the things I have to care about.
> I am thinking more about using a payment gateway, since it is the easy way
> out.
>
It is easy, but it comes with a price.

On that score, you will need accounts both at the gateway and at a
processing bank.  You might need to see if your chosen bank deals with
the gateway(s) you're interested in, or if your chosen gateway can
help with getting an account at one of the processing banks they deal
with.  Some gateways see that kind of service as part of the benefits
they provide to the merchants they serve.  But that too comes at a
price.

I just recalled reading recently about Amazon's payment services.
They certainly run a vault, but you'll have to check whether or not
they offer vault services to the merchants they serve.  One of the
things I noticed is that they require the merchant to have an account
at a US-based bank, into with they ACH their settlements ot the
merchant.  That may be useful to you, or it may be a deal breaker.
But it is worth checking out since their rates are among the lowest I
have seen anywhere (though Paypal seems competitive too - but then, I
don't know whether Paypal provides vault services).  I don't normally
recommend other businesses, but if you deal with one of the banks that
NMI deals with, you should check out NMI.  They are one of the best
gateways in the business, and quite reasonable (and I know they
support everything you need).  NB: I do not have any connection with
NMI, so you could regard this as a recommendation from a company that
is striving to compete with NMI.  ;-)  Seriously, they are nice guys,
so give them a call and see what they can do for you.  You would have
to integrate them into your shopping cart/billing system, but their
API is one of the best documented, cleanest and simplest APIs I have
seen in this business.

Good luck,

Ted

> On 05.05.2014 04:09, Ted Byers wrote:
>>
>> OFBiz does have some support for subscriptions, but I am not the one
>> to tell you how much of what is required is supported out of the box.
>>
>> What I am curious about, though, is the problem of ensuring PCI compliance
>>   with a recurrent billing, or rebilling, business model.  Ensuring the
>> safety of customer payment information is not a trivial task
>> (basically, if you do it yourself, you have to establish a vault that
>> can not be accessed by any machine other than the machine that runs
>> the program that determines what accounts need to be rebilled and when
>> - that means that I would see a segmented LAN, with three sets of
>> non-routable IP address: 1 for the machines running OFBiz and it's
>> database, a second for the vault, and which ignores all traffic coming
>> from the first, or from the internet, and a third which includes the
>> machine running the rebill engine that reads the relevant rebill data
>> from OFBiz's database, and payment information from the vault, and
>> then submits the payment to the payment processor).
>>
>> I would ask you to what extent are you, or have you, deployed anything
>> like a vault for customer payment information, or are you going to go
>> that route?  You could seek out payment gateway's that will tokenize
>> your customer's payment information, so you can use their gateway to
>> support rebilling, but that comes with a non-trivial cost.  But for
>> many, that is a viable option.  And, there are third party vault
>> service providers.
>>
>> And I would ask the OFBiz gurus to what extent is commercial
>> subscription supported out of the box, or would I be correct that all
>> of this pretty much must be developed de novo?
>>
>> Cheers
>>
>> Ted
>>
>>
>>
>> On Sun, May 4, 2014 at 6:03 PM, anon <[hidden email]> 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.