Orders Not Validated Using AtosOrigin Gateway

Phil

unread,

May 28, 2012, 6:37:48 PM5/28/12

to in-port...@googlegroups.com

Hi guys,

I've met -again- a known bug: orders successfully placed using AtosOrigin gateway always stay in "Incomplete" status.

I remember it was a problem with read access to units/gateways/gw_classes/notify_scripts/atosorigin_notify.php , but I've checked that this file is actually readable from an external server, and that correct path is sent to Atos server, then problem can't be on sent informations, which are correct.
Also, when I click on "Return" button from gateway, after successful payment, order validation should occur trough this direct return link, even if automatic validation fails. But none of them are working.

Because neither automatic or manual validation occurs, I bet the problem comes from response parsing, but I can't do more at this point, as I don't know how to log returns from gateway by modifying gw class file :-S

Minor bugs in atosorigin.php gw class file

- duplicate line #62

- #99 : return '</form>'.$ret.'<form>'; : forms opening and closing are in wrong order, but finally it's not needed at all, because there's already 2 surrounding HTML form tags (!), so line should be " return $ret; "

p

Dmitry A.

unread,

May 29, 2012, 1:39:46 AM5/29/12

to in-port...@googlegroups.com

Phil,

Please troubleshoot this on your a bit further and provide more details so we can check on this:

1. See what Error / Web log shows you when Atos does request

2. See what PHP log shows you when Atos does request

Post both here so we can review. At least we'll see if there a PHP error or issues with accessing file.

DA

Alexander Obuhovich

unread,

May 29, 2012, 4:06:51 AM5/29/12

to in-port...@googlegroups.com

Yes, I was also interested in whatever Atos gets correct request from In-Commerce (e.g. payment is created on Atos side) and then if Atos sends back request to In-Commerce and he really gets something useful back (e.g. HTTP 200 code and not 401 code).

Copy-paste from atos-in-commerce communications from apache log would be very useful.

Also was it working link that all the time or just broke recently because of Atos changed it's api or something like that?

--
You received this message because you are subscribed to the Google Groups "In-Portal Bugs Team" group.
To view this discussion on the web visit https://groups.google.com/d/msg/in-portal-bugs/-/QAV-4q6Fz2cJ.

To post to this group, send email to in-port...@googlegroups.com.
To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/in-portal-bugs?hl=en.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

Phil

unread,

May 30, 2012, 7:12:48 AM5/30/12

to in-port...@googlegroups.com

I've made tests and here is the error log:

POST /modules/in-commerce/units/gateways/gw_classes/notify_scripts/atosorigin_notify.php HTTP/1.0" 401 712 "-" "-"

while if I access it directly in browser:

GET /modules/in-commerce/units/gateways/gw_classes/notify_scripts/atosorigin_notify.php HTTP/1.1" 200 1314 "-"

It seems that POST from outside server is blocked for authentication...

Additionally, the second POST, which is "manual return" URL, and which should also validate order, in case automatic return wouldn't work, isn't doing the job, because it is redirecting directly to tpl:

POST /in-commerce/checkout/checkout_success.html HTTP/1.1" 200 6867 "-"

while payment result info should be also retrieved here.

2 problems now related to this bug:
- notify script is not reachable from payment gateway
- manual POST return don't communicate with notify script

Le mardi 29 mai 2012 à 10:06, Alexander Obuhovich a écrit :

> Yes, I was also interested in whatever Atos gets correct request from In-Commerce (e.g. payment is created on Atos side) and then if Atos sends back request to In-Commerce and he really gets something useful back (e.g. HTTP 200 code and not 401 code).
>
> Copy-paste from atos-in-commerce communications from apache log would be very useful.
>
> Also was it working link that all the time or just broke recently because of Atos changed it's api or something like that?
>
>
> On Tue, May 29, 2012 at 8:39 AM, Dmitry A. <dand...@gmail.com (mailto:dand...@gmail.com)> wrote:
> > Phil,
> >
> >
> > Please troubleshoot this on your a bit further and provide more details so we can check on this:
> >
> > 1. See what Error / Web log shows you when Atos does request
> > 2. See what PHP log shows you when Atos does request
> >
> > Post both here so we can review. At least we'll see if there a PHP error or issues with accessing file.
> >
> >
> > DA
> >
> > --
> > You received this message because you are subscribed to the Google Groups "In-Portal Bugs Team" group.
> > To view this discussion on the web visit https://groups.google.com/d/msg/in-portal-bugs/-/QAV-4q6Fz2cJ.
> >

