Requesting the ability to incorporate the PayPal API as an Administrative Feature. 

Reason why:

We have many members who mail in an application and would like us to charge their credit cards.  While we can do that with PayPal, the transactions are not stored in our WA database.  We like the idea of an "all in one solution" and hopefully this request won't be too difficult to implement.

We frequently have members who order by phone or in person during an event and wish to pay by credit card. It isn't practical to have them go online during an event, especially if that event has already closed to registrations. On our previous meeting management platform, simply had them fill out a form with all necessary information, an administrator entered the transaction by the following morning, and  the data form was shredded as soon as the transaction was confirmed.

We DESPERATELY need a practical way to accomplish this in Wild Apricot. We have created a hidden event for the purpose, but the steps required to use it are awkward, convoluted, inconvenient, time-consuming, and prone to error:

1. As administrator, change the member's password to a temporary one for the purpose.
2. Make the artificial event visible and if necessary, add a registration item in the amount to be charged.
3. Log off, then log back on as the member, using the temporary PW. Navigate to the artificial event, register, pay with credit card, and log off.
4. Shred member's credit card information.
5. Log on as administrator, navigate to the event and hide it.
6. Notify the member, that it will be necessary for them to click Lost Password and create a new one next time they visit the website or register for an event.

SURELY, you can devise a better system that this!

Forgot to mention that you had previously suggested we manually add the attendee via the admin console and record it as a manual payment transaction. This does not solve the problem -- we are still left with no means of creating the transaction. Paypal's virtual terminal would solve the problem, except that it is way too expensive at an extra $30 per month for the needed 4-6 monthly transactions.

WA's difficulty with this issue seems to be the assumption that sensitive financial data would need to be stored somewhere and you do not want it stored on your servers, but there is no need for you to store credit card info once the transaction is entered and confirmed. Apparently, you do not store it on registrations made by members; there is no need to store it just because the registration was made by an administrator on a member's behalf. Indeed, if entered through Paypal, the transaction itself is not even made on WA. All we need is the access to the Paypal payment page -- the same page the member would use for a standard transaction.

Pstrom - we totally understand the need for this feature. And you are right - storage sensitivity is a separate point.

Let's see how other clients weigh in so that we can prioritize this.

For the benefit of others struggling with this problem, here is a workaround we just started using:

We added a page, titled “…,” which is normally hidden to all but administrators. I must make it visible, log on as a member to use it, then log back on as administrator to hide it again. This is actually a Donor page, which I have repurposed to allow me to enter credit card transactions for registrants without having to emulate them (thus avoiding the necessity of changing their password). It’s not quite as awkward a procedure as the previous one, but is still a pain in the butt. WA has not yet moved on creating a more practical way for an administrator to enter a credit card transaction on behalf of a third party who has provided the required card information.

Jim Sympathy added:

You can also keep this "donor" page visible at all times but only to a selected group of individuals:
- Create a new group and add the allowed members who should have access to this page
- Add a new restricted access section page and grant access to this group only.
- Make the "donor" page a sub-page of this restricted access section page.

Only logged members in that group will be able to see that page. (Will still be a pain, but at least you have now eliminated the need to show / hide the page each time).

I will make that change this weekend.

What's the latest on this issue. 

Have you thought about just adding a button to the Admin page that will send the admin user to the same page a user sees when they are filling out an application or event registration form?  You would need some code added to handle the navigation and know how to handle the payment data coming back from the portal the website uses, but seems like you could just piggy back off a system you already have.  Is this possible?

NOooooo! Really? I'm so surprised that others don't have this need as much as we do? Please reconsider?!

  ;(

Meagan

Meagan:

This is something that we know is important to our clients, and thus is also important to us. It's also part of an ever-growing list things that are important.

The Roadmap forum is now going to be used to host the Top 50 projects that we have assigned for the next 12 months, as well as those issues that are in the upcoming release (for example, version 3.4 which is scheduled for release in March 2010). It's also so that the roadmap doesn't become so large that things get lost in it.

We've moved this to the wishlist because while this is an important issue, we also want to make sure that we design it properly. We're still collecting feedback on it and examining what the best, easiest-to-use solution is. Once we have that we'll let you know so that we can make sure it works for you, and then put it back on the Roadmap with a set release date.

I've also made a note of your interest, and as you know that interest does help to move things up the queue!

I agree this is indeed a critical feature.

 Is there any way for the Wild Apricot team to go Agile and make releases more often?

Thank you.

Michael,

Thanks for your vote - it is appreciated and noted. 

Actually we do follow a version of Agile methodology. Funny thing, with shorter releases we would actually release features slower because of unavoidable overhead for testing and deployment. We used to do releases monthly, then gradually increased them to 8 weeks. 3.4 and 3.5 are a bit of anomaly because we are tackling some really big changes in system architecture and those can't be split into smaller Agile releases.

I've been assisting an organization that needed to add online credit card processing.  The web developer recommended Wild Apricot and the site was built upon it.  In Settings/Payment Settings there is an option: to support offline payments including credit cards.  We now learn that this does not mean that we can enter credit card transactions administratively.  Unfortunately, we have already built the site before learning that you cannot, in fact, enter credit card payments administratively through WA.  Hence, one of our main reasons for choosing the product has been significantly undermined.

 Your support personnel have recommended masquerading as a Contact on the website.  But when one gets to the credit card entry, the CVV code is required.  Of course we do not have that information for mailed in transactions and would certainly not ask our customers to provide us this "last line of defense" information.

So, we strongly encourage you to give priority to adding administrative entry of credit card payments.  I would vote on this and give it 5 stars (more if allowed), but I cannot find any place to cast my vote.

Your comment and vote are noted, thank you. 

This feature is needed.

 We have tons of people pay @ events, and the WA doesn't allow for onsite registrations.

 Would be great to have an admin choice for this.

Aaron 

Agree with Aaron; we have several events each year.  Many sign up for various activates as they arrive at the event.  onsite (at event) registration is needed; this would work well with the new accounting additions in version 4.0.

We want to eliminate off-line tracking and accounting for events and associated activities.

A big vote yes!

Correct.  Our association main annual event is being held in San Antonio, Texas September 14 – 19, 2010. This is our first major event scheduled with WA; the majority of our attendees have registered and paid online. We have several activities within the event; each listed and priced.

Historically, we will have 25-50 members that fail to register; or when arriving decide to attend additional activities.  Therefore when they pay they are added to the various lists.

We would like to be able to register any given member or upgrade them using WA onsite; our event planner would do that for them in WA.

Not knowing the “details” of the new financial package: I have not found a way to process their credit card payments; manual payments appear to work.

Hope I answered your question.

Thanks Mike.

Re new financial package - unfortunately the overhaul in version 4.0 does not address this aspect at all (admin processing of credit card charges), though it does makes it easier for us to enable it in the future.