SWIPE payment processor prevents other pp from being available about com.iatspayments.civicrm HOT 11 CLOSED

You need to disable SWIPE if you no longer want all staff to use it for +Submit Credit Card contributions. I think that got changed in the readme file. Will edit it.

from com.iatspayments.civicrm.

I would like staff to continue to use the swipe payment processor, I just do not went them locked out of all other options. The current behavior makes it unusable in a production environment.

from com.iatspayments.civicrm.

Actually this is a feature. Imagine a fundraising event where you want administrative staff and volunteers (for security reasons) to use encrypted SWIPE straight into a specific iATS subaccount that you have set up for this event for ease of reconciling the monies. You don't want to give staff the option to use any other methods (and thus any other iATS subaccounts) - it is not their decision to make. A CiviCRM Administrator (with permissions to enable the SWIPE) has decided by enabling and setting SWIPE to default that this is how these cards present are to be processed during the event. Bypassing any potential key stroke monitor malware. The public outside of the fundraising event can continue to make Contributions online. The regular Credit Card processor is still available on public pages.

What use case are you thinking of?

from com.iatspayments.civicrm.

Sarah: you're correct, SWIPE will take over regardless of whether it's the default or not. In addition, this functionality isn't setup for backend credit card submissions for events or memberships, so I'll fix all this in a release later today.

from com.iatspayments.civicrm.

The use case I am thinking of is there is an off-premise event where staff is checking attendees in at the door, including swiping credit cards as needed. At the same time, its business as usual in the main office. So the employees in the main office should not be locked out of other payment processors. Even the default being different depending on the day would confuse employees in the main office. (ie Its Tuesday, so the default is different )

I understand the need to prevent mistakes, but there are already MANY ways the staff handling event swipes can make mistakes: Such as choosing the wrong event, wrong fee level, wrong contact, wrong financial type, .... Perhaps you could restrict access to various payment processors using roles/permissions.

I was thinking maybe you could hook in the swipe functionality into the CiviMobile extension. Those screens for checking people into an even are fool-proof and streamlined.

from com.iatspayments.civicrm.

Sarah: I think your use cases can work with the existing design (once it's fixed). You can just leave the swipe processor not as the default, and then use it, or not, as you choose. It should be working on both front and back end forms once I'm done today.

from com.iatspayments.civicrm.

If you're able to test master tonight, it's got all the latest fixes. I'll push out a new release tomorrow.

They key issue with backend credit card payment forms is that they don't refresh when you change payment processors. So until we fix that, you can only have swipe on all backend payment forms, or none. In the meantime, you can use a solution similar to the ACH/EFT one - i.e. you can switch on 'front end' type forms, so i you want to enable swipe without it taking over all backend forms, you can just enable it for a 'front end' form.

from com.iatspayments.civicrm.

I updated the extension to version 1.2.11 and the fix is working: That is if the SWIPE payment processor is not the default, then I can use the other payment processors as expected in the back-office( but I am prevented from using SWIPE at all). If the SWIPE is the default, then it takes over as before.

It seems for end-users to make use of SWIPE, I must make it the default pp, which has the unfortunate side-affect of hiding all other pp in the back office. This is a significant usability issue for the use cases I am familiar with. ( ie what I described above with the off-site event happening in parallel to business as usual in the head office)

Since the main roadblock is the limitation in CiviCRM core ( on the "new Contribution(Credit Card)" screen not refreshing the billing block when the user changes the pp choice; do you have any plans or timeline to addressing that roadblock in CiviCRM core? (Fixing that issue in core would help with SWIPE AND ACH in the back-office) Or building onto the OmniPay extension for CiviCRM?

from com.iatspayments.civicrm.

1. The fixes to civicrm core to allow swipe to share the backend credit card contribution forms - I haven't looked at that, and am a little scared to. But I've got some other fixes to do to those forms, so I'll have a look and see if it's not too hard.
2. Your paragraph 2 is not true: the work around that exists now is similar to the ACH/EFT work around - i.e. don't set swipe to the default, but use it on a front-end form, where it can be the only option, or happily share the stage with other payment processors. I think using swipe on a front end form is actually a better choice than using it on an admin screen if you're at an off-site event (for security reasons).

from com.iatspayments.civicrm.

1. Whatever you can figure out would be appreciated. It seems like the back-end core code for screens that use payment processors is very brittle and makes too many assumptions. It seems like the work-around of expecting a back-office user to use a front-end form is becoming the standard for the iATS extension.

2. You are right, I was not thinking about forcing the back-office user to a front-end form as a work-around. Based on your explanation, my only realistic option for my use-cases is to NOT set the SWIPE payment processor as the default; only use it on front-end forms.

from com.iatspayments.civicrm.

Closing this: iATS Swipe is working with 4.4.x and 4.5.x in backend as well as on public contributions pages (Donations, Donations-recurring, Membership, Events) [see the README.md file: a patch is needed to make iATS Swipe work on public pages].

from com.iatspayments.civicrm.