Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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:

No Format
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.