I've asked WorldPay for advice and they've said we need to be posting to https://secure.worldpay.com/wcc/purchase, but I can't find anywhere within uCommerce where this URL can be configured.
Anyone have any ideas how to change this URL?? Basically we need to change all references of "rbsworldpay.com" otherwise the checkout process will not work...
You can not change the url where uCommerce POST order data in a configuration file (as far I'm aware). However you can change it by override the default "page" generator and change to post URL that way. I'm not sitting with the code right now but my guess with be that you need to create a new class which inherits from WorldPayPageBuilder (Not sure whether its entirely correct). Then you can override the BuildBody method and then change post URL to the correct one.
I suggest you activate debug then you're able to see what values are posted to the payment provider.
There seems to be 301 redirects in place for the URLs uCommerce is using pre-3.6 so I expect it to continue working wihtout incident.
However, just to be on the safe side I have updated uCommerce 3.6 with the latest URLs. You can grab a copy at www.ucommerce.dk/releases/uCommerce-3.6.0.13142.zip. (Remember backup if you decide to upgrade).
I was nervous with relying on the WorldPay redirects and didn't fancy upgrading from uCommerce 2.6 to 3.6, so instead I followed an approach similar to what Martin suggested except I created a class to inherit from the WorldPayPaymentMethodService. I could then simply override the PostUrl as required.
Looks like everything is still working as expected, but I guess we'll need to wait until WorldPay's deadline of tomorrow and see what happens!
WorldPay post URL not configurable?
We’re trying to determine once and for all if any of our uCommerce websites will be affected by the upcoming changes being made by WorldPay - http://www.worldpay.com/support/index.php?page=domain-change&c=WW
What we’ve established is that our sites appear to be posting to the WorldPay payment gateway using https://secure.wp3.rbsworldpay.com/wcc/purchase, which then redirects to https://secure.worldpay.com/wcc/dispatcher.
I've asked WorldPay for advice and they've said we need to be posting to https://secure.worldpay.com/wcc/purchase, but I can't find anywhere within uCommerce where this URL can be configured.
Anyone have any ideas how to change this URL?? Basically we need to change all references of "rbsworldpay.com" otherwise the checkout process will not work...
Surely I'm not the only person using WorldPay with uCommerce?!?
Hi Jamie Robb,
You can not change the url where uCommerce POST order data in a configuration file (as far I'm aware). However you can change it by override the default "page" generator and change to post URL that way. I'm not sitting with the code right now but my guess with be that you need to create a new class which inherits from WorldPayPageBuilder (Not sure whether its entirely correct). Then you can override the BuildBody method and then change post URL to the correct one.
I suggest you activate debug then you're able to see what values are posted to the payment provider.
Best regards Martin
There seems to be 301 redirects in place for the URLs uCommerce is using pre-3.6 so I expect it to continue working wihtout incident.
However, just to be on the safe side I have updated uCommerce 3.6 with the latest URLs. You can grab a copy at www.ucommerce.dk/releases/uCommerce-3.6.0.13142.zip. (Remember backup if you decide to upgrade).
Thanks for your help guys.
I was nervous with relying on the WorldPay redirects and didn't fancy upgrading from uCommerce 2.6 to 3.6, so instead I followed an approach similar to what Martin suggested except I created a class to inherit from the WorldPayPaymentMethodService. I could then simply override the PostUrl as required.
Looks like everything is still working as expected, but I guess we'll need to wait until WorldPay's deadline of tomorrow and see what happens!
Let me know how it worked out for you.
Looks like everything working ok thanks :)
is working on a reply...