> > To post to this group, send email to in-port...@googlegroups.com (mailto:in-port...@googlegroups.com).
> > To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com (mailto:in-portal-bugs%2Bunsu...@googlegroups.com).

> > For more options, visit this group at http://groups.google.com/group/in-portal-bugs?hl=en.
>
>
>
>
> --
> Best Regards,
>
> http://www.in-portal.com
> http://www.alex-time.com

> --
> You received this message because you are subscribed to the Google Groups "In-Portal Bugs Team" group.

> To post to this group, send email to in-port...@googlegroups.com (mailto:in-port...@googlegroups.com).
> To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com (mailto:in-portal-bug...@googlegroups.com).

Alexander Obuhovich

unread,

May 30, 2012, 11:39:19 AM5/30/12

to in-port...@googlegroups.com

- notify script is not reachable from payment gateway

This is bug from our side. We've recently added "/modules/in-commerce/units/.htaccess" file, that blocks any direct access to files inside that folder, including gateway notification scripts it seems.
You can safely remove that .htaccess to make it work again.

I guess 2nd problem would be solved along with first one.

To post to this group, send email to in-port...@googlegroups.com.
To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/in-portal-bugs?hl=en.

Phil

unread,

May 30, 2012, 11:44:41 AM5/30/12

to in-port...@googlegroups.com

