This page explains how to get "self help".

If problems occurs, there are several things that you can do as a self help, before going on reporting the problems. Many problems are based on exceptions between Resurs Bank and the plugin, when it comes to business cases. For example, many problems comes from natural errors like the ones listed below. Many problems are therefore self explained and logs are there as a complement for you to check in. All of the logs are stored in your site, normally in the uploads folder: [WORDPRESS-ROOT]/wp-content/uploads/wc-logs. The plugin uses the internal logging systems and are therefor separated in several sections (or files) which are also reachable from within wp-admin ([WORDPRESS-URL]/wp-admin/admin.php?page=wc-status&tab=logs). The two mentioned paths here are the exact same, reachable in different ways.

Log Types

Those log types are available from within the Data class.

In normal cases, we use Data::setLogNotice/Data::setLogInfo to log notices, but from Data::setLogInternal we can also choose our own severity, and depending on the choice the logs are separated. But they is always there. The goal is to log as much as possible (on demand) so that it get easier to track problems to the correct source. Also, very much all customer events that is vital for "weird tracking" is being done; for example, a very common problem for merchants is when a customer decides to start a payment, but in the middle of the process further chooses to not proceed.

If a customer do not proceed while in the signing moment - or when starting to provide card data to external providers, end never returns to the store again, to fulfill an order no traces will neither become available. Therefore, the plugin also logs the moment when customers are leaving your store to sign or use another payment provider to complete the process. When customer returns to the landingpage for success, we again log the landing moment. By doing this, we can keep track of a potential customer that has not completed the order. Order statuses are also marked with those actions so logs don't have to be the first necessary step in troubleshooting.

Step 0: First time running should be a dedicated test environment

If you are entirely new to this plugin, I'd suggest you to run it in a dedicated test environment that is supposedly equals to a production environment when you install the plugin AFTER testing. Primary newly detected errors should be discovered in TEST rather than production. If something fails in production it also means that YOU are the one that potentially looses traffic to your site.

Step 1: Consult the logs

The first step as mentioned here, unless the errors are displayed instantly on screen is to simply consult the logs. Most of the errors, both critical and less critical errors are logged here.

This screenshot is taken from the "fatal errors" logging:

The other current log is based on regular notes. These are logs mostly based on customer actions and other non critical events. As you can see in the below log file, there are INFO and NOTICE entries here and it is very much depending on which kind of logging you actually want.

If something goes wrong, the answer is almost guaranteed to be found here.

Step 2: Contacting the correct instance

2a. Collect data!

At this point, make sure you have the support data container and logs that might be essential for toubleshooting ready. Do NOT just email someone and say "something is wrong" or "I've got a pop up that says 'there is an error in this unknown function'. Why is this happening?". Make sure you really deliver something that could HELP with the troubleshooting. The "container" mentioned here can be found at /wp-admin/admin.php?page=wc-settings&tab=trbwc_admin&section=information and looks like this.

This container helps a lot to find out if you are compatible with the plugin, which drivers you have available and so on. This includes for example PHP version. If you for example is using PHP 5.5 at this point: Do not contact anybody. Just upgrade your site.

2b: Problems that comes from API requests, that indicates the Resurs Bank has problems

There are errors generated by Resurs Bank, that is forwarded through the API. As you can see, some of the messages above also refers to Resurs Bank own contact ways. This is often problems like "unauthorized" issues in the API or address data (example only) that has trouble to resolve during requests, and much more api related things. This, depending on if you are in test phase or in production, should be reported to Resurs Bank (onboarding@resurs.se for test and support@resurs.se for production). If this is not enough, there might be a chance that other bugs must be handled by the plugin developer. If this plugin has been imported to Resurs Bank as a step to make things better, you can stop here, since they will support this plugin equally to if you ended up on this page. If the plugin is not imported, you can keep reading.

2c: Report further problems to the "community" (or the developer)

The absolutely worst way to contact a developer is to send a mail. support@tornevall.net and sometimes tomas@tornevalls.se is usually available but comes with risks: The mailboxes are not checked everyday, and you could very simply get stuck in spamfilters. Instead, use the open contact channels:

• Jira: Sign up and create a bug.
• Github: If you feel JIRA is too complex for you. As JIRA-licenses for servers is about to expire, I work with both JIRA and Github in parallel.
• WordPress plugin page (not yet created).

Errors that is not necessarily errors

Resurs Checkout and missing payments

If you enable logging you can see a bunch of errors that looks like this:

Preferred payment id set to "ABC" for customer.
Checkout type in order meta is empty, but found in session as rco. This usually occurs in RCO mode. Order meta data will update.
trbwc internal generic exception 8: SOAP Service getPayment: [REFERENCED_DATA_DONT_EXISTS] Tekniskt fel (Could not find externalId: ABC in E-commerce [...], line 2887.
trbwc internal generic exception 8: SOAP Service getPayment: [REFERENCED_DATA_DONT_EXISTS] Tekniskt fel (Could not find externalId: ABC in E-commerce [...], line 2887.
trbwc internal generic exception 8: SOAP Service getPayment: [REFERENCED_DATA_DONT_EXISTS] Tekniskt fel (Could not find externalId: ABC in E-commerce [...], line 2887.
Callback received from Resurs Bank: UPDATE (Digest Status: Valid, External ID: ABC, Internal ID: 2893).
Callback received from Resurs Bank: BOOKED (Digest Status: Valid, External ID: ABC, Internal ID: 2893).
API data request: Customer returned from Resurs Bank. WooCommerce order validation in progress..
Customer returned from Resurs Bank to complete order ABC.
Session value rco_order_id has been reset after successful return to landing page.

As you can see in the above, there are three exceptions with code 8. This is not an actual error, if the logs are followed by the rest of the input you also can see - this is a natural flow caused by the internal order id tracking. For a normal flow, like "simplified", we usually trying to find a proper order from Resurs Bank while we for example prepare for signing. When an order can not be found, it may be caused by specific settings in the plugin that changes how payment id's should be handled. In such cases, the plugin will do a couple of fallbacks to alternate payment references to see if they exist. In RCO, the flow works differently and the plugin may fall back to payment id's that is for real unexistent during the primary payment process. Therefore this is not a regular error, it's a natural behaviour.