40 replies to this topic

[tigergirl]

Hi,
thanks for the new module.

I'm testing but have a few issues:

1) no sage payment notification email arrives for vendor (customer receives though, order emails ok)
2) what is the Sage Pay Reference ID in admin and order confirmation email? It appears to have nothing to do with any info I can find on my sage test admin account = useless if a customer quotes it to me. It looks encrypted?
3) I see references to order id - but this doesn't appear anywhere in the sage system.
4) The sage pay ref id looks odd, all with -12- at the end, no vendor name - is that correct?
5) the readme pdf makes reference to:

Quote

Additional Changes for Existing osCommerce Online Merchant v2.2 Milestone 2 Store Owners
The following core source code changes must also be performed for osCommerce Online Merchant v2.2 Milestone 2 installations:
http://github.com/osCommerce/oscommerce2/c...7345cc91145862a
This change has been made as a bugfix for osCommerce Online Merchant v2.2 Release Candidate 1 (released 4th July 2007).

Please can you state specifically which osc versions this fix needs to be applied to?

Look forward to your replies.
Thanks

[John_SagePay]

Hi,

Could you message me your vendorname and I will check your account at point 1.

Many thanks,

John.

[Harald Ponce de Leon]

Hi..

tigergirl said:

2) what is the Sage Pay Reference ID in admin and order confirmation email? It appears to have nothing to do with any info I can find on my sage test admin account = useless if a customer quotes it to me. It looks encrypted?

The Sage Pay Reference ID is a unique code on the Sage Pay payment system used to reference the transaction.

tigergirl said:

Please can you state specifically which osc versions this fix needs to be applied to?

That fix is needed for osCommerce Online Merchant v2.2 Milestone 2 installations. This fix can be verified by viewing the checkout_process.php file and if you see this:

// load the before_process function from the payment modules
  $payment_modules->before_process();

  require(DIR_WS_CLASSES . 'order_total.php');
  $order_total_modules = new order_total;

  $order_totals = $order_total_modules->process();

it needs to be changed to this:

  require(DIR_WS_CLASSES . 'order_total.php');
  $order_total_modules = new order_total;

  $order_totals = $order_total_modules->process();

// load the before_process function from the payment modules
  $payment_modules->before_process();

Kind regards,

[Harald Ponce de Leon]

It would be great if you could report which osCommerce Online Merchant version you are running. This can be found at the following page:

Administration Tool -> Tools -> Server Info

The osCommerce logo and version should be shown on that page.

Kind regards,

[tigergirl]

Hi, thanks for your responses.

Quote

The Sage Pay Reference ID is a unique code on the Sage Pay payment system used to reference the transaction.

The sage reference is coming through like this in osc and order email although I changed a few digits here:
Sage Pay Reference ID: {4F6GHH98-3ABC-63DR-12D8-3668OPU98E89}

....and that is not what shows in sage admin or sage email as the unique transaction reference, the above looks encrypted and it bears no relevance to me or my customer. If my customer quotes that to me it means nothing. So that refernce needs to be displayed correctly or stripped out of the module IMO.

I beleive I am on osc V2.2 MS2 060817. I can not check Administration Tool -> Tools -> Server Info as I removed that link & file due to potential security risk.

I do have the code you mention - I use Paypal IPN V1.4 and am confused as the link http://github.com/osCommerce/oscommerce2/c...7345cc91145862a mentions something like

Quote

this will break paypal ipn

. Will I break paypal IPN if I apply the fix? I need to run both sage form and paypal ipn - don't want to break anything...

John is looking into the email issue.

Is there no way to log the order in admin before payment for sage form? I have problems with the old module not logging orders occassionally which creates a real mess sometimes and isn't good from a customer point of view = some pay twice. The main reason I was looking for an improved version of form.

Thanks for your help.

[rlangton]

Quote

The sage reference is coming through like this in osc and order email although I changed a few digits here:
Sage Pay Reference ID: {4F6GHH98-3ABC-63DR-12D8-3668OPU98E89}

....and that is not what shows in sage admin or sage email as the unique transaction reference, the above looks encrypted and it bears no relevance to me or my customer. If my customer quotes that to me it means nothing. So that refernce needs to be displayed correctly or stripped out of the module IMO.

