2012-08-20 - [GRASE-Hotspot] New Voucher System (Was Re: Paypal integration ??)

Header Data

From: Timothy White <ti***8@gmail.com>
Message Hash: df9fb7483f0b957e77997eefc99cce013b3a06773786724615e3ac9adbd23c27
Message ID: <CAESLx0+4PBu+tGwnPG63Pha5SnzO6swZA-WyxuEk8WGVGEzfBg@mail.gmail.com>
Reply To: N/A
UTC Datetime: 2012-08-20 14:11:46 UTC
Raw Date: Tue, 21 Aug 2012 07:11:46 +1000

Raw message 

On Tue, Aug 14, 2012 at 11:35 PM, Hans van de Voorde
<ha***s@van-de-voorde.com> wrote:
> Hi Tim,
> Great that you are back in bussiness with the new development system.
> I hope that it is also getting better on the hours of sleep per night.
> I see that things are moving again and asked my self where you are at with
> the Paypal project.
> I know that you had a test verion working a couple of months ago. Is there
> any chance that it will be ported into an official release?

Glad you asked!

Due to a discussion with an interested 3rd party who wants to pay for
a specific payment gateway, I've started the paypal stuff from
scratch, and it's for the better.
Here's a good opportunity to explain to everyone how the new system
will work, and why.

First, some history. The original system only had users, no concept of
tickets, and the pricing system for the place it was written for, was
linear. $X for 1Mb or $Y for 1minute. It also didn't matter from an
accounting point of view if there was records of the $ amount sold,
the $ amount was just a guide as all payments happened manually in
cash.

This doesn't scale so well to other organisations, for example most
ISP's give you a discount if you purchase more quota. Hotels/Motels
love you buying the bigger internet pack, because chances are you
won't use it all, so even though it was cheaper per Mb, the hotel
actually wins out in the majority of use cases. It also doesn't allow
a $ value to be placed on other aspects of the account, for example
high quota, but short usage time vs high quota and long usage time. Or
bandwidth limits, etc.

So the first thing I'm in the process of doing (90% done) is
disconnecting data/time limits from $ values, and making them
customisable however the admin wants, no more linear options, you
choose the options!

When then have groups, (which we already have implemented) that define
a "ticket" type with it's default settings and limits. You'll still be
able to create users manually in a group, and inherit the group
settings are define your own settings at creation time (within a group
still).

Then we'll have "vouchers" (naming still to be worked out) that define
a $ value, and some limits for the $ value. All vouchers will still
fall under a group, and will be able to be purchased as ether an
initial voucher, or a topup. i.e. you charge them $10 for the first
100Mb, but topups of 100Mb are only $5. Each group will define a
voucher group, which helps define which vouchers can topup which
vouchers. Basically, topups have to be within the same group, this
ensures that settings like bandwidth limits are maintained, and they
don't purchase a cheap topup in a group with less restrictive
bandwidth, but still have all their time quota.

The purchasing system will consist of selecting a voucher type,
(group), then the initial purchase or the topup purchase. It'll then
use a plugin system to allow different payment gateways to be used
(including a manual Admin gateway that allows the manual issuing of
vouchers, i.e. a cash register) and finally the creation of the
voucher. There will probably be a way to even create vouchers that are
tied to something, like the computer MAC address, or a phone number
and uses SMS to authenticate the user.

I hope that gives everyone a clear image of the direction I'm going.
It should clear up the UI a bit as well, as some of the legacy stuff
cluttered up the screen. Paypal will probably be the second public
gateway written, with Manual being the first!

Tim

Thread