CiviCRM Community Forums (archive)

I just added eWay (thanx to peter from dolphin software) to the 2.1 code base. not sure if that will meet your needs.

1. Yes, can you please update and post it on the CiviCRM wiki

2. you should put it in packages/PaymentExpress. I'd use require_once instead of include

3. We've generalized a fair amount of the ipn code in CRM/Core/Payment/BaseIPN.php. CRM/Core/Payment/PayPalIPN.php inherits from this class. I suspect you can use smething similar for DPS

lobo
 

Quick question - has the payment processor code changed in 2.1 (apart from including eWay)?

I'm going to start making some notes here on setting up a payment processor in the hope they will be corrected and something worth posting on the wiki will result

Step 1 as I understand it is to add the processor to the table `civicrm_payment_processor_type`
I believe this replaces the first two steps listed here: http://www.idealso.com/civicrm/AUTHORIZENET_NOTES

Fields are:

ID   - unique ID
DomainID - generally 1
Name - this name needs to be used as the name for the various php files as well.
Description (optional field)
Isactive  - boolean
Isdefault - boolean
user_name_label - this is what the username field is described as in the configure payment instruments screen
password_label - likewise
signature_label
class_name - name of class (in code) should be Payment_xxx where xxx is the same as the name field
various selfexplanatory url fields & then
BillingID - number from 1-4 - this is the important one - will add more later
Isrecurr - boolean

The BillingID will determine the process followed. ID types are:
1 = form
2 = button
4 = notify

1) For forms civicrm/CRM/Core/Payment/form.php is added to the form displayed by (in events mode) civicrm/CRM/Event/Form/Registration/register.php

This form collects the credit card data on the civicrm site. Communication takes place between the civicrm server and the processor - i.e. the civicrm server sends a request (encrypted) including the credit card and it gets approved or otherwise.

The function called by this billing mode is

doDirectPayment() - 

2) button - a button is added. Curiously although 2 is defined as button in the payment.php script no processors in the processor_type table use type 2 and payment express uses type 3 which seems to have the button functionality. This method seems fairly hard coded to paypal e.g.

the function called by this billing mode is

setExpressCheckout

The customer is returned to confirm.php with the rfp value set to 1 and

getExpressCheckoutDetails

is called

when the form is processed

doExpressCheckout is called to finalise the payment - a result is returned to the civiCRM site.

4) Notify - in this case the customer is redirected from the confirm page to the payment processor. The result is returned separately to the customer (as a post from the payment processor)

The processor I am setting up I believe to be a better fit with this method as the result is returned as a POST separately from the customer i.e. returnurl?result=encryptedHex. The customer is returned to the same url so the URL must be able to cope with both the post from the customer and the encrypted hex. The customer needs to be redirected to the thank you page whereas the processor just needs an 'OK' reply.

 (there are two different ways to decrypt the hex pxaccess & pxpay - one using an installed lmcrypt module and the other involves interacting with the processor but these are handled by code provided by the processor and don't pose a difficulty).

The function called is

doTransferCheckout

I now need to figure out:
- how to test the return post for whether it is the user or not.
- If the reply is not from the user it needs to use variables passed back from the processor to the IPN script so it can figure out what payment it relates to & confirm it.

I believe the function for a success is
   function completeTransaction( &$input, &$ids, &$objects, &$transaction, $recur = false )
( I may need to call the validate one first)


Objects includes
        $contribution =& $objects['contribution'];
        $membership   =& $objects['membership']  ;
        $participant  =& $objects['participant'] ;
        $event        =& $objects['event']       ;

$input variables from GoogleIPN.php:

       $input['amount']     = $contribution->total_amount;
        $input['fee_amount'] = null;
        $input['net_amount'] = null;
        $input['trxn_id']    = $orderNo;
        $input['is_test']    = $contribution->is_test;

NB - GoogleIPN seems to check whether the contribution has already been confirmed - I expected to find this in the BaseIPN

but I still need to investigate further what else to pass through

Work in progress

Hi there,

Yep, will try to when the kids are in bed. I am 90% there. It works but I have to do some more testing.

i assume DPS is the same as paymentexpress that eileen is working on? Since the 4 of us are in NZ, might be easier to coordinate and figure out how to get the PP's working and into the 2.1 codebase. I'm on IRC if you'll need help or assistance

Would be good to create a manual for "how to write a payment processor" for civi 2.x

lobo

Good morning, all.

First, yes, Donald, DPS and Payment Express are one and the same. 

Second, Eileen, I am using PxPay and have had success right up to the point where the payment processor redirects back to the server.  I also started with the Google script, but have modified it somewhat (adding in a few functions to build the XML string I need to pass to the server in order to generate a request, etc.). I initially met challenges with the DPS/Payment Express server since they won't allow anything except absolute URLs to be passed to the server in the successURL and failURL XML elements, so I added a couple of rewrite rules to the server and modified the URLs I was passing so that they didn't contain any "?" or "&" characters.

I am now able to complete a transaction with the payment processor.  However, upon redirect back to the server, I am always landing back on the initial contribution form, with all of my information prepopulated (which means it is obviously retrieving the qfKey, but that my Apache rewrite rules aren't working properly because of the rather lengthy string being attached to the end of the URL from the DPS/Payment Express server (which contains the encrypted transaction results)).

So, as I mentioned in my previous post, I am left with the option of adding in a new script outside the current module to parse the incoming URL and then redirect it manually to the correct page.  It's not ideal, as I would like to have the solution integrate completely, but it doesn't seem to be working.  Even adding rewrite rules to the server isn't ideal, but it does get me to the goal of having a working module that much quicker (I'm working under a deadline at the moment.  ).  But, adding rewrite rules isn't an option for everyone who could use this module.  Ultimately, I want the module to tie into CiviCRM without requiring any "tweaking" on the server or extra scripts, but, at the moment, DPS/Payment Express has some pretty stringent requirements which make that a tad difficult to achieve.

I, too, am on Skype most days - lucasbaker. 

Happy to hear any thoughts anyone might have about this.  I am pretty close to rigging up a solution that works, but, before calling this a "working" module, I'd like to tie up all the loose ends.

Regards,
Lucas

lucas:

check: CRM/Contribute/Form/ContributionBase.php, line 264

there is a hack for paypal there (CRM/Core/Payment.php, function paypalRedirect). Since paypal in some cases does not send us back the return url but makes its own url!

will adding a similar hack for DPS work? If so, we can make this hack a virtual function for each payment processor and allow the payment processor code to decide if we need to redirect to the thankyou page

lobo

Am at our business now so not on skype or on the computer with my stuff on it but I passed a few variables through paymentexpress back to myself in the encrypted code.

I think I set dpsref1 to something like
a=contactID,b=contributionID,c=contributionTypeID,d=eventID,e=particpantID
(the variable names were originally longer but they made the URL too long).
dpsref2 was the qfkey

In my PaymentExpressIPN file I extracted these from the hex file (along with InvoiceID,& used functions based on the googleIPN file main() and newOrderNotify() to re-construct the order details from the hex file. My code does go as far as confirming the order within CRM and triggering the e-mail - I just haven't constructed the correct url to re-direct the user's browser to the thank you page yet

I can access that mibbit from here http://embed.mibbit.com/?server=irc.freenode.net&channel=%23civicrm&forcePrompt=true

I'm not sure how different the process is for pxpay though