as I've reported in my previous post, I CAN access notify script when I access it via browser (code 200), then it can't come from here (and additionally, I don't have .htaccess in whole notify script path.

Envoyé avec Sparrow (http://www.sparrowmailapp.com/?sig)

> > > > To post to this group, send email to in-port...@googlegroups.com (mailto:in-port...@googlegroups.com) (mailto:in-port...@googlegroups.com).
> > > > To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com (mailto:in-portal-bugs%2Bunsu...@googlegroups.com) (mailto:in-portal-bugs%2Bunsu...@googlegroups.com (mailto:in-portal-bugs%252Buns...@googlegroups.com)).

> > > > For more options, visit this group at http://groups.google.com/group/in-portal-bugs?hl=en.
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Best Regards,
> > >
> > > http://www.in-portal.com
> > > http://www.alex-time.com
> > > --
> > > You received this message because you are subscribed to the Google Groups "In-Portal Bugs Team" group.

> > > To post to this group, send email to in-port...@googlegroups.com (mailto:in-port...@googlegroups.com) (mailto:in-port...@googlegroups.com).
> > > To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com (mailto:in-portal-bugs%2Bunsu...@googlegroups.com) (mailto:in-portal-bug...@googlegroups.com (mailto:in-portal-bugs%2Bunsu...@googlegroups.com)).

Alexander Obuhovich

unread,

May 30, 2012, 11:54:05 AM5/30/12

to in-port...@googlegroups.com

Then you have restriction in apache that prevents that script to be accessed from atos server. In-Portal doesn't return 401 code anywhere.

To post to this group, send email to in-port...@googlegroups.com.
To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/in-portal-bugs?hl=en.

Phil

unread,

May 30, 2012, 5:26:53 PM5/30/12

to in-port...@googlegroups.com

That's right, I had a problem locally which have been easily solved.

Still stand the second bug, where POST request to checkout_success don't use informations to validate order (in case it have not been validated automatically).

> > > > > > For more options, visit this group at http://groups.google.com/group/in-portal-bugs?hl=en.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards,
> > > > >
> > > > > http://www.in-portal.com
> > > > > http://www.alex-time.com
> > > > > --
> > > > > You received this message because you are subscribed to the Google Groups "In-Portal Bugs Team" group.

> > > > > To post to this group, send email to in-port...@googlegroups.com (mailto:in-port...@googlegroups.com) (mailto:in-port...@googlegroups.com) (mailto:in-port...@googlegroups.com).
> > > > > To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com (mailto:in-portal-bugs%2Bunsu...@googlegroups.com) (mailto:in-portal-bugs%2Bunsu...@googlegroups.com (mailto:in-portal-bugs%252Buns...@googlegroups.com)) (mailto:in-portal-bug...@googlegroups.com (mailto:in-portal-bugs%2Bunsu...@googlegroups.com) (mailto:in-portal-bugs%2Bunsu...@googlegroups.com (mailto:in-portal-bugs%252Buns...@googlegroups.com))).

Alexander Obuhovich

unread,

May 31, 2012, 7:26:57 AM5/31/12

to in-port...@googlegroups.com

Still stand the second bug, where POST request to checkout_success don't use informations to validate order (in case it have not been validated automatically).

This is for security reasons. This way just going to that "checkout_success.html" page won't approve order or set it's status as paid. Doesn't this gateway only redirect user back to "checkout_success.html" page, when payment has been made, like PayPal does?

To post to this group, send email to in-port...@googlegroups.com.
To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/in-portal-bugs?hl=en.

Phil

unread,

May 31, 2012, 10:35:58 AM5/31/12

to in-port...@googlegroups.com

Gateway replay in POST with an encrypted message, that is decrypted locally via binary file.
Users could also forge a reply directly to notify script, because it's also in free access, then nothing to protect here.
But it's very rare that server who processed correctly payment forget to send this automatic answer, then it's not a so big problem maybe.

Envoyé avec Sparrow (http://www.sparrowmailapp.com/?sig)

> > > > > > > > For more options, visit this group at http://groups.google.com/group/in-portal-bugs?hl=en.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best Regards,
> > > > > > >
> > > > > > > http://www.in-portal.com
> > > > > > > http://www.alex-time.com
> > > > > > > --
> > > > > > > You received this message because you are subscribed to the Google Groups "In-Portal Bugs Team" group.

Phil

unread,

Jun 7, 2012, 5:43:02 PM6/7/12

to in-port...@googlegroups.com

Guys,

I'm back on this. I've performed hours of tests and investigations, and I've concluded that general notify script (gw_notify.php) is in cause.

Here is what I've found:

1- when GW server send back payment information, In-Portal (stupidly) wants to send cookies to GW server

2- because of this cookie problem (or not), user session, tied to order ID, become a Guest session

3- Orders stay as "Incomplete"

4- when brought back on checkout page, user is logged out, even if he logged in before ordering (side effect of #2)

I've carefully checked that we send the correct return URL for automatic info return.

Problems 1 - 2 - 3 happens immediately after payment is validated, and BEFORE I click to be brought back on In-Portal. The roblem occurs on automatic return, when notify script is reached, because changes occurs in user session, means that some info have been retrieved to group Guest ID with user's order session.

At his point, I was sure that Atos script wasn't in cause, and I wanted to validate this assertion.

Then I had the idea of conduction a test on beta server, for 520b3. (Great idea, it seems I've found another bug, see below)

Here is the test case:

- I've created a new product

- I've setup Paypal payment with sandbox environment

- Because of bug about impossibility to enter product details such as price, I've added a processing fee of $5 to Paypal payment mode

- I've placed my order, and have chosen Paypal as payment gateway

Once on Paypal payment page:

- only subtotal price is sent, instead of grand total (my product price was set to 0, and price to pay was also 0, but should have been 0 + $5= $5)

- when payment is validated, nothing happen: order stay as incomplete

About Sub-total bug, I'll fill another thread.

p

Alexander Obuhovich

unread,

Jun 8, 2012, 2:28:51 PM6/8/12

to in-port...@googlegroups.com

Please test on 5.1.3 version as well, where you can enter product price.

p

--

You received this message because you are subscribed to the Google Groups "In-Portal Bugs Team" group.

To post to this group, send email to in-port...@googlegroups.com.
To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/in-portal-bugs?hl=en.

Phil

unread,

Jun 8, 2012, 2:38:45 PM6/8/12

to in-port...@googlegroups.com

product price isn't in cause here, because when using paypal sandbox system, you can modify value before paying.

I'm reporting this because I encounter the very same problem in v510, and as far as I know nothing have been changed in gw notify scripts, isn't it? Is really worth it to test on another intermediate version? My test was including a processing fee, so cart wasn't 0,00 euros.

But maybe my test wasn't good, because beta servers are under a password protected directory. That's why doing your own tests would bring another tester-knowledge in the game, and would may end in a wrong-report from my side.

Asking to someone who have found a bug if it's happening in another case, make you taking the risk that problem comes from tester way-of-doing, and then both of us are loosing time...

Envoyé avec Sparrow (http://www.sparrowmailapp.com/?sig)

> > To post to this group, send email to in-port...@googlegroups.com (mailto:in-port...@googlegroups.com).
> > To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com (mailto:in-portal-bugs%2Bunsu...@googlegroups.com).

> > For more options, visit this group at http://groups.google.com/group/in-portal-bugs?hl=en.
>
>
>
>
> --
> Best Regards,
>
> http://www.in-portal.com
> http://www.alex-time.com

> --
> You received this message because you are subscribed to the Google Groups "In-Portal Bugs Team" group.

> To post to this group, send email to in-port...@googlegroups.com (mailto:in-port...@googlegroups.com).
> To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com (mailto:in-portal-bug...@googlegroups.com).

Alexander Obuhovich

unread,

Jun 8, 2012, 2:47:27 PM6/8/12

to in-port...@googlegroups.com

Yes, this actually might be the case, when paypal/atos can't reach gw_notify.php/atos_notify.php because of it.

To post to this group, send email to in-port...@googlegroups.com.
To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/in-portal-bugs?hl=en.

Phil

unread,

Jun 11, 2012, 5:34:17 PM6/11/12

to in-port...@googlegroups.com

back on this. I've performed new tests on a clean 513 install, and I can reproduce the same problem.

Here is the list of problems found:

- when GW send back info, notify script create a new session, and this new session is attached to actual order

- notify don't work correctly anyway and order stays as incomplete

- when user come back on checkout page, he's logged out if he was logged in before

All this happens on notify script level, and not because of Atos, as it happens the very same way for Paypal. And I bet it'd be the same for all GW who use notify scripts.

Then once again, I'd ask you guys to deep seriously into this problem, because actually all 5.x versions seems affected by this problem...

Envoyé avec Sparrow

Dmitry A.

unread,

Jun 15, 2012, 12:17:43 AM6/15/12

to in-port...@googlegroups.com

Did you get to the bottom of this Phil?

Still not working?

DA

Phil

unread,

Jun 15, 2012, 4:17:40 AM6/15/12

to in-port...@googlegroups.com

thanks for replying about this. As per all my tests (see previous message), it's not an Atos problem, as I though, but a global notification problem, which involve notify script behavior, which create a new session, which is then tied to order, instead of user session.

Then still not working, and now became a global In-Portal bug. I bet that nobody have used Paypal in v5.x, otherwise it'd have seen it's not working.

Envoyé avec Sparrow

--

You received this message because you are subscribed to the Google Groups "In-Portal Bugs Team" group.

To view this discussion on the web visit https://groups.google.com/d/msg/in-portal-bugs/-/wbaWr1c4ZqoJ.

Phil

unread,

Jul 4, 2012, 2:20:54 PM7/4/12

to in-port...@googlegroups.com

well, guys, no news here? I don't need such feature myself, by I thought this subject was important, as it concern in-commerce core GW management.

Le vendredi 15 juin 2012 10:17:40 UTC+2, Phil a écrit :

thanks for replying about this. As per all my tests (see previous message), it's not an Atos problem, as I though, but a global notification problem, which involve notify script behavior, which create a new session, which is then tied to order, instead of user session.
Then still not working, and now became a global In-Portal bug. I bet that nobody have used Paypal in v5.x, otherwise it'd have seen it's not working.

Envoyé avec Sparrow

Le vendredi 15 juin 2012 à 06:17, Dmitry A. a écrit :

Did you get to the bottom of this Phil?

Still not working?

DA

--
You received this message because you are subscribed to the Google Groups "In-Portal Bugs Team" group.
To view this discussion on the web visit https://groups.google.com/d/msg/in-portal-bugs/-/wbaWr1c4ZqoJ.

To post to this group, send email to in-portal-bugs@googlegroups.com.
To unsubscribe from this group, send email to in-portal-bugs+unsubscribe@googlegroups.com.

Alexander Obuhovich

unread,

Jul 20, 2012, 1:59:14 PM7/20/12

to in-port...@googlegroups.com

Ping to anyone.

I've found, that new discussion about same problem, but in 5.0.x version of In-Portal is started here: https://groups.google.com/d/topic/in-portal-bugs/MaZS_L4A3rY/discussion (from 18 June 2010).

Reading both discussions you easily tell, that original problem found in In-Commerce 5.0.x release (broken payment gw notification script) wasn't addressed in 2010 year and still happens in 2012 year on 5.1.x versions of In-Portal. Without a doubt I can safely assume that same problem still happens even in 5.2.x versions of In-Portal.

To view this discussion on the web visit https://groups.google.com/d/msg/in-portal-bugs/-/OgUUO2qPTSsJ.

To post to this group, send email to in-port...@googlegroups.com.
To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/in-portal-bugs?hl=en.

Alexander Obuhovich

unread,

Aug 7, 2012, 8:52:26 AM8/7/12

to in-port...@googlegroups.com

Ping 2. See previous ping for more info.

Alexander Obuhovich

unread,

Nov 5, 2012, 12:17:27 PM11/5/12

to Bugs In-Portal

Ping 3. No replies for 3 months in this discussion.

Phil

unread,

Nov 5, 2012, 1:15:41 PM11/5/12

to in-port...@googlegroups.com

Phil

unread,

Nov 5, 2012, 1:17:15 PM11/5/12

to in-port...@googlegroups.com

what else could I say, 2 years after it's still the same, it can't evolve magically, problem is quietly standing in v5.2 :)

Reply all

Reply to author

Forward