Re: UU Courses and classes

["Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>]

Alexey Parshin wrote:
>
> If any class admin can add other user to the class - does it mean that
> payment is optional?
Yes, if admin explicitly adds student to his class, payment is bypassed.
Now, this does
create a strange situation, if class owners pay to the course owners
some percentage
(this allows bypassing of our payment system). Perhaps it should be OK,
and course owners
would be only getting percentage of what comes through our payment
system. We cannot
control what goes on outside anyways.
> We have to think seriously on what admin can do with users if it
> involves money.
> Some examples:
> a) Admin includes a student into a class. The class enrollment price
> should/can be written off the student account, or it doesn't make
> sense. If the class enrollment price is zero, then it isn't an issue.
Of course it doesn't make sense. If admin enrolls a student (if we
decide we allow it), he gets in free.
> b) Admin removes a student from the class. The enroll or tuition money
> should/can be refunded to the student unless this is a disciplinary
> action.
Interesting idea. It's possible that student should be auto-refunded in
that case, but creates
problems for us (once payments were made, we don't have those money in
our control).
>
> This suggests that we may need 'user account' support. It may be
> implemented as some extension of person_list table plus
> charges_history and payment_history or something similar.
>  It may make sense to allow a user select several things he wants to
> subscribe on (like a basket in online stores), then collect a single
> payment, and subscribe on the order things upon confirmation.
Could be done. I'd probably lean towards paypal model in this case
though - i.e. user does have an account,
and can have balance, but anything he obtains should be paid for
immediately (either through withdrowing
from existing balance, or by adding immediate payment to said balance
and withdrawing from it).
>
>     Students:
>     1. Anyone who passes class sign-up rules  becomes a student
>
>
> The idea of application is only applicable for the case, when someone
> may review that application and accept or decline it. The reasons may
> differ.. Like the class is too full, or someone has bad reputation, etc..
That is why we shall have moderation (i.e. forceful removal), but no
applications for admission.
>
>     > 4) How we are going to verify the payment? I suspect that payments
>     > should be processed by some online system. Do we have such
>     system in mind?
>     Yes. It's real-time credit card processing. Details outside of the
>     list,
>     if you really want them now.
>
>
> If you're going to call a subscription stored proc with the
> _confirmed_ payment amount - then I don't need details. I only think
> that we need to do it through several steps:
> a) The subscription is tested and reserved in the stored proc. The
> place in class is assigned but marked as 'unconfirmed' or just
> expired. The id in group and payment amount are returned
> b) The payment is processed (outside of my scope). If payment is
> unsuccessful the record created in a) is removed and the process
> interrupted.
> c) The subscription confirmation proc is called with the amount. The
> student is confirmed and his place in class is marked as 'confirmed'
> or expiration date is set properly.
Sounds good so far.
>
>     > 5) We need some structure to store the payment information. At the
>     > very least, it should include references to {person, object of
>     > payment}, date, amount, payment method, confirmation?
>     Yes. We might, however, store it in separate database, for security
>     reasons. I'm open
>     to suggestions on this one.
>
>
> The payment referrential integrity is really important. I'd prefer to
> keep all the payments in the same database, but limit the access to
> these data to db owner, special accountant role and special stored
> procs. Nobody but db owner and accountant would have select
> permissions on these data, and stored procs would be allow per-user
> access.
OK. I guess with our permissions system this should be safe enough. In
any case we will never
store actual CC info - just the amounts, and perhaps payment references.

-- 
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com