Process recurring UK payments
The Trustly Recurring Payments solution (formerly UK Direct Debit) allows you to process recurring payments and subscriptions directly from a customer's bank account within the United Kingdom (UK). This robust, convenient method for subscription billing often results in significantly reduced payment processing costs compared to card networks.
This product is powered by the Trustly European platform. While it can be accessed by North American merchants, the integration endpoints and authentication flows may differ from standard North American recurring payments. Contact your Implementation Manager for the correct European API credentials.
Trustly Recurring Payments is a restricted product. To use this feature, the customer must be located in the United Kingdom (GB), Guernsey (GG), Jersey (JE), or Gibraltar (GI).
Required fields and format
To set up a Direct Debit Instruction (DDI), you must pass specific information in the request object when calling the API.
Mandatory customer and geolocation data
The customer's email and physical address must be provided.
In compliance with the General Data Protection Regulation (GDPR), do not send the customer's telephone number. While the API may not validate this field in real-time, omitting mandatory address data forces the user to manually enter it at checkout, and this lowers conversion.
Merchant reference requirements
The MerchantReference field is mandatory and must be unique for each mandate. It must adhere to the following BACS (Bankers' Automated Clearing Service) rules:
- The core reference must be 6 to 13 characters long.
- Only uppercase alpha and numeric characters count toward the minimum 6-character length.
- The Data Dictionary (DDIC) codes must not be used in the first four characters (reserved for PSP use).
- It must not consist of all the same characters (e.g., "000000").
- It must be left-justified within Field 10 of the DDI record.
- It must be unique for the Service User Number (SUN).
- You must include the payment schedule in the metadata.
{
"metadata": {
"paymentSchedule": {
"1": { "amount": 23, "date": "27th March"},
"2": { "amount": 23, "date": "27th April"}
}
}
}Fixed recurring payments
The following are the requirements for fixed, predictable subscription payments:
- Lead Time: The initial payment date must be at least five days after the mandate is established. Mandates need up to five days for bank confirmation (BACS cycle).
- Auto-Capture: The
AutomaticCaptureparameter must be set totrue. - Cut-off Time: You can cancel a recurring transaction on the current day, but only before 8:30 PM GMT.
BACS cycle workflow
The following diagram illustrates the five-day BACS cycle workflow.
sequenceDiagram
autonumber off
participant U as User
participant M as Merchant
participant T as Trustly API
participant B as UK Bank (BACS)
U->>M: A
M->>T: B
T->>B: C
Note over M, B: D
M->>T: E
T-->>M: F
Note over M, B: G
M->>T: H
T->>B: I
B-->>M: J
| Step | Description |
|---|---|
| A | User Consent: The user agrees to the Direct Debit mandate (checkout). |
| B | Establish Request: You send the Establish API call with the paymentSchedule metadata. |
| C | Register DDI: Trustly registers the Direct Debit Instruction (DDI) with the BACS network. |
| D | Network Gap: The specific "Quiet Period" required by BACS. No collections can be made. |
| E | Early Capture Attempt: Merchant attempts to capture funds on day two or three. |
| F | Error (Failed): The API rejects the request because the mandate is not yet established. |
| G | Lead Time Complete: Day five has passed. The mandate is now active. |
| H | Valid Capture: Merchant attempts capture on day 6 or later. |
| I | Process Payment: Trustly submits the collection to BACS. |
| J | Funds Settled: Funds are moved to the merchant account. |
Variable payments
The following are the requirements for processing payments with variable amounts:
- Lead Time: The first capture cannot occur earlier than five days after the mandate is established.
- Notification: You must send an email notification to the user before calling the capture API. This email must clearly state the date and amount of the upcoming transaction.
- Confirmation: You must send an email confirmation to the user as soon as a mandate is successfully created.
Representment
If a transaction fails (usually due to insufficient funds), you can attempt a representment.
- You must enable representment in your configuration.
- You must define the retry interval (days between attempts).
- You must send an advanced notice email to the user before each retry.
- Limit: A failed transaction can be retried a maximum of two times.
- Window: The representment period is limited to 30 days from the initial failure.
Representment workflow
The following diagram illustrates the workflow for failed payment representment.
flowchart LR
Start((A)) --> Fail[B]
Fail --> Check{C}
Check -- Yes --> Wait[D]
Check -- No --> Stop((H))
Wait --> Email[E]
Email --> Retry[F]
Retry --> Result{G}
Result -- Success --> Done((I))
Result -- Fail --> Fail
style Start fill:#f9f,stroke:#333,stroke-width:2px
style Stop fill:#ff9999,stroke:#333,stroke-width:2px
style Done fill:#99ff99,stroke:#333,stroke-width:2px
| Step | Workflow Step |
|---|---|
| A | Transaction Start: Initial capture attempt. |
| B | Payment Failed: The transaction is declined. For example, insufficient funds. |
| C | Eligibility Check: Is the retry count < 2 AND is the initial failure < 30 days ago? |
| D | Wait Interval: Pause for the predefined number of days. For example, three days. |
| E | Send Notice: Send the mandatory Advanced Notice email to the user notifying them of the upcoming retry. |
| F | Execute Retry: Trigger the representment (Capture) API call. |
| G | Outcome: Did the retry succeed? |
| H | Hard Stop: Max retries reached or time limit expired. No further attempts allowed. |
| I | Success: Funds captured successfully. |
Import existing mandates
To import existing mandates, complete the following tasks:
- Create CSV files in the required format. Use the recommended naming convention.
- Send the file to your designated SFTP folder.
You'll receive a notification for each transaction processed during the import.
API resources
Use these API calls to manage your Recurring Payments mandates.
The following documentation links reference the Trustly European API standard. Ensure you are authenticated against the European endpoints.
| API Method | Reference |
|---|---|
| Get transactions | EU API Reference: Notifications |
| Retrieve payment | EU API Reference: Deposit |
| Cancel transaction | EU API Reference: Refund/Cancel |
Expected responses
The following table lists the response types and reason codes used to indicate the status or reason for a transaction or mandate failure.
You must enable Event Notifications to retrieve status updates on mandates and transactions. See Event notifications.
| Type | Reason | Description |
|---|---|---|
| ARUCS | 0 | Invalid details |
| ARUCS | 2 | Beneficiary deceased |
| ARUCS | 3 | Account transferred |
| ARUCS | 5 | No account |
| ARUCS | B | Account closed |
| ARUCS | C | Requested by remitter |
| AWACS | 0 | Invalid details |
| AWACS | 3 | Account transferred |
| ARUDD | 0 | Refer to payer (basically means out of funds) |
| ARUDD | 2 | Payer deceased |
| ARUDD | 3 | Account transferred |
| ARUDD | 4 | Advance notice disputed |
| ARUDD | 5 | No account (or wrong account type) |
| ARUDD | 6 | No instruction |
| ARUDD | 7 | Amount differs (disputed amount) |
| ARUDD | 8 | Amount not yet due (in case payment is sent before DDI confirmed) |
| ARUDD | 9 | Presentation is overdue |
| ARUDD | A | Service User differs (Details do not match DDI) |
| ARUDD | B | Account closed |
| ADDACS | 0 | Instruction canceled refer to Payer |
| ADDACS | 1 | Instruction canceled by Payer |
| ADDACS | 2 | Payer Deceased |
| ADDACS | 3 | Account transferred to new bank |
| ADDACS | B | Account closed |
| ADDACS | C | Account transferred to new branch |
| ADDACS | D | Advance notice disputed |
| ADDACS | E | Instruction amended |
| ADDACS | R | Instruction re-instated |
| AUDDIS | 1 | Instruction Canceled by Payer |
| AUDDIS | 2 | Payer deceased |
| AUDDIS | 3 | Account transferred |
| AUDDIS | 5 | No Account |
| AUDDIS | 6 | No instruction |
| AUDDIS | C | DDI amount not zero |
| AUDDIS | F | Invalid account type |
| AUDDIS | G | PSP will not accept DD on account |
| AUDDIS | H | Instruction expired |
| AUDDIS | I | Payer Reference not unique |
| AUDDIS | K | Instruction canceled by paying PSP |
| AUDDIS | L | Incorrect payers account details |
| AUDDIS | M | Trx code/user status incompatible |
| AUDDIS | N | Trx not allowed at payers branch |
| AUDDIS | O | invalid reference |
| AUDDIS | P | Payer's name not present |
| AUDDIS | Q | Service users name blank |
| DDIC | 1 | Amount differs |
| DDIC | 2 | No advance notice received by payer |
| DDIC | 3 | DDI canceled by bank |
| DDIC | 4 | Payer has canceled DDI with Service User |
| DDIC | 5 | No instruction held |
| DDIC | 6 | Signature fraudulent |
| DDIC | 7 | Claim raised at Service User Request |
| DDIC | 8 | Service user name disputed, payer does not recognise |
Updated 16 days ago