Failed payment: how to still recover orders in your shop

A failed payment in Shopware 6 does not mean the order is lost. The order is created as soon as the customer clicks the order button, and the payment status initially remains “Open” (Shopware documentation). If the payment breaks off after that, the system holds an order without any money received. Whether it still turns into revenue depends mainly on whether customers may change the payment method afterwards, whether they learn about the failure in time and in plain words, and whether the way back into the order works without obstacles. This guide covers settings, reminder email, deadlines and tests of your payment plugins. As a Shopware agency we also set this up for your shop.

Why the order survives a failed payment

In Shopware 6, order and payment are separate. Unlike in the previous version, the system creates the order as soon as the customer presses the order button and handles the payment as a separate transaction with its own status (Shopware documentation). If the customer is redirected to the payment provider and completes the payment there, the status changes to “Paid”. If she cancels or the payment fails because of an error, the order remains in place; only the money is missing. The documentation describes the way out explicitly:

Should the payment process be aborted by the customer or an error occur, the customer can also initiate the payment again in his customer account at a later date or change the payment method.

Shopware documentation, Orders: Overview, section “The payment process in Shopware 6”

The legal situation is also clear at first. Under German law, an online shop has to design the ordering process so that consumers expressly confirm with their order that they commit to paying; with a button, this is done with the words “zahlungspflichtig bestellen” (order with obligation to pay) or an equally unambiguous wording (Section 312j BGB). A canceled card payment usually concerns the performance of the contract, not the order itself. When the contract is concluded is usually governed by your terms and conditions.

No public data set measures how often payments fail after checkout in German shops. The surrounding figures do show where the weak points are. In Germany, 85% of internet users aged 16 to 74 shopped online in 2025 (Destatis). For purchases on the internet, 50% of payment transactions run through internet payment methods (Deutsche Bundesbank), followed by direct debits and credit transfers at 30% and credit cards at 15% (Deutsche Bundesbank). Internet payment methods and cards usually involve a redirect or an additional confirmation, and each of these steps is a point where a payment can break off.

Buyers report friction as well. Of the people aged 16 to 74 in the EU who shopped online in 2025, 63% reported no problems at all (Eurostat). By contrast, 12% came across a website that was difficult to use or did not work satisfactorily (Eurostat). A payment failure without clear feedback is such an experience, and it can be avoided.

Why payments fail after checkout

The causes fall roughly into groups. The distinction matters for how the shop reacts, because not every cause can be fixed with the same message.

• Canceled by the customer: The payment provider’s window is closed, the return to the shop does not happen or the customer changes her mind. If she does not return, the payment status usually remains open. If the plugin reports a cancellation by the customer after her return, Shopware sets the payment to “Canceled”, not to “Failed” (Shopware source code).
• Failed authentication: If the payment service provider requires strong customer authentication, it has to be based on at least two elements from the categories knowledge, possession and inherence (Delegated Regulation 2018/389). After no more than five consecutive failed attempts within a given period, access is blocked, temporarily or permanently (Delegated Regulation 2018/389).
• Expired session: For the redirect to the payment service provider, Shopware generates a payment token. Without your own setting it is valid for 60 minutes; if it expires before the payment is completed, Shopware cancels the payment automatically (Shopware documentation).
• Decline or outage: The bank declines the card, a limit has been reached, the payment provider does not respond or a plugin processes the response incorrectly. Here a reminder only helps if it offers a different payment method.

Strong customer authentication still makes sense. According to the joint report of the European Banking Authority and the European Central Bank, payments verified with it were generally less susceptible to fraud, and card payment fraud was 17 times higher when the payee was outside the European Economic Area, where it is not legally required (EBA/ECB). Overall, reported payment fraud in the EEA rose from €3.5 billion in 2023 to €4.2 billion in 2024 (EBA/ECB). How shops can protect themselves against fraud is covered in our article on fraud detection in online shops; the upcoming EU rules on authentication are summarized in the article on PSD3 and PSR.

What Shopware already does out of the box

Recovering an order in Shopware does not require an extension at first. In the customer account, customers see every order with its delivery and payment status under “Orders” and have several options (Shopware documentation):

1. Change payment method: takes the customer back to the checkout page of this order. There the payment method can be updated and the payment process carried out again or canceled.
2. Repeat order: does not create a new order but a new shopping cart with the same products, which the customer has to complete herself as usual.
3. Cancel order: is only available if cancellation is enabled under Settings > Cart.

