Get the MageBase DPS – PaymentExpress Magento extension on MagentoConnect.
Features
- Use Payment Express either via PxPay or PxPost
- Adds new order statuses and configuration choices to fit your order workflow
- Displays transaction details in the back-end so you can be confident what you ship is what you have been paid for
Tested and approved by DPS.
PxPay Requirements
The extension uses the fail-proof notification by DPS to get notified of received payments – this requires internet connectivity (ie full testing on localhost will not work).
Some php / server configurations disallow access to the $_GET variable when it contains very long strings (2000+ characters) – if your server does this the extension will not work.
UPDATE: Please see the extension Trac pages for troubleshooting instructions: http://trac.fooman.co.nz/MB0002_DpsPaymentExpress/wiki
Screenshots
Originally published on magebase.com. Copyright © 2010 Magebase - All Rights Reserved.
Proud members of the 
A quick inspection of the code suggests online refund support. If true, this is a major enhancement over the Fontis one!
Hi Daniel, I am the developer behind the extension and I can confirm that online refunds work for PxPost and Magento 1.4.1. I still need to do some further testing on previous versions before advertising this feature.
Refunds look like they need to be enabled specially, but I can’t see how, could you point me in the right direction please? Thanks!
@Robert
Are you using PxPost? It’s not supported for PxPay.
@Robert: Thanks, we are using PXPost, I raised a credit memo to test and it would still only allow “Refund Offline”.
Hm, Kristof is on holiday at the moment so I’m not sure when he will be able to reply. Unfortunately, I’m not able to test this myself at the moment as I have no PxPost account testing.
Hey Robert,
Thanks for the extension. I just installed it and I lost access to the frontend. One of these errors:
Warning: simplexml_load_string() [function.simplexml-load-string]: Entity: line 60: parser error : Opening and ending tag mismatch: default line 45 and reference in /home/velcoff/public_html/shop/app/code/core/Mage/Core/Model/Layout/Update.php on line 294
Trace:
#0 [internal function]: mageCoreErrorHandler(2, ‘simplexml_load_…’, ‘/home/velcoff/p…’, 294, Array)
#1 /home/velcoff/public_html/shop/app/code/core/Mage/Core/Model/Layout/Update.php(294): simplexml_load_string(‘fetchFileLayoutUpdates()
#3 /home/velcoff/public_html/shop/app/code/core/Mage/Core/Model/Layout/Update.php(246): Mage_Core_Model_Layout_Update->fetchPackageLayoutUpdates(‘default’)
#4 /home/velcoff/public_html/shop/app/code/core/Mage/Core/Model/Layout/Update.php(224): Mage_Core_Model_Layout_Update->merge(‘default’)
#5 /home/velcoff/public_html/shop/app/code/core/Mage/Core/Controller/Varien/Action.php(265): Mage_Core_Model_Layout_Update->load()
#6 /home/velcoff/public_html/shop/app/code/core/Mage/Cms/Helper/Page.php(83): Mage_Core_Controller_Varien_Action->loadLayoutUpdates()
#7 /home/velcoff/public_html/shop/app/code/core/Mage/Cms/controllers/IndexController.php(45): Mage_Cms_Helper_Page->renderPage(Object(Mage_Cms_IndexController), ‘home’)
#8 /home/velcoff/public_html/shop/app/code/core/Mage/Core/Controller/Varien/Action.php(376): Mage_Cms_IndexController->indexAction()
#9 /home/velcoff/public_html/shop/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(248): Mage_Core_Controller_Varien_Action->dispatch(‘index’)
#10 /home/velcoff/public_html/shop/app/code/core/Mage/Core/Controller/Varien/Front.php(158): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#11 /home/velcoff/public_html/shop/app/Mage.php(459): Mage_Core_Controller_Varien_Front->dispatch()
#12 /home/velcoff/public_html/shop/index.php(65): Mage::run()
#13 {main}
I think its something to do with the update.php but I’m hopeless at .php right now. Any suggestions?
Thanks
Fixed it.
Using this kids method.
See below
Resolved. but not fixed.
What I did to resolve?
First of all I’m using the default template, just editing the files.
I made a backup of this directory: /app/design/frontend/default/default
- layout
- locate
- template
Then I unzip the directory /app/design/frontend/default/default who comes with the ZIP file, in the case: ‘magento-1.3.2.3.zip’ and send the uncompressed directory to my server, after all transfer done, worked as default template.
After that, I was sending file by file that was changed to find out what caused the error. But to my surprise, it returned to work perfectly.
Weird, but can be an solution for somebody else.
@Fran
you are using Magento 1.3.2.3? In that case you need to use the 1.1.2 version of the DPS extension as outlined in the Overview. If you have used the extension key for the 1.1.3 version, it won’t work correctly for Magento 1.3.x
Hey Robert,
Just reread my first post and it reads like I was being critical of the extension. Just to clarify I wasnt. I think its great.
I am using the proper version I just had a bit of debugging to do.
Thanks Again
Fran
Have you ever seen a problem with this working with the one step checkout extension? I thought it was going fine but I just ran one last test and I have the NK error again which is usually related to a wrong user ID or PXpaykey. Any thoughts? Thanks
I’d say Kristof might have some comments on this question… I haven’t tried the new DPS extension on the One Step Checkout.
Is there anything I can post to help? The website is http://www.velocitycoffee.com/shop If you run through it you will see it fails when sent over to DPS. Anyway Ill keep trying.
Sorry its a .co.nz/shop
I just disabled the cache again on the backend and it came right.
So I went through the cache options one-by-on:
Configuration
Layouts
Blocks HTML output
Translations
Collections Data
EAV types and attributes
Web Services Configuration
until I got to Blocks HTML output and BAM! That is the culprit.
So if I keep this off will there be other adverse effects?
Ill post anyting else over on the forums so I dont muddy up anymore of this article.
thanks
Hi Fran,
not sure if this would work with OneStepCheckout. The best advice I can give is to enable all debugging (under payment for MageBase DPS PxPay and under Developer) then test with both the normal and the onestepcheckout. And then compare where both differ. During a normal checkout getOrderPlaceRedirectUrl would provide the link to dps.
good luck
@Fran, you shouldn’t have adverse effects if you keep the Block output caching off. It just means that part won’t be cached.
@Fran, @Kristof
After installing the DPS ext on a shop that uses the OneStep Checkout, I have encountered the same issue as Fran. When the Block output cache is enabled, the payment fails.
After investigating, it transpires that the DPS success and fail URLs are passed through to DPS with a query parameter containing ?___SID=U. This may be due to something in the OneStep Checkout since I have tested the DPS extension on a stock standard Magento 1.4.1.1 install with the built in checkout and there were no issues with cache enabled.
In any case, I have simply added code to strip out the query string from the success and fail URLs before passing them to DPS. After that I could enable the block cache again.
Cool Ill have to give that a try at some point. If you get a chance I’d be grateful to know exactly what you did. I meant to come to the meet-up last night but my 1 yr old is sick. Next time.
We are still checking the issue out. There may be a better way to deal with this. I’ll comment again when we have more info.
Have you guys had any issues with Guest checkout not sending confirmation emails to either Guest or “Send Order Email Copy To” contact? I notice that inside sales/order/order number where DPS usually sends a response text saying approved that it isn’t showing up there either. Not sure where to start here.
No issues reported about the Guest checkout. Turn on debugging and logging and see what’s going on. Is this on a live site?
Hey,
Its on Velocitycoffee.co.nz/shop
Yeah its live but still in an unfinished phase.
Another thing worth mentioning is that you cant do 0.00 dollar transactions without DPS throwing and error. So if someone has a coupon that makes their entire order free it freaks out a bit. Ill try the logging and debugging thing and let you know. Thanks
Ok so here it is:
Note: I do the transaction for shipping only so DPS charges me the $2.50 then when it sends me back to Magento magento shows the transaction as being $0 dollars because it doesn’t factor the shipping dollar in for some reason.
Here are the logs FYI.
DPS PxPay Log
2010-08-18T04:44:01+00:00 DEBUG (7): DPS result from url: v5i2PdhUMzjBHUHcrouiUmP7t58hAB5f0qEOPvzPC-BJ4moFMCr2Qa8DHFoLezf3pZWGu1JDe27l5u7-Lx2gpkxbtTZ4-CnIYvkUHr9Sm-pqzthajG_tmpCiO98EM6YjmcYRbkCh78YqiaGCJdfJQvsmMNKnRZRDcdrc3Fo-RZQGCe-e0q7TxcHisSE0103OS_PzIgiVHRFWWllpCzW56D66CK6ykI5-O0h6vbGX6DVqNYcNduuBVEL3goS-MUJHzrFhjuV8TUMT3Fk2YOBV0Hsw3JM2e9VeJbC54gObPgMtfe7IOWkC5rPZivYJuHI7V4a2b6ozJC0KkowiR93Hc6vomDK8ZqSjB5Mehrg-ljXe5Fow8-n9yAltzQwzIBRcYoOG3zr8wO1oo_1HOifHyyawSa9wY8MlOu1Ij9rLQmj5c8oLGvJr34mV5fG1L5WFy1abaV211I1Jq-PFFWUgMbubdSknIzvbchrme8W9S5K-vOQ6m2QOe7PjyjECYdliKCFIpP4u6rSAQ1Tr6V_Fp5RAlqeGawIJrg
2010-08-18T04:44:02+00:00 DEBUG (7): 500000011 Error in DPS Response Validation: Mismatched totals
2010-08-18T04:44:02+00:00 DEBUG (7): MageBaseDps failed with exception - see exception.log
2010-08-18T04:44:10+00:00 DEBUG (7): 500000011 MageBaseDps User returned to Success Url
Exception Log:
2010-08-18T04:44:02+00:00 ERR (3):exception 'Varien_Exception' with message 'Invalid method Mage_Sales_Model_Order::registerCancellation(Array
(
[0] => There has been an error processing your payment. Please try later or contact us for help.
[1] =>
)
)' in /home/velcoff/public_html/shop/lib/Varien/Object.php:549
Stack trace:
#0 [internal function]: Varien_Object->__call('registerCancell...', Array)
#1 /home/velcoff/public_html/shop/app/code/community/MageBase/DpsPaymentExpress/Model/Method/Pxpay.php(508): Mage_Sales_Model_Order->registerCancellation('There has been ...', false)
#2 /home/velcoff/public_html/shop/app/code/community/MageBase/DpsPaymentExpress/Model/Method/Pxpay.php(198): MageBase_DpsPaymentExpress_Model_Method_Pxpay->_cancelOrderAfterFailure(Object(SimpleXMLElement))
#3 /home/velcoff/public_html/shop/app/code/community/MageBase/DpsPaymentExpress/controllers/PxpayController.php(132): MageBase_DpsPaymentExpress_Model_Method_Pxpay->processSuccessResponse('v5i2PdhUMzjBHUH...')
#4 /home/velcoff/public_html/shop/app/code/community/MageBase/DpsPaymentExpress/controllers/PxpayController.php(80): MageBase_DpsPaymentExpress_PxpayController->_processSuccessResponse('v5i2PdhUMzjBHUH...')
#5 /home/velcoff/public_html/shop/app/code/core/Mage/Core/Controller/Varien/Action.php(376): MageBase_DpsPaymentExpress_PxpayController->successAction()
#6 /home/velcoff/public_html/shop/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(248): Mage_Core_Controller_Varien_Action->dispatch('success')
#7 /home/velcoff/public_html/shop/app/code/core/Mage/Core/Controller/Varien/Front.php(158): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#8 /home/velcoff/public_html/shop/app/Mage.php(459): Mage_Core_Controller_Varien_Front->dispatch()
#9 /home/velcoff/public_html/shop/index.php(65): Mage::run('home')
#10 {main}
Thoughts?
Thanks
Hm, this issue is something that Kristof might be better suited to comment on. The key seems to be in: “Error in DPS Response Validation: Mismatched totals”. Not sure if you should even be able to do a zero total checkout. There is a Magento setting addressing zero total checkouts… never been clear on what it actually does!? Maybe you can play with that? Ideally, with a zero total, you just want the order to be created without even passing over processing to DPS, right?
Regarding the zero total – yeah exactly.
I think that if I could make magento acknowledge the shipping amount as part of the total price then that could fix that problem. Its weird because right now it sends the total to DPS with the shipping included and when DPS sends back the total it has charged magento doesnt accept it as legit because it discounts the validity of shipping amount making up part of the total – if that makes sense.
Has anyone noticed that with this extension – orders are automatically invoiced? To double check I just reverted back to the original Fontis DPS payment method (orders no longer automatically invoiced).
@Graham
Yep, that’s the standard way that all payment gateways (like PayPal, Authorize.NET, etc…) work when payment has been successful. Since the payment has gone in, the system generates an invoice. If you want to reverse or cancel such an order, you need to issue a proper refund via credit note.
The fact that the Fontis one didn’t create an invoice was actually a bug, not a feature
.
Haha. Looks like I’m confusing bugs with features then lol.
Thanks Robert.
Hey Guys. Any interest in making this work with the Aheadworks Subscriptions and Recurring Payments ext. I see that dps now has the recurring payment option available (http://www.paymentexpress.com/products/recurring_billing.html) I have a copy of the aheadworks extension if you want to play with it. If its not a high priority could someone develop it specifically for me for a reasonable price? Its a bit more than I can do for sure.
Thanks
@Fran Magento added the option for recurring payments and profiles as beta in 1.4.1.0. I believe it is comparable feature-wise with the aheadworks extension. I am currently waiting on the sidelines to see what options will be possible by this development and what the differences for on-site payments (PxPost) and third-party payments (PxPay) will be. I noticed you rsvped to the meetup this week so we can talk about it in detail on Wednesday.
Just tried to upgrade due to noticing an error this morning with the correct status not being returned after a successful transaction (pending instead of processing).
Tried upgrading to magento-community/MageBase_DpsPaymentExpress-1.1.8 as I’m on 1.3.2.3.
I get the error (in Connect) ‘Ignoring installed package magento-community/MageBase_DpsPaymentExpress’
Just wanted to check am I installing the correct version?
Thanks!
I’ve been trying this out with the intention to use auth/complete purchasing via pxPay – it looks like the auth works perfectly, but I can’t see any interface to do completion from within Magento. Is the idea that you do auth via the extension and then go do the completion transactions within the DPS administration interface?
@Tim this is the expected behaviour. You can’t complete a previously auth purchase without a PxPost account. So yes you would need to log into the dps admin area complete the transaction there and then invoice/capture offline in Magento.
Thanks, I’ll do some investigation with PxPost (we’ve got both accounts), hopefully we can extend the extension to perform PXPay completion payments using PxPost from the admin.
Thanks for a great extension.
I have gone right in a installed it on Magento 1.5.0.1 (may be a bit naive) and all going well until I get a declined card. On clicking “next” the follow fatal error is kicked back.
Fatal error: Call to a member function getLastRealOrderId() on a non-object in /httpdocs/app/code/community/MageBase/DpsPaymentExpress/controllers/PxpayController.php on line 138
Is this something that is related to that way I have setup my sever or DPS.
@chris please check the extension trac page for details and also the troubleshooting guide.
Robert thanks for the link. I will have a look through the trouble shooting section.
@chris the extension should now work on 1.5.0.1 – please let me know if you are still seeing the issue via the bug tracker.
Kirstof I will do. Thanks for the looking into it and will makes sure I track all errors I encounter. Not that I am expecting to.
Just checked it and it is working perfectly. Thank you again for putting together such a great extension.
I’ve noticed this module doesn’t dispatch any events on payment success. Core events like ‘sales_order_payment_pay’ often come at weird times (that one triggers before redirect to the payment gateway, every time). Have you considered adding some events to the Model/Method/PxMETHOD.php files?
We’re considering doing this for a site where we’ll need to trigger some code on payment success/failure, just wondering if I’m missing a core event that would work well.
Hi Sam,
thanks for the feedback. Can you please add a feature request to the bug tracker. Please also include against which payment method you are currently comparing.
Does the current version of the module with PxPay support the new requirements for DPS’s upcoming migration on 30th September?
http://www.paymentexpress.com/migration.html
Thanks for the heads up. An update will be available before the deadline. You can track it here:
http://trac.fooman.co.nz/MB0002_DpsPaymentExpress/ticket/23
If you want to follow this issue, use http://www.followthatpage.com to follow the RSS for the ticket, http://trac.fooman.co.nz/MB0002_DpsPaymentExpress/ticket/23?format=rss
Or use a RSS reader or something …
Wicked Extension ………………
Just a quick note that versions 1.2.0 and 1.2.1 have been released as a beta with the updated urls. Please leave any feedback here.
Thanks Kristof – to update for the DPS migration do we just update the module as normal in Magento Connect?
Hi Kristof,
Will this beta release be upgraded to Stable this week, or will we need to apply the Beta to make the end of August deadline?
Regards,
JP
Trying to update it using Magento Connect.
It’s saying this:
downloading MageBase_DpsPaymentExpress-1.1.17.tgz …
Doesn’t that mean it’s still on 1.1.17, whereas it should be downloading 1.2.1 (I’m on Magento 1.4.1, so am using the V1.0 Magento Connect key)
I also have a problem with it not being able to create a directory.
ERROR: failed to mkdir [hidden]/shop/httpdocs/app/design/adminhtml/default/default/template/magebase/dps/pxpay/pdf
OK, one issue solved: you have to go to ‘releases’ to get the right version – not that intuitive seeing as it only says that next to the v1.3 info, not v1.4
I still have the issue of not being able to create a directory. Is this because it already exists?
Do I have to uninstall the existing extension first? (Don’t want to do this because it would mean I can’t take orders if I then can’t either install the new version or reinstall the old one).
@ Darren Your issue with the directory may be to do with the file ownership on your server? You may need to check if the adminhtml template files and folders are writable by the web server process (as opposed to the ftp user you may be using to upload files).
@JP – was planning to release as stable before then. So far I had no reports on the beta (good or bad) so am assuming that no issues were encountered.
@Darren – if you use the key without version it will automatically find the last version within your preferred stability. Since you’ll likely have it as “stable” it installs the 1.1.17 version. For the mkdir error see Robert’s response above.
Hi guys, presumably I can change https://sec2.paymentexpress.com/pxpay/pxaccess.aspx to https://sec.paymentexpress.com/pxpay/pxaccess.aspx inside mysite.com/code/community/magebase/DpsPaymentExpress\Model\Method ?
Is is it a little more complicated/more places to update than that?
Cheers,
Mitchell
@Mitchell Yes you can update the code directly with the new URLs. Take care to use the correct ones for the PxPay and PxPost methods since they are different.
Thanks Robert, I have updated mysite.com/app/code/community/MageBase/DpsPaymentExpress/Model/Method/Pxpay.php with the new URL. Was that everything I needed to update?
Cheers
I have added new releases, marked as stable, with the new urls. Get them here:
http://www.magentocommerce.com/extension/specs/3878/magebase_dpspaymentexpress
Hi there, this extension looks really neat. Just wondering if it is tested under 1.6? Cheers, Tony
Hey just like tony i am curious to know if this works with 1.6 cheerz, adam
I’m using it fine on http://firstinhealth.co.nz which is running the very latest stable version.
I know that the MageBase payment express extension (PxPay) is not set up for handling a multiple address checkout in Magento, right?
But before I look into this any further I was wondering if it was developed this way because it would not work with DPS, or if it would be possible, if we had a PHP developer familiar with DPS, to add the functionality to process multiple address orders to DPS?
Thanks,
Mike.
@MikeD
To my knowledge, Magento’s Multi Address checkout does not support 3-party payment gateways. The Magebase DPS extension supports both the PX Pay and PX Post methods. PX Pay is a 3-party method and cannot be used for multi address checkouts.
PX Post, on the other hand, should be compatible with the multi address checkout out of the box (any comments, Kristof?). However, to be able to use PXPost on a site, it will have to pass full PCI compliance as the credit card details are entered on the merchant site. This may be an issue with NZ based banks.
While I am not saying it would not work all Magento 3rd party payment methods that I have come across don’t work with the Multi-Address Checkout. Happy to be proven wrong though – so please do submit a patch if you implement it.
All my credit card orders are coming through as ‘cancelled’ even though DPS has taken the money and put it in our account. Anyone know why this would be happening?
I’m using 1.6.1.0 with v1.2.3 of this plugin.
I don’t think we’ve changed anything recently.
Did you change / add some shipping costs perhaps? Maybe you added some extension that implements some additional charges? Best to check the magebase_dps log under [siteroot]/var/log/ for any messages. You may need to enable logging in your admin backend.
My guess is that you’re getting a value mismatch for the order total. In my experience this happens when you use shipping costs that have more than 2 non-zero decimal places. ie.: 3.5692. There is a stringent check on payment return that verifies that the paid total matches the order total. The discrepancy comes from the order total being calculated at the full precision and the paid total being rounded to 2 decimals.
There are two ways around this, you can alter the validation code in
app/code/community/MageBase/DpsPaymentExpress/Model/Method/Pxpay.phparound line 353:if (abs((float)$resultXml->AmountSettlement - $order->getBaseGrandTotal()) >0.0005) { ...and change the 0.0005 to say 0.05
or revisit your shipping costs and change them to 2 decimal values if that’s what was causing the issue.
But before changing the code, make sure you establish the actual reason for failure.
That worked – we implemented the rounding error fix for prices and that’s what had happened.
Shipping costs are already set to 2 digits, so I implemented your fix above and it’s now fine again. Thanks heaps for that. I hope you and Leanne have a great Xmas.
Great you managed to fix your site. You have a fantastic Christmas too.
99% fixed. I now can’t cancel orders, but I’ll look into that later!
Once an order is “Invoiced” you can’t cancel it, you need to refund it by issuing a credit note.
It’s standard Magento order workflow. You can only cancel orders without invoices/shipments, ie. only Pending ones. You can change your payment method to Authorize (instead of Purchase) then you would be able to cancel them, but also, you will have to create invoices manually and your orders would come in Pending.
Ah, of course – the orders that failed weren’t invoiced. That makes sense. All sorted now.
Hi Robert,
Can you please advise if this DPS extension runs on Magento 1.6?
Just that the MagentoConnect site says only up to 1.5.
Thanks.
I’m running it on 1.6.1.0 and 1.4.1.1 and it’s fine.
Thanks Darren, I’ll give it a shot since I am looking to setup a new store.
After a succesful payment using the PXPay method, the Order Status is set as ‘Pending Payment’ and never changes. Looking at the config page in Maneto Admin it looks like it is supposed to change to ‘Processing’ upon receiving a successful payment confirmation but this never seems to happen. Any ideas anyone?
Richard, I think the issue is that, as Kristof says, your site is disallowing public access so the DPS IPN can’t get through. I believe you may have a .htpassword protection for your dev site. To test this successfully, you may need to remove the access restriction temporarily or create some exclusion rules for the DPS IPN IPs.
@Richard yes this should update. You need to make sure that DPS can reach your site. Additionally things like php suhosin can prevent the response to be read. Check the troubleshooting guide to work out what is happening or not happening.
Robert, thank you, yes that was the problem. There was what appeared to a valid reponse from DPS in the debugging table which I guess indicated to me communication with DPS was OK even when it wasn’t. Thanks again guys!