CiviCRM Community Forums (archive)

Sagepay (was Protx) has various options, one of which is their forms protocol. Some info here:
http://www.sagepay.com/developers/integration_manual/form_introduction.asp

Since I can't find anyone who has written one of these before (I did find some Sagepay Direct code, but that's not what I need and didn't appear to work), I'm (foolishly) plunging in to try myself.

I've read the advice here:
http://wiki.civicrm.org/confluence/display/CRMDOC/Creating+Additional+Payment+Processor+Plugins
Which is helpful but only gets me so far. Please bear with me on this - this is the first thing I've ever tried to code in PHP.

I've started my code, but currently have a couple of questions:
1. Sagepay requries that "The final confirmation page on your web site should contain an HTML FORM with the Action set to the Sage Pay Form submission URL and the following 4 hidden fields as part of that Form." How can I add hidden fields to the relevant pages (in Contribute and Event, presumably) - I know generally how to code hidden fields, but which pages am I adding this to and how?

2. Sagepay then do their stuff and "The system will append to the SuccessURL or FailureURL a field called CRYPT, [sets out format of the return URL ? fields].  The SuccessURL and FailureURL field should point to scripts on your server that extract the information in the crypt field and use it to update your database (if you have one) and/or format an appropriate response page for the customer."
Obviously I can create a script for these to point back to, and I think I know how to get the script to pull the required information out of those fields, but how does the script "tell" CiviCRM that the transaction was a success/failure and what page do they forward them to (i.e. the equivalent of the thank you page when you use the "pay later" option?)

Re point 1 - I have a feeling from a quick look that the Forms integration is not the way to go and that server integration is.

This is more the sort of thing I'd be wanting to work from if I was coding it.

http://www.sagepay.com/developers/integration_manual/server_protocol.asp

Thanks for your various replies. I have to admit that because we use Sagepay Forms with our current online system I assumed we had to use them again. I'll check with our treasurer though, what our account with Sagepay is as it may be that we can use whichever variant we like. Note, though, that we cannot take payments or credit card details on our own site (shared hosting, shared SSL etc) which I think the server protocol requires.

Hi

Have you got any further with this?

We may be able to help and conrtibute back as we need to create an interface with ProtX for a client we're working with.

Thanks

Parvez

ok, I've started the process and will be getting the integration to work with the server version of Sage Pay. Will update this post when done, have got the PHP kit downloaded and am in the process of using the Paypal integration as a basis for the server integration.

Final update for the day!

Decided not to use the Sage Pay transaction ref at this point i.e. on handshake I will not be updating the contribution record yet. I may do this as an enhancement later down the line but seeing as the invoice id is unique anyway I'll use this instead.

So, I have the contribution page carrying out the handshake to Sage Pay.
CiviCRM redirecting the client to the Sage Pay pages
Sage pay completing and requesting an update to the contribution much like the Paypal IPN code

This is where there is a difference. Sage Pay is expecting the processing to respond back to Sage Pay with some information i.e. the Status, RedirectURL, StatusDetail. Its only when Sage Pay gets this info does it actually redirect back to CiviCRM. So, anyone know how to do this in CiviCRM?

The example PHP code they supply does this (after checking and updating all the relevant tables in their example)

ob_flush();
header("Content-type: text/plain");
echo "Status=INVALID" . $eoln;

/** Only use the Internal FQDN value during development.  In LIVE systems, always use the actual FQDN **/
if ($strConnectTo=="LIVE")
echo "RedirectURL=" . $strYourSiteFQDN . $strVirtualDir . "/orderFailed.php?reasonCode=002" . $eoln;
else
echo "RedirectURL=" . $strYourSiteInternalFQDN . $strVirtualDir . "/orderFailed.php?reasonCode=002" . $eoln;

echo "StatusDetail=Cannot match the MD5 Hash. Order might be tampered with." . $eoln;
exit();

Any help would be appreciated!

Hi Lobo

How are you? Good to hear from you!

1. CiviCRM sends a GET request to sage with Huh information. Sage responds with a URL and a unique transaction ID
Not quite. I've got CiviCRM posting out to Sage Pay. Sage Pay returns a MD5'd string which is the handshake security key.

2. I would store the transaction ID in civicrm_contribution as trxn_id
I'm stoing the resultant transaction ID into this field, not the security key.

3. CiviCRM redirects to SAGE to the above URL.
Yes.

4. When Sage is done, its calls a CiviCRM URL (put this in the bin/SagePayInterface.php directory). The question is what info does SagePay call you with, can this URL be dynamic. For paypal we construct a dynamic URL and send it over.
Have done this. Yes, the URL is dynamic and contains information that was sent out in step 1, effectively the notify URL. Its also at this point that the status of the transaction is exposed to Civi in the call. I've got it so that Civi is updating the relevant details, as it does with Paypal.

5. How does Civi know about status/status detail? seems like sage pay does the processing and should know it?
See above.

This is the stage that I've got to. Sage Pay expects some information presented back from its post to CiviCRM with the results of the transaction, effectively to let it know that we received the information ok and where to go next.

This is the point that I'm stuck at - does Paypal also do this?

Thanks

P.S - I dont have an IRC client at the moment.

Hi, I think the PaymentExpress code might be a bit more generic - I based it on the paypal code but there were some paypal specific things in there so you may find it a more helpful base