Whether a payment method is offered for the second attempt is decided by a switch per payment method: “Allow payment method change after order completion”. If it is off, customers can no longer select this payment method when they change it afterwards (Shopware documentation). For this, payment plugins set an option in code that keeps the payment method available after the order has been created, for example for a new attempt after a failed payment (Shopware developer documentation). So check for every payment plugin whether it supports the later change.

Guest orders need separate attention. Anyone who orders without a customer account cannot log in and therefore receives a link to the order in the order confirmation; after entering the email address and postal code, changes can be made there (Shopware documentation). Recovering a guest order therefore depends on exactly this email. Why guest orders should be offered anyway is explained in our article on guest checkout without a mandatory account.

The settings at a glance

Which payment methods make sense for the second attempt

The switch for the later change is a business decision, not a technical formality. If you offer purchase on invoice after a declined card payment, you shift the default risk into the shop. If you only allow prepayment, delivery takes longer. A sensible selection fits the goods, the customer group and the margin.

With the availability rule of a payment method you also define when it is available at all; the rules come from the Rule Builder (Shopware documentation). This lets you limit purchase on invoice to existing customers, for example, while prepayment remains open to new customers. Check in testing that the rule also works as planned on the page for the later change. What each payment method actually costs your shop is calculated in our article on the cost of each payment method.

• Allow payment methods with a redirect for the second attempt if the first attempt was merely canceled
• Offer credit transfer or prepayment as a fallback; with instant credit transfers, the merchant is credited with the amount almost in real time (Deutsche Bundesbank)
• Only allow purchase on invoice with a rule, for example for existing customers or up to a fixed cart value
• Do not open payment methods with their own credit check for the change without review
• Test the selection in the customer account with the same customer groups as in the checkout

In B2B, advance payments and prepayment against invoice come into play; how to bill these cleanly at the turn of the year is shown in the article on advance payment invoices in B2B shops. Instant credit transfers as a fallback are put into context in the article on SEPA Instant Payments.

The reminder email: trigger, content, timing

Without a message, customers often do not even notice that their payment has failed. The Flow Builder under Settings > Automation closes this gap. It has a separate trigger for each payment status; state_enter.order_transaction.state.failed fires when a payment reaches the status “Failed” (Shopware documentation). You attach conditions from the Rule Builder and actions to this trigger. A flow could look like this:

1. Trigger: The payment reaches the status “Failed”.
2. Condition: Sales channel and customer group, so that the consumer shop and the B2B shop get their own wording.
3. Action “Send email”: a template with a link to the order to the customer, for example with the subject “Payment not completed”.
4. Action “Add tag”: a marker on the order so that the team can filter it in the administration.

For payment reminders, Shopware already ships a template: the mail template for entering the payment status “Reminded” is meant for the case in which the customer has not paid yet and receives a reminder (Shopware documentation). It only partly fits a failed payment because the reason is different: the customer has not neglected anything, the payment process broke off. Since version 6.7.14.0, Shopware ships its own flow, flow template and mail template for the trigger state_enter.order_transaction.state.failed (Shopware release notes 6.7.14.0). After the update, adapt this template instead of creating a second flow with its own email for the same trigger; otherwise customers receive two messages. On older versions, create the template and flow yourself. Cancellations by the customer that arrive as “Canceled” additionally need a flow with the trigger state_enter.order_transaction.state.cancelled (Shopware documentation).

There is one limitation regarding timing: delayed actions in the Flow Builder are only available from a specific paid plan onward (Shopware documentation). In the Community Edition, the first email therefore goes out right when the status changes. A second reminder on the following day, only if the order is still open, is handled by a small extension with a scheduled task: Shopware runs such scheduled tasks at an interval defined by the extension (Shopware developer documentation). Making sure the server triggers them regularly is part of a properly configured Shopware hosting.

What belongs in the email

• a subject line that states the reason, such as “Your payment for your order has not been completed”
• order number, amount and items, so that the email makes sense without logging in
• a button with a direct link to the order in the customer account or, for guests, to the order via guest access
• a note that a different payment method can be chosen
• a way to get in touch by phone or email
• no input fields and no request for card or account details in the email itself

The email serves to process the contract; the legal basis is then usually the performance of the contract (Art. 6 GDPR). Advertising does not belong in it: under German law, advertising by email without prior express consent counts as an unreasonable nuisance, and the exception for existing customers is tied to conditions (Section 7 UWG). How to structure transactional emails properly is described in our article on the order confirmation as a transactional email.

