Use-case A: Staff-driven financial activity
The staff decides how much a large group of people are going to pay( such as 500 people need to pay $1200 each for an annual "family" membership; or 50 kids are being registered for school, and the parents will pay off the tuition over the course of the school year).
The staff member does a search on this set of contacts, then chooses "Create Membership" from the batch actions select list. The next screen should ask for the membership type, and the current choices shown when creating a batch action membership. It should also create a financial obligation of $1200 for each contact. This could be a "pledge" of $1200. The staff member should also select which CiviContribute page should be used for the contacts to make their payments.
A similar batch action should be "Create Contribution" and "Create Pledge". The actions "Create Membership", "Create Contribution" and "Create Pledge" would not require credit card information, but simply create a pending obligation/pledge for each contact.
When the contact later logs onto the website, they should have the ability to 1) Pay the full amount 2) set up a schedule, such as monthly payments plus make their first payment, such as just $100 for that month, or 3) set up automated recurring payments. The automated payments would stop at the end of the year ( or whatever the last day of the membership is )
If someone falls behind in their membership-related payments, their membership status should be changed to "grace" until they pay what they owe, or the term of membership ends.
Ideally, the staff member is not responsible for picking the payment schedule. Ideally the member logs into the website, reviews how much they owe and then chooses a payment schedule, and whether or not to set up automated payments for that time-frame.
Pay as able:
Some people may choose "no schedule." Which means they will visit the organization website periodically, review their outstanding balance and make a payment against their obligations. In this situation the organization sends monthly statements ( I already have custom mail merge tokens that I use to create the statements) to remind people of their outstanding balance.
Use-case B: Contact-driven financial activity
A existing contact or a new contact visits the organization's website. They use a CiviContribute page that is configured for membership signups/renewals. They choose which membership type they want, then choose the schedule of how they want to pay their member dues. If they choose a year-long "family" membership for $1200 per year, they can choose to pay the full amount upfront, or break it into monthly payments, quarterly payments, or every 6 months. They could choose to fully automate the transactions or just get reminders to visit the website and make the payment manually for each transaction
The same contact may also signup for an event, and is bringing 3 guests. The event pricing may use pricesets or may be simple pricing. They may put an initial deposit, then pay the rest later. Or set up a payment schedule.
Pay as able:
Some people may choose "no schedule." Which means they will visit the organization website periodically, review their outstanding balance and make a payment against their obligations. In this situation the organization sends monthly statements to remind people of their outstanding balance.
Use Case C: An Automated payment fails
Someone chooses to do fully automated payments. The first 2 payments work correctly. However, the third payment fails due to the credit card being expired. In this case, the person should be able to visit the organization's website and make a manual payment or setup recurring payments again with a new credit card for the remainder of the of the membership term. It might be nice to have an option to set a standard charge for NSF checks and for declined payments of other sorts into the system.
Ideally payment options available to staff and public-facing forms offer the same choices/flexibility for pledges, events, and membership activities.