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!