Post-Purchase Cross-Selling & Upselling

Payment methods & failure cases

How the add-on amount is collected depends on how the original order was paid. The extension always resolves this from the order's own payment, not from anything the customer changes afterwards. This chapter shows the full support matrix by payment state – and what applies in failure cases.

Support by payment state

The payment method determines whether the offer can be accepted directly, needs a quick PayPal confirmation or is not shown. Only the four open standard payment methods and the supported SwagPayPal paths qualify – an open third-party invoice gets no offer.

Payment state	Status	Customer action	Result in Shopware	Condition
Invoice, prepayment, cash on delivery or direct debit – open/unpaid	Supported directly	Accept on the offer page	Add the item to the still-open order; no recharge	Only while the order and payment state remain eligible
PayPal wallet or Express with saved authorisation	Supported directly	Accept the offer	Silent recharge, then a change to the same order	Official SwagPayPal extension, vault token and live capability required
PayPal wallet or Express without saved authorisation	Quick confirmation	Accept, then confirm briefly at PayPal	Recharge and order change after successful confirmation	The confirmation path must be enabled and supported by the PayPal account
PayPal on-page card with saved authorisation	Supported directly	Accept the offer	Silent recharge, then a change to the same order	Reusable ACDC vault token required
PayPal on-page card without saved authorisation	Unsupported	No valid acceptance path	No offer	Cards have no wallet confirmation fallback
Pay Later inside the PayPal wallet flow	Quick confirmation	Confirm briefly at PayPal	Recharge and order change after successful confirmation	The order must use the PayPal wallet payment path
Standalone Pay Later payment method	Unsupported	No action	No offer	The standalone Pay Later payment method is not supported
Stripe, Mollie, Klarna, Adyen and other already-paid providers	Unsupported	No action	No automatic recharge; normally no offer	No supported recharge handler

Pay Later is split in two

If the buyer chooses Pay Later via the button inside the PayPal wallet flow, they get the offer with a quick confirmation – never silently. The standalone Pay Later payment method gets no offer. The add-on item itself never runs on an instalment plan.

Invoice, prepayment, cash on delivery, direct debit

While the order is still unpaid, the add-on amount is simply added to the order total. The customer pays the new total the same way they were always going to. Nothing else is needed – nothing is collected.

Order in the administration after an accepted offer — An existing order after the add-on was accepted: the extra item and its discount are added to the original order, and the total is recalculated.

Orders already marked paid

If such an order has already been marked paid, there is no open balance to add to, so no offer is made for it.

PayPal (with SwagPayPal)

PayPal here means the PayPal wallet method and PayPal's own ACDC card method. There are two ways the add-on is collected, and the extension picks automatically:

Silent recharge (best): if the customer has a saved (vaulted) PayPal payment or ACDC card, the add-on amount is charged in the background before the item is added, with no second PayPal step.
Quick confirmation (PayPal wallet only): if a PayPal-wallet order has no saved payment and you have enabled PayPal wallet: collect upsell via a quick confirmation when not vaulted, the customer is sent to PayPal once more to approve just the add-on amount. After they approve, the item is added. If they cancel, nothing is added and nothing is charged.

The card method (ACDC) is saved-card only. A card order with no saved card is not offered the upsell at all: its only possible fallback would be a quick confirmation through the PayPal wallet, which would push someone who paid by card onto a PayPal account, so the extension shows no offer rather than a step that mismatches how they paid. In practice guest card checkouts (which cannot save a card) are not offered the upsell; saved-card customers still get the silent recharge with one click.

The add-on charge is recorded as its own PayPal transaction, so the order shows the original payment plus the add-on, and you can refund either one from the order's PayPal tab. Full setup is in PayPal setup.

Note on the quick confirmation

The quick confirmation fallback is only for customers without a saved payment. If a vaulted customer's silent recharge is declined, the add-on is not added – there is no quick confirmation fallback in that case.

Cards and other providers

Credit/debit cards through other providers (for example Stripe, Mollie, Klarna, Adyen) are not recharged automatically in this version. Either restrict such campaigns to the supported payment methods, or do not offer on those orders. (The campaign's Allowed payment methods picker already lists only the methods the upsell can apply on.)

The campaign's allowed payment methods

Additionally, offers appear only for payment methods the campaign explicitly allows under Allowed payment methods. An empty selection means: no offers. How to set triggers, filters and this selection is covered in Campaigns.

Failure cases: the exception sequence

Declining, closing, an expired link or processing that does not complete safely adds no item. The original confirmed order remains unchanged. For open payment methods, the item is simply added to the open order – nothing is collected. For PayPal payments, a fixed sequence applies:

On acceptance, campaign, payment state, stock and amount boundaries are checked again; exactly one offer wins per order.
The recharge must complete before the add-on item is written. Idempotency prevents a duplicate charge on retry.
If the order change fails after a successful recharge, the extension attempts a compensating refund.
If the compensating refund fails as well, the case is logged as critical and requires manual intervention.

Not every case is visible in the admin

Critical exceptions need reconciliation through Activity, Health, logs and support. The demo shop cannot reproduce such post-capture failures – it shows the flow, not the exceptions.

Critical cases and support

The history of individual orders is on the Activity tab (see Analytics); pre-live diagnostics are covered by the health check. To discuss a critical payment case directly with the engineering team, write to support@commercewerk.de.