Support

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.