Our new 2.x version of the GreenPay WooCommerce Gateway plugin for Wordpress/WooCommerce platforms has a bunch of great new features allowing us to take advantage of the WooCommerce REST API to dynamically update the status of your WooCommerce Orders as various processing steps happen in Green. 


Because these features use the WooCommerce REST API, our plugin now requires REST API access and valid credentials in order to allow the gateway at checkout so you may find that these values aren't setup when you upgrade. If you are having trouble or seeing the errors related to the WooCommerce REST API when attempting to add those credentials, then this article is for you! 


The first item to check is that you have the correct credentials! When you generate REST API Credentials during the process outlined in our Installation and Configuration Documents you'll receive a Consumer Key and Consumer Secret. These values should be copied and pasted without any additional trailing or leading spaces or characters. When you add them into the GreenPay configuration, the Consumer Key goes in the WooCommerce REST Client ID field and the Secret goes in the WooCommerce REST Secret field. 


If you have verified that your credentials are correct and you're still receiving the above error, the next setting to check is your Permalinks. In your Wordpress Admin section go to Settings > Permalinks and make sure that your setting here is set to Post Name. If this was not the case, change it and make sure to hit the Save Changes button to have it take effect and then try to update your settings once more! 


If you are still receiving the same error, then it's likely there is a server misconfiguration problem and you may need to enlist the help of your server administration team or IT department to complete the next few steps. At the bottom of this article are a few possible solutions that may help you in this matter. Please note that the following steps, tests, and possible fixes are run and/or implemented at your own risk. Green cannot be held liable for any issues related to or potentially caused by running or implementing the commands below as all fixes will be specific to your server environment.


In order to troubleshoot where the issue is, we'll start by running a few console commands: 

  1. In a console with the cURL command or using an HTTP request tester like Postman, we'll make a request to your store's WooCommerce REST URL. Run an HTTP GET request to https://<yourdomain.com>/wp-json/wc/v3. The console command would look like: 
    curl https://example.com/wp-json/wc/v3
    If this command returns an error like an HTTP 400, 401, or a JSON response with an error then this indicates that your REST API URL is not setup correctly likely due to a permalink issue. You may need to reach out to WooCommerce directly to discuss the error you receive as we cannot help. If you receive a valid JSON response for the index of your endpoint, then go on to Step 2.
  2. Let's try to call for system status to get more information. Make a GET request to the endpoint for system_status. In cURL, this command would be:
    curl https://example.com/wp-json/wc/v3/system_status \ -u consumer_key:consumer_secret

    Where consumer_key and consumer_secret are to be replaced by your exact credentials. If this returns a successful response, please contact Green Support at support@green.money! If this also fails with an HTTP 400, 401 or a JSON error like "Cannot list resources" then this will either be due to incorrect credentials or a server misconfiguration issue. Move on to step 3 to diagnose which of those two is the case!

  3. Let's run the same call, but instead of passing the credentials using Basic Authentication, we'll pass them as query parameters.

    curl https://example.com/wp-json/wc/v3/system_status?consumer_key=<yourkey>&consumer_secret=<yoursecret>

    Of course make sure to replace "<yourkey>" and "<yoursecret>" with your REST credentials. If this returns an error like a 400, 401, or JSON stating "Cannot list resources" then this is an issue with your credentials. Please generate a new set of credentials and try again.

    If passing the credentials in the URL returns a successful response then your server configuration is failing to respect the Basic Authentication scheme used by the WooCommerce REST API. For security purposes, we do not allow passing authentication via parameters so you will need to get with your server administration, webhost, or IT team to have them correct your configuration. The changes required for this will be unique to each server/environment and as such we cannot give an exact answer as to what will fix this for you but below will be some possible fixes to give to your server team.


Possible Server Configuration Problems

Issue #1: Caching Plugins are Removing Headers

Some caching plugins will remove headers when serving up cached content. In certain configurations, these plugins will remove them completely. Common plugins to look at here will be W3 Total Cache or WP Supercache. Check with any plugins you have installed for caching and attempt disabling them and retrying. These plugins usually have an option in their configuration somewhere involving headers that you can fiddle with that may help but you may need to consult with your IT Team to ensure there are no unwanted side effects to your specific situtation. 


Issue #2 User Agent Blocking

Services such as Cloudflare have Web Application Firewall rulesets that may block the requests. Alternatively, your Apache server configuration may be set up to do this either by your web host or your server admin team. If you encounter weird behavior when attempting to access the REST API, it's worth checking for any User Agent blocking. 


Issue #3 Basic Authentication Headers Are Not Passed Through With PHP In CGI Mode

Now we're getting into the more technical items! Another common issue we've seen is where the web server hosting Wordpress/WooCommerce does not pass the Basic Authentication header information through to PHP in CGI mode by default. More technically, what happens is the header that your web server receives in the request doesn't end up populating the variable that PHP uses to populate the other variables that WooCommerce uses to check for basic authentication! That's a mouthful. 


When the variables are missing, this can result in a 401 error even through the credentials are sent correctly. Unfortunately, there isn't really an all encompassing solution that solves this issue for everyone but below are some things to try if you are using an Apache server: 


Solution #1

This solution seems to work the majority of times and it's simply modifying the Wordpress .htaccess file with the following information: 

# BEGIN WordPress
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Specifically you're looking to include the E=HTTP_AUTHORIZATION:%{HTTP:Authorization} in the first [L].
For reference, the default WordPress .htaccess files can be found here.


Solution #2

In some situations, the above will result in Apache populating the $_SERVER['REDIRECT_HTTP_AUTHORIZATION'] variable only. This alone isn't used by WooCommerce so it's still missing the other portion! 


The next approach we've seen work well is to instead add the following to your Apache server .conf file:

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

For best results, it can go in your main/global Apache configuration file. It can also be placed in your .htacess file above the WordPress rules. Like with Solution 1, this will sometimes only result in the one variable being populated however so may not be the fix you need.


Solution #3

If you are using mod_proxy or mod_proxycgi and Apache 2.4.13+ there is also a CGIPassAuth directive that can be used within your main apache config file or .htaccess. For Apache versions prior to 2.4.13, solution #2 will likely be your go to. Otherwise, you could check out the comments on this GitHub thread for more information on this.


Solution #4

If you use mod_fastcgi, another approach we've seen work is to make sure your virtual host fastcgi configuration uses the -pass-header Authorization option/flag. For example, within your <VirtualHost> tag, you'll want to have something that looks like the following: 

<IfModule mod_fastcgi.c>
  SetHandler php7-fcgi .php
  Action php7-fcgi /php7-fcgi virtual
  Alias /php7-fcgi /usr/lib/cgi-bin/php7-fcgi
  FastCgiExternalServer /usr/lib/cgi-bin/php7-fcgi -socket /var/run/php/php7.0-fpm.sock -pass-header Authorization
</IfModule>

Alternatively depending on your set up, you may need to replace "FastCgiExternalServer" with "FastCgiConfig" or add the following line: 

FastCgiConfig -pass-header Authorization