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 AutomaticCapture parameter must be set to true.
  • 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
StepDescription
AUser Consent: The user agrees to the Direct Debit mandate (checkout).
BEstablish Request: You send the Establish API call with the paymentSchedule metadata.
CRegister DDI: Trustly registers the Direct Debit Instruction (DDI) with the BACS network.
DNetwork Gap: The specific "Quiet Period" required by BACS. No collections can be made.
EEarly Capture Attempt: Merchant attempts to capture funds on day two or three.
FError (Failed): The API rejects the request because the mandate is not yet established.
GLead Time Complete: Day five has passed. The mandate is now active.
HValid Capture: Merchant attempts capture on day 6 or later.
IProcess Payment: Trustly submits the collection to BACS.
JFunds 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
StepWorkflow Step
ATransaction Start: Initial capture attempt.
BPayment Failed: The transaction is declined. For example, insufficient funds.
CEligibility Check: Is the retry count < 2 AND is the initial failure < 30 days ago?
DWait Interval: Pause for the predefined number of days. For example, three days.
ESend Notice: Send the mandatory Advanced Notice email to the user notifying them of the upcoming retry.
FExecute Retry: Trigger the representment (Capture) API call.
GOutcome: Did the retry succeed?
HHard Stop: Max retries reached or time limit expired. No further attempts allowed.
ISuccess: 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 MethodReference
Get transactionsEU API Reference: Notifications
Retrieve paymentEU API Reference: Deposit
Cancel transactionEU 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.

TypeReasonDescription
ARUCS0Invalid details
ARUCS2Beneficiary deceased
ARUCS3Account transferred
ARUCS5No account
ARUCSBAccount closed
ARUCSCRequested by remitter
AWACS0Invalid details
AWACS3Account transferred
ARUDD0Refer to payer (basically means out of funds)
ARUDD2Payer deceased
ARUDD3Account transferred
ARUDD4Advance notice disputed
ARUDD5No account (or wrong account type)
ARUDD6No instruction
ARUDD7Amount differs (disputed amount)
ARUDD8Amount not yet due (in case payment is sent before DDI confirmed)
ARUDD9Presentation is overdue
ARUDDAService User differs (Details do not match DDI)
ARUDDBAccount closed
ADDACS0Instruction canceled refer to Payer
ADDACS1Instruction canceled by Payer
ADDACS2Payer Deceased
ADDACS3Account transferred to new bank
ADDACSBAccount closed
ADDACSCAccount transferred to new branch
ADDACSDAdvance notice disputed
ADDACSEInstruction amended
ADDACSRInstruction re-instated
AUDDIS1Instruction Canceled by Payer
AUDDIS2Payer deceased
AUDDIS3Account transferred
AUDDIS5No Account
AUDDIS6No instruction
AUDDISCDDI amount not zero
AUDDISFInvalid account type
AUDDISGPSP will not accept DD on account
AUDDISHInstruction expired
AUDDISIPayer Reference not unique
AUDDISKInstruction canceled by paying PSP
AUDDISLIncorrect payers account details
AUDDISMTrx code/user status incompatible
AUDDISNTrx not allowed at payers branch
AUDDISOinvalid reference
AUDDISPPayer's name not present
AUDDISQService users name blank
DDIC1Amount differs
DDIC2No advance notice received by payer
DDIC3DDI canceled by bank
DDIC4Payer has canceled DDI with Service User
DDIC5No instruction held
DDIC6Signature fraudulent
DDIC7Claim raised at Service User Request
DDIC8Service user name disputed, payer does not recognise