Why don't developers offer payment in instalments?

[basslinemaster]

Yeah. Way too much hassle for the respective company.

How? Can you elaborate? Do you know how software is sold, how it is delivered to the customer? It's all automated, the developer doesn't have to do anything at all.

Say I am selling some software - a word processor, for £99. I have a sale before Christmas, for £33, and I see sales go up by ten times. I then decide to offer payment on instalments, three monthly payments of £33. To prevent people paying only £33 and then having the full program, it expires after one month, until they've paid all three payments. All of this is automatically done by my e-commerce system. I don't have to manually do anything, whether the customer pays the whole £99 or wants to pay in instalments.

What exactly is so difficult and troublesome to the developer in that scenario?

Who sets up and manages the transactions? Who tracks who did/didn't pay? Who collects the money? How do you identify a standard transaction from a deferred transaction? Do we keep two systems (regular shopping cart vs special cart)? Who codes and maintains the special "payment plan" part of the software authorization system? Who does the financial tracking for taxes on deferred payments?

If you did that to create, what I would estimate to be about 3 users ... it's a total money pit. If it was 10,000 users .. it would be marginally viable.

You don't even understand how most software is sold on the internet... It's ALL automated. What do you mean - "Who tracks who did/didn't pay?" How can anybody NOT pay? Who collects the money? The SYSTEM collects the money. How do you identify a deffered a standard transaction from a deferred transaction? Umm... one is 'Product 1' that costs £33, and the other is 'Product 2" that costs £99.
You estimate it to be about 3 users... okay...

[Burillo]

other things were already answered by other, so i'll just concentrate on this one.

What do you mean, SJ_Digriz "use a payment system through paypal or whatever"? Credit cards charge interest.

so you essentially want a zero interest loan from the developer? why not go to a bank instead? get a small load, pay all of it in time, only to a bank, not to developer.

No, not a 'zero interest loan' from the developer. Did you even read my first post? In what way is this a loan of any kind?

OK. so you get a product that costs X, paid off in installments in Y months, but this is totally not a loan because...?

picture a similar scenraio: you go to a bank, get X amount of money, buy the product and pay back the bank over Y months.

how is that different from your scheme?

[beely]

> Why don't developers offer payment in instalments?

Because it's a lot of hassle for no real benefit to the bottom line.
It would take more resources to implement and administer than would be made up for in extra sales.

> But it's a good idea!

But yet no one does it.

> Maybe they just didn't think of it, and I've thought of something great that everyone else has missed that has no downside!

No.

[GaryG]

No, it isn't a credit agreement.

I think in the eyes of the law it is.

Even if you frame it as three separate purchases to avoid that then I still think it's a lot of work for the developer. He may only have to set it all up once but that setup includes a way of making tailor made installers with expiry dates specific to the purchase. Then he gets to update the system as patches come along. Far from cost free for the dev.

Again, I don't see why anyone would bother as the promise of increased sales is far from proved.

[SJ_Digriz]

You don't even understand how most software is sold on the internet... It's ALL automated.

Actually, it's a big part of what I do for a living. And it's exactly this idea that all things happen magically in the cloud that creates such a disconnect for a lot of you. Who sets up the automation for the different tracking? What happens when someone doesn't pay? You say they can't not pay? That's bullshit. People don't pay on automated transfers every day. And again, the ability to auto pay in increments is ALREADY available. You're just trying to find a way to do it with no fee to you. You're just pushing the burden of tracking away from the financial system and onto the company ... which will then have to put it back into the financial system.

[fluffy_little_something]

Software is way too cheap to be paid in installments
They could implement such a payment plan in poor countries, but then again, who in Mali needs Diva ?

[rod_zero]

[basslinemaster]

other things were already answered by other, so i'll just concentrate on this one.

What do you mean, SJ_Digriz "use a payment system through paypal or whatever"? Credit cards charge interest.

so you essentially want a zero interest loan from the developer? why not go to a bank instead? get a small load, pay all of it in time, only to a bank, not to developer.

No, not a 'zero interest loan' from the developer. Did you even read my first post? In what way is this a loan of any kind?

OK. so you get a product that costs X, paid off in installments in Y months, but this is totally not a loan because...?

picture a similar scenraio: you go to a bank, get X amount of money, buy the product and pay back the bank over Y months.

how is that different from your scheme?

Because you don't get the full product for £33! You get ONE MONTH of the product for £33. You get another month for another £33. You could be given a 'token' each time you buy one month of use of the product, and when you have two tokens, you can buy the full product for another £33. No loan involved. Where is the loan? The developer decides how much to charge you for one month's use of the product. Like I said - I knew this would happen - I made it as clear as possible, and people can't even understand what I wrote in the original post, and find faults with strawmen arguments.

Anyway, this should settle it once and for all:

https://www.skrill.com/en/business/prod ... stalments/

Skrill Pay by Instalments

Offer a popular and simple financing option at your checkout – with Skrill’s Pay by Instalments. Your customers can choose to pay later, with no risk for you. Because you get paid immediately by Skrill.


The advantages of Pay by Instalments with Skrill:

Customers can choose to pay in up to 12 monthly instalments
Larger shopping carts and more revenue
Receive immediate payment in full from Skrill
No payment default risk for you
Access to a larger customer base
No customer registration necessary, so no sensitive data involved
Available Skrill branded or as a white-label solution.

or Worldpay

http://www.shopcreator.com/partners.cfm

There is a Future Pay Package which allows you to accept subscription payments and payment by instalment in addition to credit and debit cards. There is an additional charge of £100 for this package.

[basslinemaster]

> Why don't developers offer payment in instalments?

