> ## Documentation Index
> Fetch the complete documentation index at: https://dokumentation.websale.de/llms.txt
> Use this file to discover all available pages before exploring further.

# Known error messages

> Answers and solutions for known error messages from the LogManager.

export const KonfigDeeplink = ({node}) => <>
    You can open this setting directly in the Admin Interface via the following link:{" "}
    <code>{`https://<shop-domain>/admin/config/${node}`}</code>{" "}
    (<a href="/en/admin-interface/konfigurations-deeplinks">Deeplink overview</a>)
  </>;

This page collects and answers known messages from the [LogManager](/en/admin-interface/logmanager-logs). For each error message you will learn how the error occurs and which measures you can take to resolve it. Errors that cannot be resolved through your own configuration are marked accordingly.

How to create log groups, which filters are available, and what the log levels mean is explained on the page [LogManager (Logs)](/en/admin-interface/logmanager-logs).

If a cause remains unclear, please contact the [WEBSALE Service Desk](https://websale.atlassian.net/servicedesk/customer/portal/6) and always state the order number, the subshop, and the time period.

***

## Payment completion and error pages

### `... but the clearer provides no failure url. The customer stays on the page the clearer returned to. Configure an error template for this payment method.`

Message ID: `paymentCheckBeforeRoute.missingFailureRedirectUrl`

### <br />Symptom

The customer stays on the page they were sent back to by the payment provider. This is usually the regular checkout or pending page. There is no crash and no blank page is displayed.

### Cause

A payment ended in a status for which a dedicated error page would actually be required (for example `canceledByUser`). However, no dedicated error redirect is implemented for the current payment provider.

<Warning>
  **Important:**<br />The error message "`Configure an error template`" sounds as if an admin setting is missing. For Stripe (payment IDs start with "`pi_`"), however, this feature does not currently exist. Only the PayPal integration has its own error page configuration. For Stripe, this is therefore not a configuration error you can fix yourself, but a feature currently missing from the integration.
</Warning>

### Procedure

<Steps>
  <Step title="Determine the affected payment provider">
    The message states the transaction ID and the order number. You can see which payment provider is behind it by looking at the transaction in the Admin Interface. A quick indicator is the transaction ID: Stripe transaction IDs usually start with `pi_`.
  </Step>

  <Step title="Assess the frequency">
    Individual occurrences are not critical, because the customer lands on a usable page and can retry the order. A ticket is not necessary in this case.
  </Step>

  <Step title="Report frequent occurrences as a feature request">
    If the message occurs frequently and customers demonstrably abandon the purchase because they remain stuck on the pending page without feedback, please report this to WEBSALE as a feature request. This issue cannot be solved through the shop configuration.
  </Step>
</Steps>

***

## PayPal Checkout

### `Failed to load payment status for order:Payment is in invalid state setting payment to error: checkoutCapture: response status is not valid (regular)`

Message ID: `paymentCheckBeforeRoute.clearerStatusUpdateFailed`

### <br />Symptom

An order started via PayPal is not confirmed as paid. It keeps the payment status it had in the shop before the reconciliation. In the vast majority of cases this is because the customer did not complete the process in the PayPal window.

### Cause

The shop queries the PayPal order status to confirm the payment. At this point, for a regular PayPal payment it only accepts the status `APPROVED` or `PENDING`. However, PayPal reports a different status. The most common reason is that the customer never finally completed the payment in the PayPal window, for example because they closed the window or navigated back. The order at PayPal is then still set to `CREATED`, while the shop nevertheless triggers a status query.

The part before the colon, `Failed to load payment status for order`, is not a cause in its own right, but a framing message displayed in all cases where the shop could not retrieve the payment status. The actual cause follows after it.

The suffix in parentheses tells you which payment flow is involved:

| **Suffix**  | **Payment flow**           | **Accepted PayPal statuses**                           |
| ----------- | -------------------------- | ------------------------------------------------------ |
| `(regular)` | Regular PayPal payment     | `APPROVED`, `PENDING`                                  |
| `(cc)`      | Credit card                | `APPROVED`, `PENDING`, `CREATED`                       |
| `(invoice)` | Purchase on account        | `APPROVED`, `PENDING`, `COMPLETED`, `PENDING_APPROVAL` |
| `(apm)`     | Alternative payment method | `APPROVED`, `PENDING`, `COMPLETED`                     |

### Procedure

<Steps>
  <Step title="Check frequency and context">
    Occasional occurrences can be regarded as normal customer behavior (for example, a payment canceled in the PayPal window) and are not an error in the shop.
  </Step>

  <Step title="Look up the actual PayPal status">
    Search the log for the message ID `paypalCheckoutService.checkoutValidateOrderDetails`. This message is on log level "Info" and contains the complete response from PayPal including the actual `status` value. This tells you in which state the order is stuck at PayPal.

    Therefore, set up the log group so that it includes the Info level. Otherwise you will be missing exactly the message that contains the response.
  </Step>

  <Step title="Check the button integration">
    If the message occurs frequently and reproducibly, please check the integration of the PayPal button in the checkout template. Specifically, check whether the call with `wsPaymentStatus=refresh` is already triggered before the customer has completed the approval at PayPal. This is the typical symptom with custom PayPal button handlers, see [Practical examples - Linking with the payment provider](/en/verknuepfung-zahlungsanbieter).
  </Step>

  <Step title="Report unclear cases">
    If the status is not `APPROVED` or `PENDING` even though the customer apparently went through the checkout again, report the case with the order number to WEBSALE.
  </Step>
</Steps>

***

### `Failed to load payment status for order:getOrderDetails: Failed to communicate with paypal`

Message ID: `paymentCheckBeforeRoute.clearerStatusUpdateFailed`

### <br />Symptom

The payment status of an order is not updated. The order therefore keeps the status it had before the reconciliation.

### Cause

The shop wanted to query the payment status of an order at PayPal, for example when the customer was redirected from PayPal back to the shop or an automatic status reconciliation was running. However, the call to PayPal failed and the shop did not receive a usable response.

The specific cause, for example a timeout, invalid credentials, or an outage at PayPal, is not stated in this message. There is a second variant with the suffix "`result was not a valid JSON`". In this case PayPal did respond, but not in a format the shop can evaluate.

### Procedure

<Steps>
  <Step title="Check the frequency">
    Occasional occurrences spread over time are usually due to a temporary network or PayPal problem. No action is required here.
  </Step>

  <Step title="Check the credentials">
    Check the client ID, the secret, and the operating mode. The mode (`sandbox` or `live`) must match the stored credentials.

    <KonfigDeeplink node="payment.payPalCheckout" />
  </Step>

  <Step title="Compare subshops">
    First check whether all subshops or only some are affected. If only some are affected, this points to a subshop-specific misconfiguration, because configuration nodes can be overridden per subshop.
  </Step>

  <Step title="Escalate persistent cases">
    If the configuration looks correct but the error continues to occur persistently, please report it to WEBSALE. The cause may be a network or firewall block towards PayPal, or a problem on PayPal's side that cannot be resolved through the shop configuration.
  </Step>
</Steps>

***

### `Error setting up the connection to paypal api (Http: 404)`

Message ID: `paypalCheckoutService.callApiHttpError`

### <br />Symptom

A process involving PayPal is not completed. Depending on the affected call, either a payment is not captured or a payment status is not updated. With the error codes `401` and `403`, all PayPal payments in the shop are affected; with `404`, usually only individual orders.

### Cause

PayPal answered a call to the PayPal REST API, for example a status query or a payment capture, with an error code. This message appears for every HTTP code that is not successful. The code in parentheses determines the meaning.

| **HTTP code** | **Meaning**           | **Typical cause**                                      |
| ------------- | --------------------- | ------------------------------------------------------ |
| `400`         | Invalid request       | Faulty data in the request to PayPal.                  |
| `401`         | Authentication failed | Client ID or secret are incorrect.                     |
| `403`         | Not authorized        | The credentials are not authorized for this call.      |
| `404`         | Not found             | PayPal does not know the requested order ID (anymore). |

With `404`, two causes are common. Either the PayPal order no longer exists because the customer never completed it and it expired on PayPal's side. Or the sandbox and live environments do not match, for example because live credentials are stored but the order was still created under sandbox.

Directly after this, the log contains the raw response from PayPal under the message ID `paypalCheckoutService.callApiHttpErrorResult`, for example:

```json theme={"theme":{"light":"github-light","dark":"github-dark"},"languages":{"custom":["/languages/websale.json"]}}
Result: {"name":"RESOURCE_NOT_FOUND","details":[{"issue":"INVALID_RESOURCE_ID"}]}
```

`RESOURCE_NOT_FOUND` and `INVALID_RESOURCE_ID` confirm this. The requested order ID no longer exists at PayPal.

<Note>
  There is a similar error message when fetching the access token: "`Error setting up the connection to Paypal API for Access Token (Http: ...)`". If this occurs, the credentials are fundamentally invalid, independent of any individual order.
</Note>

### Procedure

<Steps>
  <Step title="Identify the order">
    The message itself does not contain an order number. Search the same time window for the message ID `paypalCheckoutService.callApiErrorResponse`. This message is on log level `Info` and contains the order number, the transaction ID, the request sent, and the complete response from PayPal.
  </Step>

  <Step title="Reconcile the sandbox and live configuration">
    The client ID, secret, and operating mode must match. This is particularly relevant if you recently switched between sandbox and live.

    <KonfigDeeplink node="payment.payPalCheckout" />
  </Step>

  <Step title="Check the age of the order">
    If the order is already several hours old, the PayPal order has simply expired. This is not a configuration error. The order can no longer be completed by the customer anyway.
  </Step>

  <Step title="Report recent orders">
    If the error occurs with current orders, please report it to WEBSALE, stating the order number from step 1.
  </Step>
</Steps>

***

## Computop Hosted

### `payment method invalid, not defined in computopHosted config`

Message ID: `computopHosted.getComputopHostedConfigPaymentMethodInvalid`

### <br />Symptom

The customer selects a specific payment method in the checkout, but instead of being redirected to the Computop payment page, the payment is aborted. The affected payment method is exactly the one whose ID is stated in the message.

### Cause

The selected payment method is supposed to be processed via Computop Hosted. To do this, the shop system looks in the configuration node `payment.computopHosted` for the entry with this payment method ID, but cannot find it. The payment is then aborted in a controlled manner. This is not a technical error, but a missing or incorrect assignment in the configuration.

The affected payment method ID appears directly after the colon in the message, without a space.

### Procedure

<Steps>
  <Step title="Note the payment method ID and subshop">
    You can take the payment method ID from the message. You can take the subshop from the log entry, because each entry is assigned to a subshop.
  </Step>

  <Step title="Check the configuration">
    Open the node `payment.computopHosted` and check for the affected subshop whether an entry with this ID exists.

    <KonfigDeeplink node="payment.computopHosted" />
  </Step>

  <Step title="Add the missing entry or correct the template">
    If the ID is active under `payment.payment` but is not stored under `payment.computopHosted`, you must add it there. Configuration nodes can be overridden per subshop. Therefore, check each affected subshop individually.

    If the ID no longer exists because it was renamed or removed, check your templates for a hard-coded old payment method ID and switch to a dynamic reference.
  </Step>

  <Step title="Perform a test order">
    Perform a test transaction in the affected subshop and observe the log group while doing so.
  </Step>

  <Step title="Assess changing IDs">
    If the message persists despite a correct configuration, look at the pattern. In practice, many different, changing payment method IDs tend to originate from outdated sessions or automated access rather than from a misconfiguration.
  </Step>
</Steps>


## Related topics

- [actions - Error texts & emails](/en/konfiguration/actions-fehlertexte-e-mails.md)
- [$wsDirectOrder - Direct order](/en/frontend/referenz/module/wsdirectorder.md)
- [LogManager (Logs)](/en/admin-interface/logmanager-logs.md)
- [actions - User account](/en/konfiguration/actions-fehlertexte-e-mails/actions-benutzerkonto.md)
- [API basics](/en/schnittstellen/admin-interface-api/api-basics.md)