When a SEPA Direct Debit (SDD) or recurring card transaction (RCC) fails, the bank or Payment Service Provider (PSP) returns an R-code or also referred to as SDD R-transactions. These codes are defined by the European Payments Council (EPC) and indicate why a transaction could not be completed or was reversed.
Correctly interpreting R-codes allows you to:
See Transaction failed — what now? for the default setup per failure type.
A Reject occurs before settlement when a transaction cannot be processed due to an error detected by the debtor bank or the clearing mechanism.
Typical causes:
A Refusal is initiated by the debtor, who instructs their bank not to execute a specific collection, before settlement.
Typical causes:
A Return happens after settlement and is initiated by the debtor bank, usually because the transaction could not be completed (e.g. insufficient funds).
A Refund is explicitly requested by the debtor after a successful collection:
The EPC defines what an R-code means and when it can occur.
Within Twikey, we go some steps further.
To enable smart, consistent and fully automated follow-up, Twikey groups R-codes into operational buckets. These buckets are not EPC scheme categories, but a practical Twikey structuring that helps determine the right next action for each failed transaction.
By structuring the R-codes this way, you can:
Below you'll find 3 operational buckets:
This bucket groups R-codes that indicate the customer can't pay at that moment, typically due to a temporary lack of funds. In most cases, the mandate and account remain valid, and payment may succeed later without customer intervention.
| CODE | ERROR REASON |
|---|---|
| MS03 | Reason not specified |
| AM04 | Insufficient funds |
Typical automated follow-up in Twikey:
This bucket contains R-codes where the customer has explicitly refused the payment or requested a refund. Simply said, they will not pay.
Retrying the same collection without customer interaction is usually ineffective.
| CODE | ERROR REASON |
|---|---|
| MD06 | Disputed authorized transaction. Debtor has requested a refund within the 8 weeks refund period. |
| MS02 | The debtor refuses this particular collection. This code may be received pre- or post-settlement, depending on how quickly the debtor bank responds to the refusal. |
| SL01 | Specific service offered by the Debtor Bank. The creditor has been blocked by the debtor (blacklisted) or the collection amount is too high. |
Typical automated follow-up in Twikey:
This bucket groups all other remaining R-codes where the failure is caused by technical, data, regulatory or mandate-related issues.
These cases usually require corrective action before any retry can succeed.
| CODE | ERROR REASON |
|---|---|
| AC01 | IBAN or IBAN/BIC combination of debtor is incorrect. |
| AC04 | Debtor account closed. |
| AC06 | Account of the debtor blocked (eg. succession/bankruptcy) or blocked for Direct Debit transactions by the debtor. |
| AC13 | Account type not allowed for Direct Debits. |
| AG01 | Account not allowed for Direct Debits for regulatory reasons. |
| AG02 | Bank Operation code specified in the message is not valid for the bank. |
| AM05 | Duplicate collection. |
| BE05 | Incorrect Creditor Identifier code. |
| FF01 | File Format incomplete or invalid. |
| MD01 | No valid mandate (no longer valid, not correctly registered, invalid sequence type). |
| MD02 | Mandate data missing or incorrect. Two FIRST transactions were received for the same mandate. |
| MD07 | Debtor deceased. |
| PY01 | Not routable. This can occur when the debtor's bank does not handle SDD's. |
| RC01 | Bank Identifier (BIC) incorrect. |
| RR01 | Regulatory Reason. The debtor account number is missing. |
| RR02 | Regulatory Reason. The debtor name and/or address is missing. |
| RR03 | Regulatory Reason. The creditor name and/or address is missing. |
| RR04 | Regulatory Reason. This code cannot be used in certain SEPA countries for data protection reasons. MS03 can be used as an alternative. |
Typical automated follow-up in Twikey:
MD07 receives special treatment that runs before the normal dunning workflow and applies across all merchants.
When a failed payment with code MD07 is received, Twikey looks up every mandate linked to that debtor's bank account — regardless of which merchant the mandate belongs to. For each mandate found:
This cross-merchant approach is intentional: a deceased debtor's account will fail for all creditors who collect against it, so all affected merchants are informed proactively rather than discovering the failure on their next collection run.
You can find a complete overview of all R-codes here:
To simplify handling failed transactions, you can configure dunning steps—automated actions triggered by specific R-codes.
This allows you to:
Failed payment steps run fully automatically, ensuring a smooth and scalable direct debit process.
When configuring your failed payment workflow, the following step types are available:
| Step type | What it does |
|---|---|
| Try again | Re-submits the transaction to the bank after a configurable delay |
| Allow payment alternative | Sends the customer a payment link so they can pay via an alternative method |
| Change status of mandate | Suspends or cancels the mandate to prevent further automatic collections |
| Notify | Sends a notification to the customer and/or merchant |
| Send official letter (Wik Letter) | Issues a legally compliant debt collection letter as a final formal step |
| Offer signing an alternative mandate | Invites the customer to sign a new mandate |
| Move mandate to other profile | Moves the mandate to a different profile (e.g. to apply different collection rules) |
Each step type can be configured per R-code bucket with custom delays and message templates. For setup instructions, see Setting up a failure management scheme.
For guidance on adapting your failed payments workflow, see Setting up a failure management scheme - dunning workflow.