Re: Lite Interface & 4.5.5 Issue
 

No, I have major issues with Xpayments 1.06, api 1.2, Paypal Pro and XCart Gold 4.5.5 with OPC and standard template (books and magazine).

Qualiteam have failed to reply to my bugtracker in over two weeks and I've had to resort to Paypal Standard for my two 4.5.5 sites. I'm not a happy bunny at all and not sure what to do. I have lost ALOT of money and customers are getting frustrated....I refuse to pay for Xcart support for something that should work out of the box.

What confuses me is that my 4.5.4 site with Xpay api 1.1 Paypal Pro works fine. Does any one know if you need to specify the callback i.p of the Xpayments server as the logs are throwing up callback errors? I just keep getting 403 errors from 4.5.5 site when submitting a payment. I don't want to have to keep making real transactions just to see what is happening.

I would appreciate anyones advice right now!

For those having issues with Xpayments....
 

Hi all

I was having terrible trouble with Xpayments connector/Xpayments.

I have four sites running 4.5.4 and 4.5.5. One of my sites also has Xpayments 1.0.6 installed on it. I am using Paypal payments Pro.

I was receiving callback and 403 errors etc. on three of my four sites. Lite interface kept switching off on three of them and I couldn't understand it. Weeks have passed with no word from Bugtracker or forums and I have had to deal with loads of frustrated customers and have lost alot of sales.....

But today I had a breakthrough and thought it may help other people struggling with Xpayments etc.

I have discovered that the "optional" field for callback i.p in Xpayments connector isn't so optional. My sites all have dedicated i.ps and have just discovered that you do have to use the i.p of the XPayments install in sites not running under that i.p.

This has angered me immensely as nowhere in the Xpayments manuals etc. does it explain that you may have to use this field if you are running another of site under a different i.p connecting to one Xpayments install. "Optional" does not indicate "may be necessary" Qualiteam!

Obviously, I am not sure about other payment processors than Paypal Payments Pro, but it you are unable to complete a sale successfully or find that Lite interface keeps unticking you may want to fill this in if you are running different sites under different i.ps and connecting to one Xpayments install

I have billed myself 3 x ё0.20 successfully and at last my customers will actually be able to pay!

Not very happy with Qualiteam/X-Cart right now. They could do more to help without charging us. Bad documentation has caused me to loose a small fortune and customer trust.

There are many people having issues like mine on these forums. I only hope that my little breakthrough may help a few of those about to pull out their hair. :wink:

Re: For those having issues with Xpayments....
 

Which IP address did you enter?

x-cart server IP?
x-payments server IP?

for example, I have an IP address for x-payments (checkout.domain.com) and a different IP for x-cart. Did you enter the x-payments (checkout.domain.com) IP in this field?

IS THE PURPOSE of this field security, or is there something functional also going on here?


WHICH IP addresses? X-payments? The store? The merchant gateway?

Re: For those having issues with Xpayments....
 

Hi carpeperdiem - Sorry if I wasn't clear enough.


I used the X-payments server i.p in all my sites X-payments connector.

www.mysite1.com - callback i.p in X-payments connector = X-payments server i.p (eg. 127.0.0.1)
www.mysite2.com - callback i.p in X-payments connector = X-payments server i.p (eg. 127.0.0.1)

My site that is on the same i.p as Xpayments install doesn't seem to need the i.p in the field to work so it may well be a security/Paypal thing but who knows with Xpayments eh? :wink:

Re: For those having issues with Xpayments....
 

127.0.0.1 is localhost. Maybe this is the reason for the other sites not being able to properly connect?

The IP field on the Connector settings is the IP of the X-Payments installation. It is optional I believe but it is very much advisable to provide considering that X-Payments has to have its own dedicated IP...

Re: For those having issues with Xpayments....
 

Hi cflsystems


Just to clarify I used 127.0.0.1 as an example i.p. Obviously, as you have pointed out, this should be set to the i.p of the Xpayments installation which is what I did. Sorry if this was confusing.

I'm am concerned that Qualiteam have marked the field as optional when really if you are running lots of sites on different i.ps pointing to one Xpayments install it is not. The explanation in the manual is not clear for less experienced users. It may be something they should modify and explain a little better perhaps? Could save many people a headache....:-)

Re: For those having issues with Xpayments....
 

Ok :) that explains it

It wouldn't make sense for the IP to be mandatory since this is the callback IP and X-Payments uses the url not the IP to connect and process. The callback IP is for increased security - just to make sure that the response is coming from the exact same X-payments installation... Since X-Payments should be installed on its own dedicated IP.

I have installed few already and every time connection is ok even without the IP callback being set. So maybe it is something with your installation? Although I would recommend having this callback IP set....

Re: For those having issues with Xpayments....
 

The Help Note in my 4.4.4 says

But the manual at http://help.x-cart.com/index.php?title=X-Cart:X-Payments_Connector supports what 'loopsound' is saying.

Why would they allow multiple IP addresses if the field is looking for only the single IP address of the X-Payments installation. This is not logical.

Re: For those having issues with Xpayments....
 

This was a mess back when I first started using X-Payments in Jan 2013. Even QT couldn't figure out what IP was supposed to be in the "X-Payments Call back" field, they ended up doing a trial and error until they got one that worked. I believe it ended up being the IP of my X-Cart installation, which was the complete opposite of what you would reasonably expect , but that what worked and has worked ever since.

Hope that helps, aaaargh.

Re: For those having issues with Xpayments....
 

Since the field allows multiple IPs, I put in both the X-Payments IP (first) and the store IP (second). I still get callback error emails on occasion and don't know why.

Re: For those having issues with Xpayments....
 

Hi Everyone,

