Re: UU Courses and classes

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

ACK.

Alexey Parshin wrote:
> So, as far as I understand, we agreed on:
>
> 1) Storing payments and idea of the balance. Still to be discussed:
> refunds.
>
> 2) Three-stage subscription.
>
> 3) No admission application.
>
> 4) Storing everything within one DB.
>
> If this is confirmed, I can start developing these things. However,
> more questions yet to come :)
>
> 2007/6/6, Ilya A. Volynets-Evenbakh < ilya@total-knowledge.com
> <mailto: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
>
>
>
>
> -- 
> Alexey Parshin,
> http://www.sptk.net 

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