Re: UU Courses and classes

[Anatoly Volynets <av@total-knowledge.com>]

Ilya A. Volynets-Evenbakh wrote:
> 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.
>   

It is, probably, a matter of policies, partly--ours,  partly--classes'?

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

Again, in my view, it is a matter of policy, and any transactions must
be based on the tool set UU provides. By the way, one tool we can
implement is something like escrow accounts.

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

-- 

Anatoly Volynets, Co-Founder
total-knowledge.com
culturedialogue.org