The user will receive the product immediately. What the customer is paying for is a service (online class) that they can complete as quickly or slowly as they want. So, the service or class will start immediately but we will have control over what they receive in terms of that service. We are thinking about limiting how much they will be able to complete until they are paid in full. Fortunately, we have final control because even if they complete the course, they will not receive a certificate of completion until they are paid in full. I suppose the answer to your question then is that they will not receive the product until paid in full. They will be able to work on the class, but without the proof that they completed the class, that will mean nothing to anyone else.

We'll say they don't receive the product until after payment is made in full (unless of course someone sees this differently than I do).

My initial thought is that this might be a good time for someone to bite the bullet and write a recurring fee handler for PayPal. There's already a structure in place to receive IPNs, so it might have to be developed as a patch to the PayPal module itself... but the idea would be setup a recurring fee that spreads the payments out over three months or something. As payments come in, they will be entered on the order by the IPN... once the balance reaches $0 you can move the orders to the Completed status or something. You can setup the recurring fee feature to only work on one option... i.e. the product could have a "Payment type" attribute. The default option is pay in full, but the second option could be pay in 4 installments w/ an appropriate adjusted SKU, drop the price to 25%, and have a recurring fee feature attached to its adjusted SKU that is 25% of the price set to be billed 3 times, once a month, starting in a month. (oof... confusing sentence... if it wasn't so late, I'd retool that.)

After doing some research into this, I don't believe this is what we want. The main reason being that the recurring fee handling in Paypal allows a user to cancel at any time. However, the module that we are looking to develop will be more of a payment plan that we will charge them 3 times in a month. After thinking about your questions some more, I have come to the conclusion that the product is received before full payment is completed. Thus, we don't want the user to be able to cancel payments in the middle of the billing process. This isn't a subscription. They either buy the course or they don't. We just want to give them the option of making payments on the course over a certain period (as I write this it seems like we are extending credit in a sense and we are using Paypal to collect the money, whereas we are just holding on to the balance owed). Anyways, any other thoughts that you might have would be great.

The version packaged w/ the 1.0 release should be the latest.

It's included in the 1.0 release... maybe you just didn't unzip it at the time?

http://drupal.org/project/ubercart

What about a Feature as Ryan suggested for "Payment type: Full" and "Payment type: Partial" with an extra option to allow for cancellation? I can see where this would be a good option to have, such as in the cases of online courses where you can't cancel. Checking this option box would allow for an additional message upon product completion (or in the product description itself) saying that "The recurring fee cannot be canceled and you will be billed the full amount after x duration."

This could even work for subscription products that need such an option. Perhaps then the meseage would be customizable to be more descriptive, e.g. "You cannot cancel this subscription through the account interface; you must email us." I don't think that's the best way to go about subscriptions, of course, but I think the issue still remains that this option would need to be in place for certain products, such as courses. Instead of breaking it out into two modules, keeping everything rolled into one is probably the best bet.

My two cents, anyway.

I'm doing a lot of this already w/ uc_recurring, the difference being "payment plan" isn't a valid payment method. However, you should be able to use a lot of the code related to storing payment info, processing payments, and restricting which payment methods are good for payment plans.

The main snag is PCI compliance. Once you've authorized a card, you're not supposed to store the CVV to be fully compliant. From what I understand, a lot of service agreements require such compliance. There are workarounds, like Authorize.Net's CIM for CC payments, tho.

I would try to not rely on PayPal going forward, their service can be spotty (although I haven't seen any issues lately). Their signup form should have a "Buyer Beware" clause..

And yeah I would say for future PCI compliance, the Authorize.net CIM is your best bet. I'm hoping to integrate this in the near future once we get subscriptions going.