VAT online check for United Kingdom

  • Posts: 7
  • Thank you received: 1
22 hours 56 minutes ago #373158

-- HikaShop version -- : 6.5.2

Hello,

I am working on a solution to verify gb vat numbers, documentation here:
https://developer.service.hmrc.gov.uk/api-documentation/docs/api/service/vat-registered-companies-api/2.0

I got that working but the integration with Hikashop is not so smooth. Checking the vat code, here:
\administrator\components\com_hikashop\helpers\vat.php

I see there is integration with the online check using the trigger onBeforeVATOnlineCheck.

I have 2 issues using this approach:

1. Entering a vat number starting with the letters GB.. causes an error, specifically the error:
Your VAT number can not be used with the country you selected. Please select the right country ( CODE: GB) or make sure your VAT starts with XI
To stop that error, I commented out the line 41 in vat.php

if($zone_code=='GB') $zone_code = 'XI';

2. The vat trigger does not return the right value causing it always be true. The vat trigger reruns an array, while the code is expecting a boolean. Around line 204, I changed this:
		$rc = $app->triggerEvent( 'onBeforeVATOnlineCheck', array( &$obj, &$processed, &$vat) );
		if( $processed) {
			return $rc;
		}

To this:
		$rc = $app->triggerEvent( 'onBeforeVATOnlineCheck', array( &$obj, &$processed, &$vat) );
		if( $processed) {
			if ( in_array( false, $rc, true ) ) {
				return false;
			}
			elseif ( in_array( true, $rc, true ) ) {
				return true;
			}
		}

Those 2 core updates allowed the checks to run smoothly. Is it possible to update the vat code? Or am I taking the wrong approach with this?

Thanks

Please Log in or Create an account to join the conversation.

  • Posts: 86080
  • Thank you received: 14186
  • MODERATOR
19 hours 23 minutes ago #373159

Hi,

You are not taking the wrong approach, and both problems you found are real. We have fixed them in HikaShop, so the two core edits you had to make are no longer needed, and we have also published a free plugin that does the HMRC check, in case you would rather not maintain your own:

www.hikashop.com/marketplace/product/314...at-number-check.html

On the GB prefix: that line was written when the United Kingdom left the European Union. Only the numbers of the Northern Ireland protocol, the ones starting with XI, are in VIES, so treating every United Kingdom address as XI was the only way to check anything at all. It was wrong for everyone else, and the message even told your customers to type XI, which is not their number. Both prefixes are now accepted for the United Kingdom, and a number typed without a prefix is given XI when the post code starts with BT and GB otherwise, since Northern Ireland is not a country of its own in the address form. A GB number then reaches the online check, and since VIES cannot answer for it, HikaShop leaves it on its format check and writes a line in the log instead of refusing it, which is what it already does when VIES is unreachable. A plugin answering on the trigger takes over from there.

On the trigger: you are right, and your fix is the right shape. triggerEvent returns one answer per plugin, so the array was handed back as the verdict and array(false) read as true. It now refuses the number when any plugin returned false, accepts it otherwise, and displays the message you left on the object, the way the VIES branch does. So if you keep your own plugin, set $processed to true, set $obj->message when you refuse, and return true or false.

Both changes are in the 6.5.2 published today, so download HikaShop again from your member area before installing the plugin. If you want to be sure of what you are running, open the configuration page of HikaShop and the version number at the top of the Main tab should read: 6.5.2 [2608261812], and the ten digits in the brackets are the date and time of the build.

What our plugin does, which may save you some work either way: It answers only for GB numbers of 9 or 12 digits, so the numbers of the other countries and the GD and HA numbers of the government departments, which the API does not hold, keep going to VIES. A 404 refuses the number, a 400 refuses it as malformed, and anything which says nothing about the number itself, expired credentials, a 429 or a 5xx, follows a setting which defaults to accepting rather than blocking your checkout. The access token lasts four hours and is stored with the settings instead of being fetched on every checkout, and a token revoked early is renewed on its own. If you enter your own VAT number in the settings, it uses the verified lookup, so HMRC returns a consultation number proving you made the check, which is written in the log with the name and address it holds.

One thing to plan for: version 2 of the API is behind authentication, so you register your own application on the Developer Hub of HMRC, subscribe it to the "Check a UK VAT number" API and accept their terms. That takes around two weeks.

Please Log in or Create an account to join the conversation.

  • Posts: 7
  • Thank you received: 1
3 hours ago #373164

Wow, thanks for the very quick reply and solutions. I will be using the plugin, no need to re-invent the wheel.

One issue I saw while testing is if the number of digits in the vat number is not 9 or 12, it passes. I am in sandbox, so using mock vat numbers. Here are results of these tests:

- GB553557881: real mock number and passes
- GB553557882 - changed the last number to a 2 to force a fail and that works
- GB5535578811 - Added an extra digit to the real mock number and it also passes

I think case 3 should fail, if the number of digits is not 9 or 12 then it is invalid.

Please Log in or Create an account to join the conversation.

Time to create page: 0.059 seconds
Powered by Kunena Forum