Custom Paypal-like Processor?

[lentilsoup]

Hi folks,

I need to implement payment processing for a wacky little payment processor my client uses.  From what I can tell on this page, it uses the "notify" method.  Basically, the user clicks the "checkout" button, submitting a POST request to the processor's site, where they fill out the billing form.

I'm concerned about two things:

1) I'm completely lost in the CiviCRM code.  I'm not clear what methods need to be implemented (doTransferCheckout()?  What about handling the processor's response?) and when they're called, what the supplied parameters are and represent, and what values need to be returned in what cases.  I've looked through the PayPal code, but since I'm not that familiar with PayPal either, it hasn't exactly enlightened me. 

2) Instead of sending the user back to the initial site via a POST or GET request upon completion, the processor sends the request itself and essentially screenscrapes the result, presenting it back under its own domain name (meaning that a) session variables are unavailable, and b) any non-absolute links die an excruciatingly messy death).  I have no idea what, if any, implications this has for CiviCRM.

Does anyone have any suggestions as to where to start with (1), or whether (2) will be a problem?  Any pointers would be much appreciated.

Thanks!

[Donald Lobo]

1. For your payment processor, you will need to implement doTransferCheckout. The return case is handled by PayPalIPN.php (and GoogleIPN.php). You basically need to translate what they return into values that CiviCRM needs to store in its DB

2. I'm not sure i understand what u mean by "essentially screenscrapes the result, presenting it back under its own domain name".

lobo

[lentilsoup]

Thank you!

2. I'm not sure i understand what u mean by "essentially screenscrapes the result, presenting it back under its own domain name".

Instead of directing the user to send a request to our site upon completion, it sends the request itself (cURL or equivalent), and presents the resulting HTML to the user.  Does that make any sense?

[Donald Lobo]

Does it do a POST or GET request back to the server with the details? If it does not, it might not fit the notify model very well. how does it expect the calling server to figure out if the transaction was completed?

lobo

[lentilsoup]

Yes, it will send a POST request if the destination URL is clearly a script, or a GET (I think without the data) if not -- I have to assume the decision is made based on file extensions (does CiviCRM use a rewritten URL?). 

It just obviously won't have any session cookies that the user would, and may suppress HTTP redirects, which is what my concern would be (that and any relative links on the page -- hopefully I can work around that in templating).

[Donald Lobo]

the callback from the server not having a session cookie etc is totally fine. We try to match quite a few fields from the db to the POST request and also the invoice id to ensure that we modify the right records

lobo

[lentilsoup]

It can pass fields through.  Are there any in particular that I need to be aware of?

[Donald Lobo]

check:

CRM/Core/Payment/PayPalIPN.php

in specific, check calls to the function self::retrieve, we basically get all that information from paypal (google follows a similar pattern). Its a fair amount of information, but lets us do quite a few checks and gives us all the needed ids

lobo

[lentilsoup]

Thanks -- That helps a lot.

I've just run into another problem trying to set up the payment processor in the CiviCRM admin screens:  When I enter "https://pay.DOMAIN.com/payment/pay.cgi" (no quotes of course) for the API URL and Button URL values, I'm getting a validation error telling me to enter valid URLs for those fields. 

Am I doing something dumb?  Does it just not like the .cgi extension?  (I've tried replacing "https" with "http" too.)

Never mind.  Really dumb mistake leaving a spurious space at the end of the value.

[lentilsoup]

OK, ran into another obstacle... Does the new payment processor code have to live in Core/Payment instead of [Contrib dir]/Contribute/Payment?  When I put it in the latter, I get errors such as the following:

Fatal error: require_once() [function.require]: Failed opening required 'CRM/Array/.php' (include_path='[DOCROOT]/sites/all/themes/mccarton/civicrm_custom:.:/home/mcf1/public_html/mccarton.staging.triopter.com/sites/all/modules/civicrm:/home/mcf1/public_html/mccarton.staging.triopter.com/sites/all/modules/civicrm/packages:.:/usr/lib/php:/usr/local/lib/php') in [DOCROOT]/sites/all/modules/civicrm/CRM/Core/Payment.php on line 74

AFAICT, this code is passing the incoming third parameter as the second parameter, resulting in the second call to the function receiving an array where it expects a string:

Code: [Select]

static function &singleton( $mode = 'test', $component, &$paymentProcessor ) {
        ...
            self::$_singleton = eval( 'return ' . $paymentClass . '::singleton( $mode, $paymentProcessor );' );
        ...
    }

Is that a bug, or is that behavior required for other functionality?

(Or am I doing something dumb again?)

Thanks!

-----------

EDIT: Got this one figured out too.  I need files in two places, mirroring what PayPal does in the core module. 

[Eileen]

Cool - perhaps you can edit the wiki entry to make it clearer once you have finished it

[lentilsoup]

If I can make any sense of what I'm doing, I will.  ;-)

Next thing that's confusing me... Do I have to create my own IPN script along the lines of extern/ipn.php or extern/pxIPN.php?

Thanks again for all your help -- I can't tell you how much I appreciate it!

[Donald Lobo]

yes you do, since different processors respond differently. We tried to put a lot of the same functionality in BaseIPN.php, so maybe you can try to do something similar

lobo

[lentilsoup]

OK, I just tried putting my IPN script under my contrib directory (trying to keep my files out of the module directory), but apparently that's not working -- it's having trouble loading civicrm.config.php.

Is the separate contrib dir just simply not designed to work for some things?

-------

EDIT: Needed to edit a whole bunch of paths.  This sure is an adventure...

[Eileen]

these are relative paths - if you move the file you'll need to review the path

require_once '../civicrm.config.php';
require_once 'CRM/Core/Config.php';