Author Topic: Cash or Bank-Transfer Payment Processor (for Events) (Read 1913 times)

web_services · September 03, 2014, 05:04:57 am

Dear forum members,

I have recognized the many payment processors available for civicrm, however I am missing one that enables processing depending on Price Field or Price Set, e.g. a seminar may be registered/purchased advanced via paypal or credit card payment, but also may be payed at the venue in cash, but advanced registration is necessary for this... other option could be to just bypass the advanced payment ti be just registered.

Did I miss something or is this an advanced feature to be requested?

joanne · September 03, 2014, 06:24:31 am

I am not quite sure what you mean by "enables processing depending on Price Field or Price Set".

Does selecting Enable Pay Later option? on the Fees page when you are configuring your event give the flexibility you want?

web_services · September 03, 2014, 08:46:53 am

Hello Joanne,

Ok, in fees one may enable a pay later option and enter instructions, however this is not part of the workflow.

E.g. You have price a (advanced payment / credit card price) and price b (cash at event), price a and b are different fee labels and amounts, when you are going to register you will have the two amounts behind the "fee label" and the "two "payment methods" further down, whereas payment method "cash" is not acceptable for price a and payment method "paypal" not accceptable for the price b. So I am looking for a way to join together a price with the associated payment method. Cash at venue can not be routed to paypal.

Hope you get my concern now.

Thank you!

joanne · September 03, 2014, 04:23:26 pm

That explanation makes things much clearer.

You can't do what you want directly through CiviCRM.

I am a non-coder with very little money to pay for a consultant, so my solution would be to set up two events that are identical except for the fees section. One would be set up to take payment only by Credit card and the other only to take a pay later payment that would be Cash on the day. I would set up one event info page in my CMS with links to each registration page (skipping the Civi event info pages). If you have a maximum capacity for the event you might have to juggle things a bit to make sure you don't end up with too many registrations. However, this method would have the added advantage of letting you set a maximum number of "Pay on the day" participants so that your don't end up with an unmanageable situation at the venue.

I suspect that the coding solution is: "Display both fee levels on the page then use jquery to hide both payments methods to start with and reveal the appropriate payment method once the person has chosen a fee level." However, someone who is a coder will need to confirm or correct that suggestion.

Michael McAndrew · September 04, 2014, 12:58:00 am

Hey there,

Yes - as Joanne says, if you were able to learn a little bit of jQuery, and how to insert that into your event registration page, you could always add a price field set field for the difference that is due when paying by cash, and have it linked to the pay later option so that when someone checks pay later, it also checks the price set field.

Else the other option seems like a good work around.

Eileen · September 04, 2014, 03:30:07 pm

As an aside - I have been thinking for a while that having a cash / manual processor may make more sense than a pay later option. I think it would simplify the code and allow things like recurring

web_services · September 09, 2014, 01:08:24 am

Hallo Eileen!

That was my first thought also, so I started to look for this "manual processor" before i have posted my request.... I just want to encourage you to go this way! Thank you for your reply.

B ert

robbrandt · November 19, 2014, 05:33:09 pm

We just had this come up as well. I am thinking that maybe labeling the Dummy payment processor as "Cash" would do the job?

Eileen · November 19, 2014, 05:34:56 pm

In 4.6 I've done a bit of restructuring on the payment processors & was very tempted to create a manual payment class just for pay later as a place to pull together the various scattered bits of logic.

robbrandt · November 19, 2014, 05:44:06 pm

Interesting... Unrelated but speaking of payment processors the FirstData/Linkpoint processor uses an API that's being deprecated. I think we've got some time, but if you are working on a new processor class, implementing the new API might be a good one to work with.

Eileen · November 19, 2014, 05:47:51 pm

First data is an option for the omnipay treatment from the looks - https://github.com/thephpleague/omnipay (but no that doesn't mean I'll jump in & do it unfunded)

CiviCRM Community Forums (archive)

News:

Author Topic: Cash or Bank-Transfer Payment Processor (for Events) (Read 1913 times)

web_services

Cash or Bank-Transfer Payment Processor (for Events)

joanne

Re: Cash or Bank-Transfer Payment Processor (for Events)

web_services

Re: Cash or Bank-Transfer Payment Processor (for Events)

joanne

Re: Cash or Bank-Transfer Payment Processor (for Events)

Michael McAndrew

Re: Cash or Bank-Transfer Payment Processor (for Events)

Eileen

Re: Cash or Bank-Transfer Payment Processor (for Events)

web_services

Re: Cash or Bank-Transfer Payment Processor (for Events)

robbrandt

Re: Cash or Bank-Transfer Payment Processor (for Events)

Eileen

Re: Cash or Bank-Transfer Payment Processor (for Events)

robbrandt

Re: Cash or Bank-Transfer Payment Processor (for Events)

Eileen

Re: Cash or Bank-Transfer Payment Processor (for Events)