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:
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 our 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 :
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.
Insufficient funds
For guidance on adapting your failed payments workflow, see Setting up a failure management scheme - dunning workflow.