🔧 Change
More detailed error messages for failed SEPA payments
Transaction error messages for SEPA payments now show more specific and accurate failure reasons. Previously, many SEPA declines returned only a generic error; now the following causes can be identified directly on the transaction: incorrect or closed bank account, insufficient funds, missing or invalid mandate, or payment disputed by the customer's bank. This makes it easier to understand why a SEPA payment failed and what the next step should be.
Stripe error message according to: https://docs.stripe.com/declines/network-codes
Raw network code | Failure code | Explanation | Next steps |
|---|---|---|---|
|
| The transaction can’t be processed because the IBAN that your customer provided is incorrect. | Contact your customer for correct account details, then retry the transaction. |
|
| The payment can’t be processed because your customer’s bank account is closed. | Contact your customer for new account details, then retry the transaction. |
|
| Stripe can’t identify a specific reason for the payment failure. | Contact Support for more information. |
|
| The payment process can’t be completed because your customer’s bank account lacks the necessary funds. | Contact your customer to verify that they have the required funds, then retry the transaction. |
|
| The payment doesn’t have an authorised mandate. | Collect a new mandate, then retry the transaction. |
|
| The transaction can’t be processed due to missing or incorrect mandate information. | Collect a new mandate from your customer, then retry the transaction. |
|
| Your customer requested that their bank refund this payment. | Contact your customer to resolve any dispute, then retry the transaction. |
|
| The mandate was set up on the account of a potentially deceased individual. | Verify your customer’s status before retrying the transaction. |
|
| The payment can’t be processed because the bank branch associated with your customer’s IBAN doesn’t exist. | Contact your customer to provide new account details, then retry the transaction. |
|
| The transaction can’t be processed because your customer’s account information is missing or incorrect. | Collect a new mandate and ask your customer to provide their name and address exactly as it appears on their bank account. Then, retry the transaction. |
|
| We don’t have detailed information about the payment failure because your customer’s bank didn’t provide a reason code. | Contact your customer for more information. |
Event ticket details can now be set per order item
Event information for ticket purchases can now be provided separately for each item in an order, instead of a single set of details for the whole order. This allows an order to contain tickets for different events, ticket categories, or ticket types in one purchase — for example, an order with one early-bird ticket for a conference and one regular ticket for a webinar, each keeping its own event details.
Each ticket item can now carry:
the event name, start date, and end date
the promoter or organizer
the event type (conference, seminar, webinar, or other)
the ticket category (normal, early-bird, discounted, speaker, sponsor, or other)
the ticket type (in-person or digital)
the event address
🐛 Fix
PLEN-11478: Deactivating an API access token with auto-renewal enabled did not stop new tokens from being created for it, so deactivated tokens kept producing replacements. Deactivating a token now also ends its automatic renewal, and existing unwanted renewal chains have been cleaned up.
PLEN-11281: The VAT category code in generated xRechnung/ZUGFeRD invoices was not always correct, and in some cases the invoice did not pass XRechnung 3.0 validation. The following now applies:
Digital products and services sold to a business customer in another EU country with a VAT ID are now reported as AE (VAT reverse charge) instead of K. This is the correct classification under Art. 44 and 196 of the EU VAT Directive. Previously these invoices were also rejected by XRechnung validators, because K requires delivery information that digital products do not have.
Physical goods sold to a business customer in another EU country with a VAT ID continue to be reported as K (intra-community supply), and the invoice now includes the deliver-to country, which XRechnung requires for this category.
Supplies taxed outside the EU are now reported as G (free export item, VAT not charged) instead of AE. Reverse charge is an intra-EU mechanism and requires a buyer VAT ID, which customers outside the EU do not have, so these invoices previously failed validation.
Domestic and standard-rated invoices are unaffected.
All VAT category outcomes now validate against EN 16931 and XRechnung 3.0 without errors.