We are going to publish a knowledge base article about callbacks, calls, etc X-Payments does in order to explain users how it works and what all those callbacks are.

While the article is being created at http://help.x-cart.com I am sharing a Google doc explaining all of that here:
https://docs.google.com/a/x-cart.com/document/d/170A0kl3kK6cZzuFfq9s1vNAaO8hWtjNE6E1Psrktj98/

It should help everyone to understand e.g. what to put into "IP addresses for X-Payments callbacks"in X-Payments connector module settings

I hope it will help.

Re: For those having issues with Xpayments....
 

Thanks Alex! That is a great start at an article to help everyone! I will be sure to check the final version to see how it compares to my store which is working using a particular IP in my X-Payments Callbacks field.

One small, request, maybe out of scope, how difficult would it be to include the status of the order# as it relates to the activity of the checkout process (therby explaining the relationship between the order statuses is XC and the order statuses in X-Payments). I know I would benefit from this greatly to understand why the lists of order isn both systems don't always coordinate clearly.

Re: For those having issues with Xpayments....
 

Alex...Just checking up on your document...

When I get an error email sent to me that says:

***************************
Date: Tue, 23 Jul 2013 18:18:08 -0500 [07/23/2013 06:18:08 PM CDT]
Subject: Callback to online store is failed.
Callback to "http://<onlinestore>/home.php" online store is failed.

This notification has been sent by X-Payments installation at "<x-payments domain>" .
***************************

I got two of these emails within 9 minutes of each other.

According to your document I should see some explanation of this incident in the <xpay-dir>/var/log/admin/2013-07-23/ or <xpay-dir>/var/log/payment/2013-07-23/ or <xcart-dir>/var/log/x-errors_xpay_connector-130723.php. But none of the files or log files in any of those locations show any kind of error.

Can you explain this? What am I looking for? Am I looking in the right locations?

Re: For those having issues with Xpayments....
 

> One small, request, maybe out of scope, how difficult would it be to include the
> status of the order# as it relates to the activity of the checkout process (therby
> explaining the relationship between the order statuses is XC and the order statuses
> in X-Payments). I know I would benefit from this greatly to understand why the
> lists of order isn both systems don't always coordinate clearly.

David, it is configured at X-Payments Connector settings. See "6. Establish mapping rules." at http://help.x-cart.com/index.php?title=X-Cart:X-Payments_Connector#Configuring_X-Payments_Connector

Re: For those having issues with Xpayments....
 

Thank you Alex, but I am aware of the mapping rules. The extra information I am looking for is similar to the following:

1. at what point in the checkout process is the XC order # actually get assigned?
2. at what point in the process does XP become aware of the XC order #?
3. if the cc transaction does not go through, does the order# stay in XC, what about in XP?
4. what happens to the order# in XC and XP if the customer abandons the order process at some point?
5. what happens to the order # in XC and XP if the customer makes multiple attempts to get the cc transaction to go through and is eventually successful?

Things like that, it seems such information might be able to be added to the diagram in the document you are putting together that shows the XC/XP process flow.

Re: For those having issues with Xpayments....
 

1. Order # is assigned as soon as customer clicks on "place order". This is way before they rich any payment processing.
2. After order is actually placed within XC orders tables, some emails are send (if set to be send, like initialized orders), some other internal tasks are done - like points, quantity decrease, etc.
3. Yes it does.
4. If customer abandons order before "place order" there is no order # assigned, nothing has happened; if they leave at the CC info screen - order has been placed within XC already and it will show as initialized or queued but stays in XC; it will also show in X-Payments as cancelled (or whatever status is assigned to it for this).
5. This will create multiple sequential order # - last one will be successful, all previous attempts - cancelled, failed, declined...

Please note though that this is not entirely X-Payments fault - it is how XC deals with orders and yes it is wrong as order record is created first before anything else happens...

Re: For those having issues with Xpayments....
 

David, is this an exercise in trial lawyering?
(never ask a question you don't know the answer to?)
or the inverse: ask the question that you know the answer to, just to get the guilty party to admit to it in public...

I think the latter.

We know that XPC ajax and X-Payments order flow is flawed. I invested in Altered Cart C1 and C1XPC to solve some of these very issues. But not all.

Until X-Cart invents a new checkout user experience, x-payments' hands are tied.

I think XP should wait for xcart to fix the checkout.

Re: For those having issues with Xpayments....
 

My intent was not malicious in nature at all (no underlying intent).

I truly thought that Alex's document was helpful. I am currently trying to cleanup some of the 'droppings' in terms of orders that X-P lists on its Payment Details page that say they are Status="New", but in reality I believe they exist as a result of XC telling XP there was an order coming even before the customer ever attempted to provide cc details. Accoring to the definition of "New" in XP its says...

"New – The status indicating that the payment gateway has been asked to make the payment, but the result is not known yet (the payment gateway has not answered or the admin has to process the payment manually). "

When in reality the "payment gateway WAS NEVER asked to make the payment" in these cases.

I just want to clean up my stuff every 6 months or so to keep things lean and mean.

Providing this kind of visibility in Alex's document would help lots of other people do the same, once they undersatnd why so many "New" entries exist in XP.

To your point, I wish it didn't work this way, but it does and so you have to clean up the "droppings" every once in a while.

Re: For those having issues with Xpayments....
 

I was trying to be funny. That failed.
:-)

But there is truth in the question(s)

X-P can't help you until the checkout works without hoop jumping.
Altered Cart XPC solved some of these issues. Some.

Re: For those having issues with Xpayments....
 

The humor was not lost ;-). It was very much appreciated. It has been a long day. Time to go home for me and have a beer. We'll go at it again on Monday!