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
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 examplecanceledByUser). However, no dedicated error redirect is implemented for the current payment provider.
Procedure
1
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_.2
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.
3
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.
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
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 statusAPPROVED 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:
Procedure
1
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.
2
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.3
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.4
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.Failed to load payment status for order:getOrderDetails: Failed to communicate with paypal
Message ID: paymentCheckBeforeRoute.clearerStatusUpdateFailed
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
1
Check the frequency
Occasional occurrences spread over time are usually due to a temporary network or PayPal problem. No action is required here.
2
Check the credentials
Check the client ID, the secret, and the operating mode. The mode (
sandbox or live) must match the stored credentials.3
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.
4
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.
Error setting up the connection to paypal api (Http: 404)
Message ID: paypalCheckoutService.callApiHttpError
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.
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:
RESOURCE_NOT_FOUND and INVALID_RESOURCE_ID confirm this. The requested order ID no longer exists at PayPal.
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.Procedure
1
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.2
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.
3
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.
4
Report recent orders
If the error occurs with current orders, please report it to WEBSALE, stating the order number from step 1.
Computop Hosted
payment method invalid, not defined in computopHosted config
Message ID: computopHosted.getComputopHostedConfigPaymentMethodInvalid
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 nodepayment.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
1
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.
2
Check the configuration
Open the node
payment.computopHosted and check for the affected subshop whether an entry with this ID exists.3
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.4
Perform a test order
Perform a test transaction in the affected subshop and observe the log group while doing so.
5
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.