Subscriptions / Recurring billing?

[Success]

Hi Mike,

Your suggestion is an alternative.

But I believe why the threadstarter ask for recurring billing is because the nature of this business model leads to more stable recurring income.

More importantly, in a recurring billing system, the ad goes on until the user cancels that ad.

For example, when you pay for a service which you need every month like your hosting or autoresponder, you would want the service and automated billing to go on and on with minimum hassle to you.

For a classified, it's an ad the customer wants to go on and on, until the customer cancels it.

If the user choose a 1 month, or 1 year package, the main difference is that the customer still needs to renew the ad, which he may not do, and in turn leads to lower revenue for you.

Every renewal is a breaking point where certain number of customers are lost.

[Maffo]

I myself wouldnt program this as a module. I cant see it suiting a universal audience. There are the issues I have mentioned in the previous couple of posts. There are the users who may have custom payment gateways or less popular gateways. What about when bulk listing packages are introduced? When writing a module it has to configurable to each users particular needs. I can tell you from experience that nobody is ever happy with the way a module comes out of the box. 'I want this' 'I want that' 'why cant I do this'

For this system I feel its bespoke to the site in question and cant really be made globally. Maybe if you got two or three people who exactly the same system you could split the costs.

[Lhotch]

From a developer point of view I agree with Maffo. Modules can take many many man hours to build, test trouble shoot etc. If only a handfull of people are going to buy it then its not worth the time to create it.

This is also likely why many features dont make it into the actual product. Too time consuming to justify the demand and too many possible and conflicting variations.

[Success]

As another member posted earlier, we don't need to have the work done on every payment gateway. Just a few or even 1 is good enough.

Users who have custom payment gateways or less popular gateways would require additional customization.

Regarding bulk listing, it's our job to set the rules on what can be billed under recurring or single payment.

If recurring bulk listing is not possible, as compared to individual recurring ad, we just need to state that recurring is for individual ads.

I hope you don't mind this. Personally, I feel that if it's a trend that improvements or suggestions for a software often leads to asking to pay for the new feature, the software and it's community won't go far. Just look around.

I would anytime prefer to pay more to the developing team for the software and it's yearly upgrades, and get continuous improvements in the software.

Vbulletin is a very good example. I have more than 10 owned licenses with them and their software is top notch.

[Lhotch]

Originally Posted by Success

As another member posted earlier, we just don't need to have the work done on every payment gateway. Just a few or 1 is every good enough.

Users who have custom payment gateways or less popular gateways would require additional customization.

Regarding bulk listing, it's our job to set the rules on what can be billed under recurring or single payment.

But who decides what everyone needs? You have stated what you desire but intentionally state that other less popular payment gateways do not need to be incorporated. This is in direct opposition to what you state below.

Originally Posted by Success

If recurring bulk listing is not possible, as compared to individual recurring ad, we just need to state that recurring is for individual ads.

I hope you don't mind this. Personally, I feel that if every improvement or suggestion for a software leads to asking to pay for the new feature, the software and it's community won't go far. Just look around.

I would anytime prefer to pay more to the developing team for the software and it's yearly upgrades, and get continuous improvements in the software.

Vbulletin is a very good example. I have more than 10 owned licenses with them and their software is top notch.

You are comparing apples to oranges when you compare VB to 68c. All businesses have to decide where to focus their efforts and 68c is no different. Over thetime I have been using the product I have seen a steady stream of improvements and I expect that trend to continue.

However you have to realize that there are only so many man hours in a day and it would be silly for a company to spend all of them creating features that cater to the few while tabling features that cater to the many.

I can just about gaurantee that if a system was built to fit your needs, for every peice of praise there would be someone to state it doesnt fit their model.

Also, your desire to pay more for updates and continued improvements does not encompass all users and just your desire and willingness to pay is likely not enough.

Your input is valuable of course and customer input is what allows 68c to continually improve but keep in mind it is still a realatively young product. In the end it will never be a complete product to everyone which is also one reason you can get the developer edition to make your own changes or hire someone to do them.

Heck who knows maybe they will create just what your looking for and ad it in at some time.

[Success]

Hi Larry,

I agree with what you said.

But I want to correct one thing.

Originally Posted by Lhotch

But who decides what everyone needs? You have stated what you desire but intentionally state that other less popular payment gateways do not need to be incorporated. This is in direct opposition to what you state below.

I second the suggestion for a recurring billing feature.

But I did not state what I desire; I did not even say which payment gateway I want, or is good for this feature.

It would be impractical for anyone to suggest that recurring billing can be, or should be, implemented for all payment gateways.

In line of constructive suggestions for the software, that's why I said it's good enough if this feature is available for a few or even 1 payment gateway for now.

Which payment gateway is suitable for recurring billing, and best for 68, is for the developing team to decide.

This is still the thread starter's presale thread. I have shared enough, and too much, of my thoughts.

[Lhotch]

Originally Posted by Success

I did not state what I desire.

I did not even say which payment gateway is good for this feature.

It would be crazy for anyone to suggest that recurring billing can be and should be implemented for all payment gateways.

This is getting silly now and just going in circles. I didnt say you spoecified any gateways, I simply said that you said they all didnt need to be included which means it will surely piss someone off.

All I have tried to do here was express the complexity of adding such a thing. Often times the most simple items in context can be the most difficult to implement and this is always overlooked by the non coding community.

[tungsten]

Hi everybody,

I'm french, and my project is to buy one 68classified licence and Super Mod System licence too,
only if i'm sure i can meet a developper, who may custom the original script and propose to my customers,
a reccuring paypal billing !!?
I need a Googlemaps API to know the distance between seller and buyer ,and evaluation note system too (EBAY).
Thank you for your good ideas and suggestions...

[cwp]

Originally Posted by tungsten

Hi everybody,

I'm french, and my project is to buy one 68classified licence and Super Mod System licence too,
only if i'm sure i can meet a developper, who may custom the original script and propose to my customers,
a reccuring paypal billing !!?
I need a Googlemaps API to know the distance between seller and buyer ,and evaluation note system too (EBAY).
Thank you for your good ideas and suggestions...

If you're looking to get quotes for custom work I suggest you to start a new thread, since this one is somewhat old.