Clearaccept fields not displaying correctly and [object Object] overlay

[graphicz]

Site has Clearaccept fields not displaying correctly and [object Object] overlay.

Has anyone kindly got a solution for this? :





Thank you!

[Mike Hughes]

Hi Jonathan,

This isn't the problem where ClearAccept cannot be run in test mode is it?

[zgap111]

I had this problem a while back... (a problem with v18.2.2)
I can see this:

Our developer has found several reports of ‘invalid phone number’ on both sites. This is due to ClearAccept phone number validation. There is no need for the phone number to be passed to ClearAccept. We cannot guarantee that this is the problem that the buyer encountered but it is the only CA error in the recent logs and it happens on both sites. Please take appropriate backup before making the changes.

• Edit OCCClearAccept.pl in the site CommonOCC folder
• Search for

{'BillContact'}{'PHONE'}

This will match on 2 lines, delete both lines. The 2 lines will be

$hParams->{'paymentMethod'}{'billingDetails'}{'phone'} = $pContacts->{'BillContact'}{'PHONE'};

• and

$hParams->{'customerInfo'}{'phoneNumber'} = $pContacts->{'BillContact'}{'PHONE'};

Save the file and update the site. Please monitor and let me know if this helps.

I remember the code wasn't 100% a match to their instructions but I kind of understood what needed to be done

I hashed the two lines:



and I also see this later on:

The phone number probably causes an error before the card fields are displayed.. Our developer has come out with another idea. To avoid having to upgrade to 18.2.3 to get the better error reporting, I have attached a Design Snapshot that will change a single layout ‘Clear Accept Fields’. The change corrects the error reporting that may occur when the buyer clicks Confirm, this is where ATM the 'object, object' message occurs and should now give a meaningful message.

I recommend making a copy of the current layout and then taking a snapshot before importing the design snapshot

This design snapshot may be applied to any 18.2.2 site to improve the error reporting.

Attached copy (cannot upload *.acd, so you need to rename it back)

[graphicz]

Hi Mike - It is in production mode.
And I am afraid the PHONE fix didn't help either

[graphicz]

Gary sent me the same fix and his didn't work either!

Another little ClearAccept rush of optimism turning to nothing - again...

[zgap111]

Searching my emails I found this...


But this one only popped up occasionally when troubleshooting why the card fields took over 12 to 20 seconds to appear
(on a VPS server = setup due to getting PCI-DSS compliant, there's no animated "wait" indicators = customers how were in a hurry abandoned and chose Bank Transfer)
- even with the design snapshot applied, it was still giving this vague description for the error.

The phone one was the result of them seeing it in the logs - hopefully they can again.

I know SellerdeckPay is more finicky with the data (eg. non-UK characters in the name/address, not using ISO_3166-1 country codes) compared to the sunsetted Sellerdeck Payments.

[graphicz]

Well MeaCulpa - My Bad

I placed security headers in the htaccess file and two lines were missing a colon compared to Gary's KB post:

Header set X-Content-Type-Options "nosniff"
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"

Versus

Header set X-Content-Type-Options: "nosniff"
Header always set Strict-Transport-Security: "max-age=63072000; includeSubDomains"

Strange as I sourced mine off the interweb - hey ho

All now works with these headers:

# Security Headers
<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
Header always set X-Frame-Options "SAMEORIGIN"
Header set Content-Security-Policy: "frame-ancestors 'none'"
Header set X-Content-Type-Options: "nosniff"
Header always set Strict-Transport-Security: "max-age=63072000; includeSubDomains"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "accelerometer=(self), camera=(self), geolocation=(self), gyroscope=(self), magnetometer=(self), microphone=(self), payment=(self), usb=(self)"
</IfModule>

And A+ at https://securityheaders.com

[EdHarrison]

Would this possibly be why my security headers failed to verify?

Unfortunately I raised a ticket but got advised to try to find someone more familiar with ht access. (Despite them being my host)!

[graphicz]

I have edited my post at https://community.sellerdeck.com/for...143#post557143 to include the errant colons.

At present Ed you have Gary's headers at https://community.sellerdeck.com/for...can-compliance in your htaccess

[EdHarrison]

Oh brilliant so they are working OK hopefully?

Thank you

[graphicz]

You can test at https://securityheaders.com/

[zgap111]

The colon! Well done.

I only had one line that had a colon

Header set Content-Security-Policy: "frame-ancestors 'none'"

I've changed all to have a colon, scan still is green and hopefully no (new) problems.

[graphicz]

It's a bit crazy because those headers were sourced from the internet as they were and passed securityheaders.com.

What a nightmare we have had imposed upon us...

[Mantra]

With reference to Knowledge Base > Sellerdeck Payments post:
https://community.sellerdeck.com/for...ri-and-firefox

SD Version 16.1.3 & 18.2.2
For those that have implemented the change in Knowledge Base > Online Store Issues post:
https://community.sellerdeck.com/for...s-pci-dss-scan

Sellerdeck please confirm that the Standard Javascript Header Code(s) that need to be changed are:

<script defer src="https://sandbox-scripts.clearaccept.systems/hostedfields.1.32.1.js" integrity="sha512-jN1ba8Dn/2scsRsCjf4EAoPC6P1Uc7lm/q1v3FVyJeJZ29s6N9RRrmvegOyxsbKIpyPlfF2m+TyZ5+0zdu7dYQ==" crossorigin="anonymous" > </script>

AND

<script defer src="https://scripts.clearaccept.com/hostedfields.1.32.1.js" integrity="sha512-eVKVzHuKCHTaFKYEOVauF2ayZiVdxa3HhK9gl7MF7nKAvtRvaVdNNviuk9sIVdHD/mqipHFhqrAEiYvdI03a/Q==" crossorigin="anonymous" > </script>

Tested code above using iPhone IOS 18.5 Safari - no problem so perhaps no need to make the change just yet!

[gcamley]

I can confirm that those are the lines to change for those that had already upgraded from the original ClearAccept libraries