The way back: customer account, guest link, checkout

The email is only as good as the page it leads to. Logged-in customers reach the checkout page of the existing order via “Change payment method”, choose a payment method and pay again (Shopware documentation). The link should lead straight there and not end on the start page of the account after login. Guests arrive via the link from the order confirmation and verify themselves with their email address and postal code.

When customers change the payment method, Shopware automatically sets the order status to “Open”; a flow does not need to do this as well and would fail if it tried (Shopware documentation). If you want to attach further steps to the change, such as an internal notification, use the trigger for the changed payment method.

Deadlines, stock and cancellation: the legal side

An open payment is not a permanent state. Under German law, a party to a reciprocal contract may refuse its own performance until the other side performs, unless it is obliged to perform first (Section 320 BGB). Delivering before the payment arrives is therefore not an obligation as long as your payment terms do not provide for advance performance; with purchase on invoice, that is exactly the case.

If the customer does not pay at all, withdrawal is an option: if the obligor does not render a due performance, the obligee may withdraw from the contract after a reasonable deadline has expired without result (Section 323 BGB). The reminder email can set such a deadline. Default follows its own rule: it occurs no later than 30 days after the due date and receipt of an invoice, but for consumers only if the invoice specifically points out this consequence (Section 286 BGB). Which deadlines and wording belong in your shop is something to clarify with your legal counsel.

SEPA direct debit is a special case. It rarely fails at checkout but later: the payer can request a refund from their bank without giving reasons, and the claim is only excluded after eight weeks from the debit (Section 675x BGB). In Shopware such a case can be mapped as a chargeback; it needs a different process from a cancellation at checkout.

Besides the law, stock matters: depending on how stock is managed, an open order ties up goods. Decide after how many days without payment an order is canceled. When many orders are open after sales events, the bulk edit in Shopware helps you set statuses in one go.

Test payment plugins before customers are affected

A well-planned process is of little use if the payment plugin does not report the failure correctly. For payments with a redirect, Shopware calls a separate finalize method of the plugin after the customer returns (Shopware developer documentation); there it is decided whether the transaction counts as paid, canceled or failed. Later notifications from the provider can change the status again. This chain belongs in a fixed test plan:

• Cancellation on the payment provider’s page: Does the customer land back in the shop, is the status set to “Canceled”, and does the matching flow fire?
• Failed authentication with a test card: Does an understandable message appear instead of a blank page?
• Expired payment token: In the test environment, set the time for the transaction short and reproduce the cancellation
• Change payment method in the customer account: Do only enabled payment methods appear, and is the new payment booked correctly?
• Guest order: Does the link from the order confirmation work, including the check of email address and postal code?
• Late response from the provider: Does it avoid wrongly overwriting a status that has since changed to paid?
• Flow and email: Does exactly one email go out, even if the status changes twice or the bundled flow is active alongside your own?

If a payment provider runs as an app instead of a plugin, permissions and webhooks come into play; what to check there is shown in the article on auditing Shopware apps. We run the test plan after updates of Shopware or a plugin in a staging environment before the change goes live.

Keeping an eye on open payments

In the order overview of the administration you can filter by payment status, including multiple selection, for example “Failed”, “Canceled” and “Open” at the same time (Shopware documentation). A fixed view of these orders, checked once a day, is enough for many shops. If you pass orders on to an ERP system, transfer the payment status as well so that no unpaid order goes into shipping there; we take care of this when connecting ERP and inventory systems.

A second question is where payments fail before the order is even placed. These cancellations at checkout do not appear in the shop as orders. How to analyze payment methods and cancellations at checkout is described in the article analyzing payment methods on the XICTRAQ blog; measures before the purchase are collected in our article on checkout optimization.

How we support you with failed payments in Shopware

As a Shopware agency we set up the process from the initial review to testing: which payment methods are active, which emails go out and what happens to unpaid orders.

Every open payment needs a second route

A failed payment in Shopware is a state, not an end. The standard version brings the payment method change, guest access and the triggers in the Flow Builder. What is usually missing is the connection: a deliberate selection of payment methods, an email that explains the failure and leads straight back, a clear deadline and a test that shows after updates that the chain still holds. If you want to set up this process for your shop, get in touch with us.