WooCommerce transactions failing

[blatka]

Hi. I'm using the C&P Gateway for WooCommerce and have been experiencing erratic behavior with orders. A few failed today.

Here is an error code posted in my WooCommerce order backend:

Click & Pledge payment failed (Transaction ID: ). Payment was rejected due to an error: “The ‘urn:APISchema.xsd:IPAddress’ element is invalid – The value ‘2a02:1205:34f6:c420:e40d:59bf:4cac:2494’ is invalid according to its datatype ‘NormalizedString’ – The actual length is greater than the MaxLength value.”.

and then 90 minutes later, this got posted in the same order:

Unpaid order cancelled – time limit reached. Order status changed from Pending Payment to Cancelled.

The user told me he tried a few different browsers with no luck. There was no corresponding C&P data record for this.


A few days ago, this order failed with this error (and there have been intervening successful orders):

Click & Pledge payment failed (Transaction ID: ). Payment was rejected due to an error: “The ‘urn:APISchema.xsd:IPAddress’ element is invalid – The value ‘2602:0306:3890:1730:18f2:bb4f:821c:dbc9’ is invalid according to its datatype ‘NormalizedString’ – The actual length is greater than the MaxLength value.”.



AND EARLIER - IS THIS RELATED?...
There was another attempted donation that did get through to C&P data record. This does not appear in my WooCommerce orders - but here is the error code that was posted along with the record:

Upsert failed. First exception on row 0; first error: CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY, npo02.OpportunityRollup: execution of AfterInsert

caused by: System.AsyncException: Future method cannot be called from a future or batch method: npo02.OpportunityRollups.rollupContactsandHousehol dsForTrigger(Set<Id>)

(npo02)
: []

Here is the beginning of the XML in C&P data (obviously not woocommerce)"

<?xml version="1.0" encoding="UTF-8"?>
<CnPTransactionData><Version>40</Version>
<Application><ID>CnP_FaaS</ID>
<Name>CnP_FaaS</Name>
<Version>FaaS.20140930.001.036.001.000.036</Version>
</Application>

The C&P Data ID: Transaction-2564

I've granted access in salesforece to look around.

Thanks

[CnP.Support]

Good day!

Is this using your form in a mobile environment?

The error regarding the IP address is strange since 2a02:1205:34f6:c420:e40d:59bf:4cac:2494 is NOT an IP address but is a Mac address. I cannot think of any reason a desktop browser reporting the MacAddress -- WooCommerce is reporting this to our API and we need the IP address to determine the origin and analysis for our fraud detection.

As for the other error-- that is NPSP 2.x which is no longer supported by NPSP. They have released 3.x and it resolves the issue you are reporting. NPSP will not resolve this issue as it is in the old release and not in 3.x so we are told the issue will not be resolved in the version you have. You will need to upgrade to NPSP 3.x

Please see: https://github.com/SalesforceFoundat...lus/issues/312

Please let us know where the source of the previous error is. It is strange.

[blatka]

These orders that failed are not recurring (per the link you cite) - they are new orders. I looked at all the orders that failed (i have 6 of them) - they all list a Mac address instead of an IP. For example:

"Payment via Payment Method. Customer IP: 2601:0401:4401:cf97:b1a6:aa41:6c79:e03e"

I'm trying to reach the customers with the failed orders but I did a test order from mobile and it was successful (and showed an IP, not Mac address). I will get in touch with woocommerce - but any other ideas - I'm all ears!

I will upgrade NPSP, thanks.

[blatka]

I heard back from the donor whose orders failed. He was trying from Switzerland. I wonder how that could have affected the missing IP number? He had tried on Safari and Firefox on a mac.

[blatka]

Gents:

So it turns out the long number being returned by my failed orders is NOT a Mac address, but an IPv6 address. This according to both woocommerce support, and from my server host. Woo Commerce suggested I checked with my host to verify this, and they say the number returned is indeed an IPv6 address, and the gateway will need to be modified to accept these longer addresses. There is no translating them into regular IP addresses.

As noted earlier in this thread, the user was in Switzerland, and it's true the IPv6 addresses are being used more and more worldwide.

FYI here is the response from my server host:

Basically, ( and it's a very , very confusing topic ) IPv6 is on it's way to replacing IPv4, many ISP's ( even more so outside of the states ), are jumping on the IPv6 bandwagon, they are more plentyful, and are helping relieve the global shortage of IPv4 addresses, we've all but used them up. Because of this, they have these new protocols, and yes, they are indeed longer, which seems to be the issue here. Unfortunately, we can't just demand they return an IPv4 address, in fact, it's completely out of our hands. The problem here is your gateway simply isn't setup, or able to support the ability to accept IPv6 addresses as a returnable address. However, while This is just my opinion, based on your error though, it doesn't look like they are blocking the ip address itself, but they are simply putting in a blanket error checking for length. So, if you talk to them, they should be able to help give you a simple solution. That's not to say they have that blanket error their for a reason on their back end though, as obviously I can't see that.
Bottom line, I'd love more than anything to be able to make this happen for you, but unfortunately, this is something that gateway provider needs to fix, as their systems don't appear to support it.

SO, are you doing a check for length to verify IP address? Seems like a straght-ahead fix. Let me know what you think.

Thanks!

[blatka]

Hello. Have you seen this new development in the post above? Thanks.

[CnP.Support]

Good day!

Our API team is evaluating this and trying to figure out a way to handle this.

Yes we know the IP V6 is coming but it is hardly in use yet but it is coming.

We will update this once we have an answer. The team is working on this and trying to figure out how to deal with it.

[blatka]

Hi. Me again. Any updates on a revised gateway?
Thanks

[CnP.Support]

Good day!

Based on our review it seems like you are sending your own IP address (your server's IP address). The IP address needs to be that of the client machine and NOT yours. The fraud system uses the IP V4 and that is not our system but 3 other companies and none accept IP V6 yet.

Please use the client IP since that IP is used for fraud and if you send your own IP our system will block all transactions thinking you are under attack since all payments are coming from the same IP. Let us know which IP is being used.

[blatka]

Not true! I will have 4-7 successful transactions that show a regular IPV4 address, and then I get a transaction that fails because the user has an IPV6 address. Got one last night! This is now 20% of all orders! I am missing out donations and transactions regularly because of this. I attached a screenshot from a failed WooCommerce order showing the user's IP address that is clearly an IPV6 address. My server's address is 72.249.53.153. When the transaction fails, here is the message: Click & Pledge payment failed (Transaction ID: ). Payment was rejected due to an error: “The ‘urn:APISchema.xsd:IPAddress’ element is invalid – The value ‘2601:0404:c302:dae0:586a:c860:adf1:f5e9’ is invalid according to its datatype ‘NormalizedString’ – The actual length is greater than the MaxLength value.”.

Besides, how can I send my own IP address to C&P with a transaction? I have no control over this.

Here are examples of other failed orders and the user's IP address:
Order #6996 details: Payment via Payment Method. Customer IP: 2620:0160:eb08:0000:0000:0000:0000:000a
Order #6909 details: Payment via Payment Method. Customer IP: 2602:0304:45f6:1400:2558:647a:80f2:6b98
Order #6904 details Payment via Payment Method. Customer IP: 2604:6000:6a44:ee00:89c7:918e:cb28:577d


Here is a fraud service that appears to be using IPV6 addresses: https://dev.maxmind.com/minfraud/
This page shows that this is how they are handling their IP address check, by truncating to the first 4 segments of the address: "INPUT: The length of the data passed to us does not matter for most fields. We will truncate inputs as needed. The IP address of the customer placing the order. This should be passed as a string like “44.55.66.77” or “2001:db8::2:1”."



THanks

[CnP.Support]

Good day!

We use MaxMind and 2 other services in connection with our algorithm for fraud.

At this time we have incompatibility with other 3rd party vendors as well if we allow this. One solution is possibly that we allow it to be passed and then disable those third parties.

We are still working on this issue & will update this once all aspects are compatible.

[blatka]

Hi there. September 1 - four months since my first post, and two months since your last post - any word on a fix for this? I still have every 4th or 5th order/donation on my site failing because of the IPV6 IP addresses. I so need this fixed.

How about creating a version of the gateway that bypasses the two non-compliant services so that just the people that are having this trouble (there has to be more than just me, right?) can get back to raising funds for our nonprofits? Or doing whatever it takes to make this usable? PRETTY PLEASE?

[jenntaylor]

Hi there, just adding my voice to this in hopes of escalating it. I'm getting the error as well, I am happy to provide screenshots etc but it's exactly the same error as described by blatka. Any updates please?

[blatka]

I'd like to say THANK YOU THANK YOU THANK YOU to Click & Pledge for solving this issue. I am now successfully processing orders from people with IPV6 addresses! BACK IN BUSINESS!!
Bill