Need to be able to enter recurring payments

Disappointed, and frankly feeling a little misled to learn that when you say we can accept recurring payments, you mean we can accept them only if:  the new member makes the contribution online, and if they either have or are willing to open a PayPal account as part of the process.  

We take most of our payments the old-fashioned way: asking people to become members in person, and having them fill out a membership card.  Organizers need to be able to enter recurring payments off of those cards when they get back to the office in order for this feature to be useful to us.  We're willing to pay the monthly PayPal fee for their recurring billing system, if that provides an easier API for you guys to hook into.  Or, we could go back to the Authorize.net/merchant account we were using prior to switching to PayPal to accomodate this system, if that's an easier API toolset to set this up without making members jump through account-opening hoops.

Official response from Jim Gilliam planned

Thanks for the feedback. The reason we implemented Paypal recurring payments first was because it was the payment provider that worked for the broadest number of customers. Most people don't have merchant accounts with Authorize.net so spending the time to integrate its ARB system wasn't going to help as many people as Paypal. We actually didn't even realize that people would need to have Paypal accounts until we really got into implementing it.

Your use case of signing up memberships offline is totally valid, we want to support it, and it is on the list of things to do. It sounds like supporting Authorize.net ARB is what would work best for you? The other alternative is to support Democracy Engine's new recurring billing system which doesn't require a merchant account like Authorize.net, but would still allow you to put in cards manually.

Twitter name change alters name in NB record!?

One of our most active members suddenly didn't come up in a search for her name today.  It turns out, we were able to find her record by searching her e-mail address, but her name had been changed in the system because she changed her name on Twitter.  Since people often use fake names, nicknames, and pseudonyms on twitter, a change on Twitter should NOT change the name fields in NationBuilder.  This would inevitably corrupt our voter file over time, and make it impossible for us to search for people by name.  Please fix this.  

When voter John Smith changes his name on Twitter to "J Dog", we will not only not be able to easily find his record, but we will look like idiots with our coalition partners if I start exporting data like that to the VAN.  

"Receive Text Messages" default

When I imported my contacts, the system appears to have checked the "Receive Text Messages" box for everyone with a mobile phone number by default.  I'd really rather it default the other way, so that we can let people opt in to text blasts, rather than make people opt out after we spam them.  Am I missing something?  Does that check box not mean what I think it means?  

Official response from Jesse Haff

If you create a "mobile opt in" column in the CSV you import with the value of "0" for everyone, and then map that field to mobile_opt_in, the receive text messages box will not be checked.

By default, people are imported as prospects unless you uncheck the box during the import process to make everyone a supporter. In NationBuilder, supporters should be people who have opted in via email, text messages or following you on Twitter whereas prospects have not (ie. voters, press, potential customers, anyone who hasn't said they want to be part of your nation). Prospects would not recieve a text message unless you specifically targeted prospects when creating a text blast, even with that box checked.