That reference is the VPS Transaction ID, you can search for a transaction using that reference in My Sage Pay. (although i don't think it actually shows on the transaction detail page)

[tigergirl]

rlangton, on Sep 4 2009, 03:41 PM, said:

That reference is the VPS Transaction ID, you can search for a transaction using that reference in My Sage Pay. (although i don't think it actually shows on the transaction detail page)

I do apologise - you are perfectly correct on both points. My point then should be - it would be better to include the Vendor Tx Code in osc admin and order confirmation email as that is the one in the sage email and on the sage admin pages. Sage admin is bad enough never mind adding another piece of data to confuse everyone.

I just want an easy life...

[rlangton]

Hi,

I think the VPS Transaction ID is probably totally unique on the sage pay system, whereas the VendorTxCode is only unique to your sagepay account, so I guess maybe if a customer queried the transaction directly with sage pay then they'd be able to find it easier with the VPS Transaction ID (but that's a bit of a guess)

I've only been testing the server module, so not 100% sure this would work, but I think if you wanted to change it then you could try editing catalog/includes/modules/payment/sage_pay_form.php and change this line:-

$order->info['comments'] = 'Sage Pay Reference ID: ' . $return['VPSTxId'] . (tep_not_null($order->info['comments']) ? "\n\n" . $order->info['comments'] : '');

to

$order->info['comments'] = 'Sage Pay Reference ID: ' . $return['VendorTxCode'] . (tep_not_null($order->info['comments']) ? "\n\n" . $order->info['comments'] : '');

[tigergirl]

rlangton, on Sep 4 2009, 04:10 PM, said:

try editing catalog/includes/modules/payment/sage_pay_form.php and change this line:-

$order->info['comments'] = 'Sage Pay Reference ID: ' . $return['VPSTxId'] . (tep_not_null($order->info['comments']) ? "\n\n" . $order->info['comments'] : '');

to

$order->info['comments'] = 'Sage Pay Reference ID: ' . $return['VendorTxCode'] . (tep_not_null($order->info['comments']) ? "\n\n" . $order->info['comments'] : '');

thanks - that works and displays (in admin and order email) the transaction number the customer received from the Sage payment notification email. The customer isn't given the VPS transaction ID from Sage so that's why it's pointless giving it to them in the osc order conf email. I think this should be noted for future version releases.

Ross - does the Server module log the order in osc admin before the customer pays?

Thanks for all your help - still not receiving sage emails though

[rlangton]

Hi,

The server module still logs the order after the payment is complete, but it works differently so I think there is probably less chance of the payment going through but the order not being logged than there is with the form module, although I guess it could still happen, but we haven't had any problems yet.

I haven't looked at the official release of the direct module, but we were using the previous version a while back and I think that eliminated the possibility of orders not being logged, but we moved away from that due to the PCI audit requirements.

The server module isn't quite as slick as direct, but I personally think it's a big improvement over the form module, customers don't have to be directed away from your site to enter their payment details (which we found caused a few abandoned orders) it cuts down the number of payment steps and it only has the same PCI audit requirements as form.

Depending on your web host, you might have issues getting server or direct to work, they both need curl installed and you need to provide sage pay with the ip address of the server sending the requests.

I think there are contributions available that will change the checkout process to log the order when the customer click on confirm on the checkout confirmation page which might be what you're after. Never really liked the idea of this as you end up with orders logged that might not have actually been paid for.

Cheers,
Ross

[tigergirl]

Hi,
I found this thread to explain the bug fix http://forums.oscommerce.com/index.php?showtopic=80361 and I have applied the fix although I don't think this affected me as I'm not using external ot modules.

I was hoping to get the sage form module working to log the order before payment - can this please be worked on? For PCI reasons I want to use Form but the old module is ruining a few customer relationships and I am worried about this. I am actually considering moving to a different payment processor due to this .

Still need to get the vendor email issue resolved and the transaction ids still seem odd - they change as some have an extra 5 digits.

Thanks for all the suggestions.

[rlangton]

Hi,

The way the orders are logged is more down to oscommerce than sagepay or these modules, i would imagine you'd find similar problems using osc with any payment provider where you're redirected to their own hosted payment pages.

However, one of these contributions which log orders before the redirection might be what you're after:-

http://addons.oscommerce.com/info/1168
http://addons.oscommerce.com/info/5749
http://addons.oscommerce.com/info/6239
http://addons.oscommerce.com/info/871
http://addons.oscommerce.com/info/1153

Cheers,
Ross

[rlangton]

tigergirl, on Sep 4 2009, 09:18 PM, said:

Still need to get the vendor email issue resolved and the transaction ids still seem odd - they change as some have an extra 5 digits.

Similar problem in server with the VendorTxCode, It's built up like this (I assume form and server are probably similar here):-

'VendorTxCode' => substr(date('YmdHis') . '-' . $customer_id . '-' . $cartID, 0, 40)

For some reason the $cartID variable doesn't always seem to be set, which I guess is why the VendorTxCode sometimes ends in a '-', and sometimes in a number (the cartID)

[tigergirl]

rlangton, on Sep 4 2009, 10:51 PM, said:

Hi,

The way the orders are logged is more down to oscommerce than sagepay or these modules, i would imagine you'd find similar problems using osc with any payment provider where you're redirected to their own hosted payment pages.

However, one of these contributions which log orders before the redirection might be what you're after:-

http://addons.oscommerce.com/info/1168
http://addons.oscommerce.com/info/5749
http://addons.oscommerce.com/info/6239
http://addons.oscommerce.com/info/871
http://addons.oscommerce.com/info/1153

Cheers,
Ross

Thanks so much for supplying these links, I had found a couple last night but the instructions were confusing. I suppose I have been shielded from these problems by using paypal IPN V1.4 for so long and I have never lost an order with that and it's always updated in the end even if there is a delay and a customer has NEVER paid twice.

I thought I could try installing "Held Orders" contrib but this will not stop the customer paying twice at Sage if their cart isn't emptied and they think they haven't paid, which has happened quite a few times now with the other module sagepay_form-v1.20.

SO, the sage module (and all payment modules or osc) needs to work better IMO. It needs to work more like paypal IPN in logging the order before payment and preventing the customer paying twice on the same order. It's simply not good enough for such a mess to be created with customers not knowing if they paid or not, paying twice, carts not being emptied, stock not updated, no order emails sent, then the vendor having to fix everything - refunding/ voiding payments, using "Master Password" to create a cheque order or "Held Orders" to move it into the real orders table. Yesterday, I spent three hours on a "lost" parcel due this issue. Customers order wasn't logged so I did the whole rigmarole explained above and sent the parcel. Customer did not receive parcel so I asked her to contact local sorting office and that I had to wait until 15 working days after despatch before it was classed as lost. I eventually contacted sorting office who had the parcel, then I discover the customer had requested a different delivery address (she had moved) which I was unaware of. So the parcel has to be returned to me and I have to send a replacement to customer. Do you think that is a good customer experience? It's what happened and it's not the sort of thing that amuses me either and it's simply not good enough. I have worked hard over the last three years on my business and customer satisfaction and thought that getting a merchant account would increase sales. At the moment, I think I'm losing more customers than with paypal and I am not happy about annoying customers due to sage modules not working properly for whatever reason.

I do appreciate this is a new module which may work better than the old one but the fundamentals are the same at the moment and I can't see how it will resolve the issues I described above.

So if Sage wish to keep my business, then please can they develop a Certifed Form module that prevents this issue arising?

Obviously V1.1 won't be going live on my site until the email and vendot tx code issue is fixed. John at Sagepay says the vendor emails are being sent but they aint arriving in my inbox... I'm happy to test it if others supply fixes but I'm not a coder.
I think the module needs to be thought out a bit more...

Looking forward to getting a resolution.

[GemRock]

tigergirl, on Sep 5 2009, 09:54 AM, said:

...I do appreciate this is a new module which may work better than the old one but the fundamentals are the same at the moment and I can't see how it will resolve the issues I described above...

IMHO, your comment on the payment modules may be misplaced.
1. paypal ipn's behaviour of logging every order whenever it comes to the confirmation page is a defect NOT an advantage. a good payment module or payment processor such as protx or sage pay would not need to do this;
2. in my past few yrs experience of impletmenting protx module i can say protx is quite reliable and do not have any of the problem you describe in your posts. in fact shop onwers are quite happy with it;
3. some of the issues described in your posts make me believe your shop could have some problems itself, you could argue that why paypal have no problem, well paypay bypass some of the osc scripts like payment_process.php which other payment modules rely on. if there a problem in that file (or some others) then that would not affect paypal but do affect protx or sage pay.

Ken

[tigergirl]

I do appreciate your reply and I have posted the problem with the old module on several forums and not been able to track down the problem other than it may be my host server times out at a critical point. The issue improved afer a server move. Whatever the issue, I'd really like to sort it and maybe it wouldn't even happen with the new module (I can see there are error codes added which may help) but I can't go live with that until the other 2 issues with vendor email and id are fixed. I am worried that even by using the new module I will still have this problem.

What happens on sagepay_form-v1.20 intermittantly:
after sagepay you get directed back to https://xxx/checkout_payment.php?error_message=
cart not emptied, no order in admin, stock not updated, no order confirmation emails sent, BUT sagepay payment email notification emails sent. and then I have all the "fixing" order issues to deal with etc that I described before.

Sage say it's not their problem as they are sending the cust back to checkout_process, host says server fine and not overloaded. I got nowhere on sage support forum. If it's my site then does anyone have any pointers? I really don't know where to look.

I can only speak as an end user, not a programmer and I don't mean to dis the module as people writing stuff is what helps everyone and I'm very greatful for that. It's just frustrating not being able to get rid of the problem.

[John_SagePay]

Hi Claire.

Just to futher update you on this, the first transaction I looked at did show the vendor email being sent. However on looking at this I presume this was a transaction from a previous module that you had running.

When you completed another test transaction yesterday and sent across the TxID, I can confirm that the vendor email was not being sent hence you not receiving an email from Sage Pay.

I have since spoken with Harald and we have updated the module to include the various optional fields that will enable you to start receiving these emails.

Just awaiting now Harald to release the updated module.

Just out of interest would you not want to update your module to Sage Pay server and benefit from the iframe option? It will give a more seamless checkout flow whilst still maintaining the use of the hosted payment page. From a customer conversion point of view this may be a better option than redirecting your paying customers to another site to complete the transaction. Let me know what you think.

I appreciate all comments on these modules and we will continue to ensure that the feedback is taken on board and that the osCommerce users benefit from these modules which we will fully support and keep updated.

Many thanks,

John.

Edited by John_SagePay, 05 September 2009, 19:53.

[tigergirl]

I see Harald has uploaded V1.2 (very kind & thanks) without updating this thread.

So, V1.2 now in testing -

FIXED:
I get the vendor emails from Sage. Thank you.

NOT FIXED IN FORM V1.2:

Quote

Similar problem in server with the VendorTxCode, It's built up like this (I assume form and server are probably similar here):-

'VendorTxCode' => substr(date('YmdHis') . '-' . $customer_id . '-' . $cartID, 0, 40)

For some reason the $cartID variable doesn't always seem to be set, which I guess is why the VendorTxCode sometimes ends in a '-', and sometimes in a number (the cartID)

Ok, so I don't know what the $cartID actually is, where it comes from or where to look for it in osc admin and I guess if it's not passed it's not major as I get the info I need from the date/time stamp. Just irritating when things do not work as they should. Would be nice to have the osc order id here but of course the order isn't created until after the customer returns after payment.

I suppose we'd better keep a look out for the next version which may appear with the fix.

Will keep testing.

NB
I still feel creating orders before payment would be a very good back-up for the very widely known issues with lost orders in admin affecting others, not just me. I'm not bothered how paypal differs or doesn't rely on checkout_process or whatever = only ever bothered about my customers having a good experience and the website working correctly. So whether it's on the payment modules or a core code change - it is needed IMO. Sorry if the truth offends.

If anyone can give a pointer as to where my issues with lost orders may lie in checkout_process or whatever, please do. This will help others too.

[tigergirl]

John,
thanks for the reply and for checking the logs - I had not seen your reply before i hit the send button....
Well I have been considering "server" but actually I personnally like shopping on a website where I can see who is dealing with the security of my card details and that is how I prefer my website to be too.

I have noticed a few people selecting sage then abandoning and opting for paypal - not sure why - maybe 3d secure puts them off? The whole point of me using sage was to negate the need for paypal.

John, maybe you can advise if server would stop lost orders?
Is creating the order in osc before payment in Form something you would consider?

I'm sure we'll get it perfected in the end...

Thanks again

[GemRock]

John_SagePay, on Sep 5 2009, 08:50 PM, said:

...Just out of interest would you not want to update your module to Sage Pay server

forget about protx/sage server (not even protx/sage direct), most shop owners would choose form due to cost consideration. if a shop could afford server then s/he would propably not have the time/interest coming here ask questions and fixing issues her/himself.

or is it protx/sgae Server is now much cheaper? if not, i would say focusing on sgae form to make sure it works as it used to as protx form.

Ken

Edited by GemRock, 05 September 2009, 21:03.