Because it's a lot of hassle for no real benefit to the bottom line.
It would take more resources to implement and administer than would be made up for in extra sales.

> But it's a good idea!

But yet no one does it.

> Maybe they just didn't think of it, and I've thought of something great that everyone else has missed that has no downside!

No.

LOL. Yes, of course, everything has already been thought of already, and there will never be anything new in the world...


As for "Because it's a lot of hassle for no real benefit to the bottom line.
It would take more resources to implement and administer than would be made up for in extra sales."

Evidence, please? "no real benefit to the bottom line" - so increased sales aren't a benefit?

[basslinemaster]

No, it isn't a credit agreement.

I think in the eyes of the law it is.

Even if you frame it as three separate purchases to avoid that then I still think it's a lot of work for the developer. He may only have to set it all up once but that setup includes a way of making tailor made installers with expiry dates specific to the purchase. Then he gets to update the system as patches come along. Far from cost free for the dev.

Again, I don't see why anyone would bother as the promise of increased sales is far from proved.

No it isn't. The developer is offering the following:
One month's use of a VST for £33, with ten points.
When have twenty points, you can buy the full, indefinite use version of the same VST for £33.
The first two purchases of £33 are for a one month only version of the VST. It is clearly a different product to one without an expiry date.

The system makes tailor made installers...

http://www.ssware.com/cryptolicensing/c ... ng_net.htm

Create Evaluation Licenses with various evaluation parameters such as

Absolute date/time after which the license expires.
Maximum usage days
Maximum unique usage days
Maximum executions
Maximum run-time
Maximum cumulative run-time

Do you think that a company which sells, say, 1,000 downloads of copy protected software every day, MANUALLY implements the copy protection? It's all done automatically, by whatever copy protection system you use, which is the whole point of them! People are selling software for £2.99 and it uses copy protection - do you think they have to manually do anything at all, for each sale?

The expiry date is automatically set by the copy protection system - at the time of download.

If you all understood how this worked, then you wouldn't be raising these objections.

[Dominus]

Do you think that a company which sells, say, 1,000 downloads of copy protected software every day, MANUALLY implements the copy protection? It's all done automatically, by whatever copy protection system you use, which is the whole point of them! People are selling software for £2.99 and it uses copy protection - do you think they have to manually do anything at all, for each sale?

The expiry date is automatically set by the copy protection system - at the time of download.

If you all understood how this worked, then you wouldn't be raising these objections.

So, a second layer of copy protection on top of whatever the developer uses? Brilliant.

[basslinemaster]

You don't even understand how most software is sold on the internet... It's ALL automated.

Actually, it's a big part of what I do for a living. And it's exactly this idea that all things happen magically in the cloud that creates such a disconnect for a lot of you. Who sets up the automation for the different tracking?

Uuh... you pay a developer to do it for you in ten minutes?

What happens when someone doesn't pay? You say they can't not pay? That's bullshit. People don't pay on automated transfers every day.

What do you mean? Again, you didn't even read nor understand my original post.
They buy ONE MONTH of use of the software - it EXPIRES one month after they install it. So how can they not pay? If they don't pay for the second download, for another month, so what? You've had £33 out of them, and they've only got to use your software for a month!

And again, the ability to auto pay in increments is ALREADY available. You're just trying to find a way to do it with no fee to you.

To me? This has nothing to do with me, I'm not a developer...
I've suggested a system which benefits both parties, the customer and the developer.
The customer can pay £33 to use the VST for a month. Maybe the next month they can't afford £33, so they can't buy the next month's use. Then a month later they pay another £33 and get another month's use. Then maybe two months after that, they pay the final £33 and get the entire VST, which they most likely wouldn't have bought without that facility. Why do you think so many people use credit cards? Because they can afford to buy everything they want up front?

You're just pushing the burden of tracking away from the financial system and onto the company ... which will then have to put it back into the financial system.

You didn't bother to read my original post... no point in arguing with strawmen.

[basslinemaster]

Do you think that a company which sells, say, 1,000 downloads of copy protected software every day, MANUALLY implements the copy protection? It's all done automatically, by whatever copy protection system you use, which is the whole point of them! People are selling software for £2.99 and it uses copy protection - do you think they have to manually do anything at all, for each sale?

The expiry date is automatically set by the copy protection system - at the time of download.

If you all understood how this worked, then you wouldn't be raising these objections.

So, a second layer of copy protection on top of whatever the developer uses? Brilliant.

No, the developer can implement a one month expiry date themselves if they want to continue using their own copy protection, or they can switch to another copy protection system that offers that functionality.

Any other meaningless objections?

[SJ_Digriz]

Uuh... you pay a developer to do it for you in ten minutes?

Your estimation skills are both weak and incomplete ...

Let me know how that works out for you at your software development company.

[SJ_Digriz]

I've suggested a system which benefits both parties, the customer and the developer.

debatable

The customer can pay £33 to use the VST for a month. Maybe the next month they can't afford £33, so they can't buy the next month's use.

This is called SaaS, Software as a Service ... or subscription or rental etc... However, it comes with an overhead that is built into the cost of the software. And, it typically doesn't end up with you owning the software. Doing subscription on $100 software is stupid.

Why do you think so many people use credit cards? Because they can afford to buy everything they want up front?

I don't debate the need for the credit process or delayed payment. I'm saying that process already exists.

You didn't bother to read my original post... no point in arguing with strawmen.

If you had even a small clue how financial transactions occurred and are tracked you would realize that mine is far from a strawman. There is a system in place that companies use to manage purchases. Doing things outside those known processes is expensive. However, your proposal is just a rental system by another name. And, the rental paradigm doesn't fit the product space.