Working on Gold.. 2 issues so far

[compunerdy]

The first sounds more like a bug..

All payments made via chase paymentech show as unpaid. This may not be true on new orders (cant test currently) but converting my 7.0.7 database shows them like this..

Order Total: $13.48
Balance: $0.00
Payment Status: Unpaid

Last Payment: MasterCard xxxx
Amount: $13.48
Status: Captured
AVS: Unavailable (U)
CVV: Match (M)

Shows zero balance and captured payment but marked as unpaid.. same order in 7.0.7 shows as paid.


The second is a report that needs to be changed. I had said previously that the WA state tax report was fixed but I was wrong. It needs to show the total order amount per loc code and not total tax collected as these are the numbers WA state asks for. It needs to be order totals before shipping and tax but after coupons, etc.. This year I just ended up learning how to write a SQL statement to get past this issue but I would like to see it built in..

Code: Select all

select LineMessage,sum (ProductSubtotal) from ac_OrderItems, ac_Orders where ac_OrderItems.LineMessage is not null and ac_OrderItems.OrderID = ac_Orders.OrderID and OrderDate between '2012-01-01' and '2012-12-31' group by LineMessage

[mazhar]

I believe this was happening due to minor difference in how payment status view is handled in AC 7 and AC 8. This will be automatically resolved in R4. You can quickly confirm this by making a small change in your website code for now. Edit your Website/Admin/Orders/Default.aspx.cs file and locate following method

Code: Select all

protected string GetPaymentStatus(object dataItem)
        {
            Order order = (Order)dataItem;
            if (order.PaymentStatus == OrderPaymentStatus.Paid) return "Paid";
            if (order.Payments.Count > 0)
            {
                order.Payments.Sort("PaymentDate");
                Payment lastPayment = order.Payments[order.Payments.Count - 1];
                return StringHelper.SpaceName(lastPayment.PaymentStatus.ToString());
            }
            return order.PaymentStatus.ToString();
        }

and update it like

Code: Select all

protected string GetPaymentStatus(object dataItem)
        {
            Order order = (Order)dataItem;
            order.Recalculate();
            if (order.PaymentStatus == OrderPaymentStatus.Paid) return "Paid";
            if (order.Payments.Count > 0)
            {
                order.Payments.Sort("PaymentDate");
                Payment lastPayment = order.Payments[order.Payments.Count - 1];
                return StringHelper.SpaceName(lastPayment.PaymentStatus.ToString());
            }
            return order.PaymentStatus.ToString();
        }

Save the change and then run Admin/Order/Default.aspx page and see if its showing proper status for order or not.

[compunerdy]

That fixed it, thanks!!

[sfeher]

I'm curious to know if your "cannot test" statement is for reasons similiar to mine:

Using Chase Paymentech for the gateway processor and presently developing on an IP address. No domain, and no SSL presently active on the IP (of course).
When we try to 'test' the gateway processor, I'm getting an error that the "Preconditions failed". Not sure if this is an AC error (there's no mention of that error anywhere in the forums) or if this is actually a response being returned by Paymentech.

I suspect that this is an AC response, because the source code seems to require the SSL as a safety check (which, IMO, is smart). Of course, the drawback is that we cannot test until the domain, ssl, and new cart is launched. Ideally, I'd like to check the payment processing before we launch.

Any feedback or thoughts on this?

Thanks!

[mazhar]

What about trying it with self signed certificate on your development machine for testing purpose ?

[sfeher]

I think that I'll have to try that, yes....
But does that confirm that Able does indeed force the SSL requirement for the credit card gateway and throws that error -- Precondition Failed -- if the SSL is absent?

[sfeher]

I've issued a self-signed certificate to the development machine, assigned it to the site, etc.
Using Google Chrome, you get the following experience:
When you call the HTTPS:// on the IP, the browser (I presume IE, FF, and Safari too) will throw an error claiming that the signature authority isn't trusted (because it's self-signed, of course).
Thus, the browser displays the warning that you should not continue -- which I choose to proceed anyway.

Attempt to go through checkout and you still get the error that the "pre-condition failed". Again, I suspect that this is actually an AbleCommerce response and not something from Chase Paymentech, but I can't be 100% sure.

[mazhar]

I think that I'll have to try that, yes....
But does that confirm that Able does indeed force the SSL requirement for the credit card gateway and throws that error -- Precondition Failed -- if the SSL is absent?

No I just gave a suggestion about setting up SSL for development purpose.

[sfeher]

Still no dice here....

I suspect that I cannot test until we're live. Again, not ideal.....

[sfeher]

Mazhar --

I'm beginning to suspect that the DLL for Paymentech Orbital might be incorrectly built. No matter what we do, we cannot connect to their server and we're failing to get a valid payment response.

Communication with Paymentech has been challenging, to say the least. But our first point of interest is the destination URL for the web service. Can you confirm the destination URL that's being sent? According to Paymentech they're not seeing any requests from our account coming in at all -- raising suspicions that we're targeting the wrong submission URL. If we were passing bad information, we'd at least see errors from them.

Any assistance you can give here is appreciated.

[mazhar]

Did you tried to turn on the debug mode of gateway and capture the information sent/recieved between payment provider and ablecommerce? If you didn't then turn on the debug mode in merchant admin Administration > Configure > Payments > Gateways > Edit Gateway and then try to place an order using payment provider. Finally go to Website/App_Data/Logs folder where there should be text log file for chase payment containing debug information. Have a look at log and see whats being sent and recieved.

[sfeher]

OK --
I have the log error and it appears to include plenty of data for the transaction. I had not remembered that the log file would be written while in Debug.... thanks for that (some days, I'd forget my right arm!)

Let me send this XML output to Paymentech to see why it's not responding....

Thanks

[sfeher]

I've (finally) gotten Chase to accept payments into their system. That's working now. Thanks, Mazhar for all your help.

Three things happened to cause this issue:
All, I should say, where part of miscommunication on Paymentech's part.

1.) There is a merchant number that is critical for the merchant, and the AbleCommerce interface asks you to add that merchant number into the setup screen. However, what Paymentech WANTS you to send is called a PNS # and it's not the same as your merchant account.
Fair warning to future Paymentech users: ENSURE that you get the PNS # from your sales reps on setup. That's the number you must enter in the Merchant ID field.

2.) There's a BIN allocation -- Salem (000001) or Tampa (000002), I believe. Our rep told us the wrong one. Only when we finally sent the logged XML to Paymentech were we aware of the miscommunication from our rep. (sigh). Paymentech uses one BIN for USA transactions and the other for Canadian. Use the wrong one and ....... you get nothing.
Make sure you have the right BIN.

3.) Paymentech uses IP-based security -- they only allow transactions to come from explicitly defined transactions. Smart idea. But the Paymentech support personnel will ask your for your website's IP address.... and like an idiot, I gave them what they asked for. The problem is, they need the server IP address. In their defense, I should have realized that this server IP is what they really needed, even if they didn't ask for it specifically... Giving them the wrong IP will kill any transaction you try to send......


Paymentech was not easy (IMO) to work with, but banks often choose gateway providers for alternative reasons than I would. Suffice to say, if you deal with them, I would recommend getting a case # on the first call. That does make it much easier to get traction on subsequent follow-up calls.

Good luck, friends!