UK Corporate Payments API v1

Version history

Version 1.0 - Available only in Sandbox

Version 1.0 of the UK Corporate Payments API is currently available only in the sandbox environment and supports Faster Payments and CHAPS.

Introduction

The UK Corporate Payments API enables TPP applications to initiate and manage credit transfer payments from Nordea UK corporate customer payment accounts.

Nordea provides these services to corporate customers in the UK. This API provides payment initiation services to Large Corporate customers, in compliance with the UK Payment Services Regulations (PSRs).

The API supports the following payment types:

Using the API, a TPP can:

• Initiate (create) a payment instruction
• Verify beneficiaries
• Confirm the payment — required before execution
• Get payment status and details
• List payments
• Cancel a payment

Note: All payment endpoints can only be accessed with a token authorized by a PSU (Payment Service User) with a scope “PAYMENTS_UK”. It is important to notice that token is used to identify the PSU and all payment operations are registered as performed by the PSU, therefore, whenever the SCA is required, it must be performed by the same PSU who has authorized the token.

For more details please see the Corporate Access Authorization API v3 documentation.

Payment Flow

Overview

Every payment follows the same top-level lifecycle:

1. Initiation — TPP submits a payment instruction. The payment instruction is created.
2. Beneficiary verification (conditional) — Nordea’s system might force the PSU to verify beneficiaries information.
3. Confirmation — the payment creator (PSU) must explicitly confirm the payment. PSU signs the confirmation in Nordea App.
4. Execution — after confirmation, the payment is submitted for processing and eventually executed.

At any stage, the TPP can:

• Poll GET /uk/v1/payments/{payment_id} to check the current state.
• Cancel the payment (subject to state restrictions).

Happy path — no beneficiary verification required:

Happy path — with beneficiary verification required:

Payment Initiation

POST /uk/v1/payments

Initial request to create a payment instruction. The request body includes the payment details and identifies the payment type via the template_id field:

Nordea’s Open Banking service validates the payment instruction and, if successful, returns a payment_id that must be stored by the TPP and used in all subsequent operations (confirm, verify, cancel, get details).

On success the initial response status is PAYMENT_INITIATED. This is a transient state — the service processes the request asynchronously and transitions to the next state without further action from the TPP. The TPP should poll GET /uk/v1/payments/{payment_id} to detect the transition.

After processing, the payment will be in one of the following states:

Important: Validation errors during payment initiation return an HTTP 4xx error — no payment record is created. The TPP must correct the request and retry.

The payment must be confirmed (and if required, verified first) before the end of the requested execution date, or it will be rejected.

For request and response examples, see Create Payment examples.

Beneficiary Verification

PUT /uk/v1/payments/{payment_id}/verify

This endpoint is called when the payment status is AUTHORIZATION_PARTIAL with payment_status_reason: info.payment.verification_required. In this process phace PSU must verify beneficiaries information.

Upon calling this endpoint, Open Banking creates a signing order in Nordea App. A beneficiary must be verified by the PSU through a signing process in Nordea App before the payment can proceed. Anyone who have KEY_IN rights into debtor account have permission to verify payment/beneficiaries.

When the PSU completes signing (ie verified beneficiaries) the payment transitions to:

• AUTHORIZATION_PARTIAL with payment_status_reason: info.payment.confirmation_required — verification complete, payment ready for confirmation.

For request and response examples, see Verify Payment examples.

Payment Confirmation

PUT /uk/v1/payments/{payment_id}/confirm

Each payment requires at least one confirmation before it can be executed. The first confirmation must be performed by the same PSU who created the payment.

When called, Open Banking creates a signing order in Nordea App. The PSU signs the payment. While the signing is in progress, the payment status is:

• AUTHORIZATION_PENDING with payment_status_reason: info.payment.confirmation_in_progress

Once the PSU successfully signs, the payment transitions to:

• PAYMENT_ACCEPTED — the payment has been fully authorised and submitted for execution processing.

Note - after successful signing payment can still transit into AUTHORIZATION_PARTIAL state if several confirmation is needed. This can happen if the payment requires multiple confirmations and the next confirmation is required from a different PSU. In that case payment_status_reason will be info.payment.confirmation_required and the next PSU must be nominated by calling the confirm endpoint again.

From PAYMENT_ACCEPTED, the payment is processed and transitions automatically to a final state (see payment states table in Payment Status Reference).

Note: Payments must be confirmed before the cut-off time on requested_execution_date, or they will be rejected.

For request and response examples, see Confirm Payment examples.

Getting Payment Details

GET /uk/v1/payments/{payment_id}

At any stage of the process, the TPP can retrieve the current status and full details of a payment. The payment_id must be the identifier originally returned from the payment initiation.

Use this endpoint to poll for state changes — for example, after calling confirm or verify, poll until the expected next state is reached.

The response includes the full payment instruction details and the current payment_status and payment_status_reason.

For request and response examples, see Get Payment Details examples.

Payment List

GET /uk/v1/payments

Returns a list of payment instructions with their current status and details, filtered by the search criteria provided as query parameters. Supported filters include for example creation date range, execution date range, debtor account, payment status, and others.

The response is paginated; the maximum number of payment instructions per page is 20.

See more about parameters and request and response examples in Payment List examples

Payment Cancellation

PUT /uk/v1/payments/{payment_id}/cancel

Used to cancel a payment. Upon calling this endpoint, Open Banking creates a cancellation signing order in Nordea App. While cancellation signing is in progress, the payment status is:

• AUTHORIZATION_PENDING with payment_status_reason: info.payment.cancellation_in_progress

Once the PSU signs, the payment transitions to PAYMENT_CANCELLED, which is a final state. Cancelled payments remain visible but cannot be modified.

Not all payment statuses can be cancelled. Payments with status PAYMENT_REJECTED, PAYMENT_EXECUTED, PAYMENT_CANCELLED or AUTHORIZATION_PENDING cannot be cancelled.

For request and response examples, see Cancel Payment examples.

Payment Status Reference

The reported state of a payment can be any of the following:

Cut-off times

Payments must be confirmed before their cut-off time. Cut-off times vary by payment type. For cut-off times, refer to the Nordea UK cut-off list: NBI Cut-off Times

Payment Templates

Each payment initiation request must identify the payment type using a template_id field in the request body. The template determines the payment scheme, the applicable validation rules, and the required and optional fields.

In the current sandbox publication, UK payments support two templates:

Both templates support a single credit transfer instruction per request and one beneficiary per payment instruction.

API reference

Nordea offers open api definitions available for our consumers under UK Corporate Payments API v1 documentation. The documentation includes detailed information about the request and response structure, field definitions, and validation rules for each payment type.

Authentication and Authorization

Authentication

The only supported authentication method is NordeaID (MTA).

Access Token

All payment endpoints require a PSU token. Admin tokens are not supported. For more details please see the Corporate Access Authorization API v3 documentation.

Required HTTP Headers

Every request must include the following headers:

* Required on all requests. The Digest and Content-type header is required only when the request contain a body.

Request Signing

Requests must be signed at the application level using the Signature header as defined in RFC draft “Signing HTTP Messages” version 10.

Requirements:

• Algorithm: RSA-SHA256
• Minimum key size: 2048 bit
• keyId: the X-IBM-Client-Id value
• Headers to include in the signature:
  • Requests without body: (request-target), X-Nordea-Originating-Host, X-Nordea-Originating-Date
  • Requests with body: (request-target), X-Nordea-Originating-Host, X-Nordea-Originating-Date, Content-Type, Digest

For GET requests, no request body is sent and therefore no Digestand Content-typeis required.

Strong Customer Authentication (SCA)

SCA is required when a PSU confirms, cancels or verifies a payment. Following two authorization flows are supported:

Decoupled flow

The PSU authenticates directly on their NordeaID device without leaving the TPP application. The request body must include:

{
  "authentication_type": "DECOUPLED",
  "authentication_method": "MTA"
}

Redirect flow

The PSU is redirected to the Nordea authentication page. The request body must include:

{
  "authentication_type": "REDIRECT",
  "authentication_method": "MTA",
  "redirect_uri": "https://example.com/callback",
  "state": "38ee6abc-fd48-4b11-bd6a-97501fce702e"
}

Only supported language in authentication flow is English.

Examples

The examples in this section are illustrative and show the general request and response structure for the API. Header values such as Authorization, Signature, Digest, X-Nordea-Originating-Date, and X-Nordea-Originating-Host are omitted for brevity.

Create Payment examples

POST /uk/v1/payments

This endpoint is used to create a payment instruction. The request body structure is the same for Faster Payments and CHAPS. The main differences are the template_id, amount limits, and message formatting rules described in API definition - see from API reference.

Faster Payments — request example

This Faster Payments example shows a payment with a single beneficiary and here beneficiary verification required. The template_id identifies the payment type and determines the applicable validation rules.

{
  "payment_instruction": {
    "template_id": "FASTER_PAYMENT_UK",
    "amount": 1.0,
    "currency": "GBP",
    "requested_execution_date": "2026-04-23",
    "debtor": {
      "account": {
        "currency": "GBP",
        "value": "3046697121"
      },
      "own_reference": "own message"
    },
    "creditor": {
      "account": {
        "value": "30466971"
      },
      "bank": {
        "bank_code": "445566",
        "name": "Example Bank",
        "address": {
          "line_1": "22 Market Road",
          "line_2": "Manchester"
        },
        "country": "GB"
      },
      "message": "message",
      "name": "Name"
    },
    "external_id": "f1642fe6-ebdf-4f71-b5ab-14dd88da3a80"
  }
}

Faster Payments — response example

{
  "group_header": {
    "message_identification": "2d785ebab22c3050",
    "creation_date_time": "2026-04-22T11:47:31.224336203Z",
    "http_code": 201
  },
  "response": {
    "_id": "7f8bb693-47b3-40b8-8db3-f923aa6429f8",
    "template_id": "FASTER_PAYMENT_UK",
    "external_id": "f1642fe6-ebdf-4f71-b5ab-14dd88da3a80",
    "amount": "1.0",
    "requested_execution_date": "2026-04-23",
    "currency": "GBP",
    "debtor": {
      "account": {
        "value": "3046697121",
        "currency": "GBP"
      },
      "own_reference": "own message"
    },
    "creditor": {
      "account": {
        "value": "30466971"
      },
      "name": "Name",
      "bank": {
        "address": {
          "line_1": "22 Market Road",
          "line_2": "Manchester"
        },
        "bank_code": "445566",
        "country": "GB",
        "name": "Example Bank"
      },
      "message": "message"
    },
    "payment_status": "PAYMENT_INITIATED",
    "payment_status_reason": "info.payment.verification_required",
    "_links": [
      {
        "rel": "self",
        "href": "/uk/v1/payments"
      },
      {
        "rel": "verify",
        "href": "/uk/v1/payments/7f8bb693-47b3-40b8-8db3-f923aa6429f8/verify"
      },
      {
        "rel": "cancel",
        "href": "/uk/v1/payments/7f8bb693-47b3-40b8-8db3-f923aa6429f8/cancel"
      },
      {
        "rel": "details",
        "href": "/uk/v1/payments/7f8bb693-47b3-40b8-8db3-f923aa6429f8"
      }
    ]
  }
}
 

The payment is then processed asynchronously. The TPP should poll GET /uk/v1/payments/{payment_id} until the payment transitions to either:

• AUTHORIZATION_PARTIAL with payment_status_reason: info.payment.verification_required, or
• AUTHORIZATION_PARTIAL with payment_status_reason: info.payment.confirmation_required

CHAPS — request example

Here beneficiary verification is not required, so the payment can be confirmed immediately after initiation.

{
  "payment_instruction": {
    "template_id": "CHAPS_PAYMENT_UK",
    "amount": 285000.00,
    "currency": "GBP",
    "requested_execution_date": "2026-04-23",
    "external_id": "0c2efdc7-a2cb-4df8-9d4e-dc3bfc508e71",
    "debtor": {
      "account": {
        "value": "3046697121",
        "currency": "GBP"
      },
      "own_reference": "Property completion"
    },
    "creditor": {
      "name": "Smith and Co Client Account",
      "country": "GB",
      "address": {
        "line_1": "22 Market Road",
        "line_2": "Manchester"
      },
      "account": {
        "value": "87654321"
      },
      "bank": {
        "bank_code": "445566",
        "name": "Example Bank",
        "address": {
          "line_1": "22 Market Road",
          "line_2": "Manchester"
        },
        "country": "GB"
      },
      "srd_roll_number": "MATTER7788",
      "message": "Completion funds. Ref 2026-041. Client A"
    }
  }
}

CHAPS — response example

{
  "group_header": {
    "message_identification": "11b15d6184a6bb0a",
    "creation_date_time": "2026-04-22T11:56:39.894821855Z",
    "http_code": 201
  },
  "response": {
    "_id": "1a9485ba-aee8-4412-bfcb-a5be44779964",
    "template_id": "CHAPS_PAYMENT_UK",
    "external_id": "0c2efdc7-a2cb-4df8-9d4e-dc3bfc508e71",
    "amount": "285000.00",
    "requested_execution_date": "2026-04-23",
    "currency": "GBP",
    "debtor": {
      "account": {
        "value": "3046697121",
        "currency": "GBP"
      },
      "own_reference": "Property completion"
    },
    "creditor": {
      "account": {
        "value": "87654321"
      },
      "name": "Smith and Co Client Account",
      "address": {
        "line_1": "22 Market Road",
        "line_2": "Manchester"
      },
      "bank": {
        "address": {
          "line_1": "22 Market Road",
          "line_2": "Manchester"
        },
        "bank_code": "445566",
        "country": "GB",
        "name": "Example Bank"
      },
      "message": "Completion funds. Ref 2026-041. Client A",
      "srd_roll_number": "MATTER7788"
    },
    "payment_status": "PAYMENT_INITIATED",
    "_links": [
      {
        "rel": "self",
        "href": "/uk/v1/payments"
      },
      {
        "rel": "confirm",
        "href": "/uk/v1/payments/1a9485ba-aee8-4412-bfcb-a5be44779964/confirm"
      },
      {
        "rel": "cancel",
        "href": "/uk/v1/payments/1a9485ba-aee8-4412-bfcb-a5be44779964/cancel"
      },
      {
        "rel": "details",
        "href": "/uk/v1/payments/1a9485ba-aee8-4412-bfcb-a5be44779964"
      }
    ]
  }
}

As with Faster Payments, the initial response only confirms that the payment instruction has been created. The payment must still progress through the authorization flow before execution.

Get Payment Details examples

GET /uk/v1/payments/{payment_id}

This endpoint returns the current payment status together with the payment details originally submitted at initiation.

Request example

This is example of above Faster payment created above.

GET /uk/v1/payments/24bcfc34-4502-4d3e-bcfe-f80c477f4e08 

Response example

{
  "group_header": {
    "message_identification": "2d785ebab22c3050",
    "creation_date_time": "2026-04-22T11:47:31.224336203Z",
    "http_code": 201
  },
  "response": {
    "_id": "7f8bb693-47b3-40b8-8db3-f923aa6429f8",
    "template_id": "FASTER_PAYMENT_UK",
    "external_id": "f1642fe6-ebdf-4f71-b5ab-14dd88da3a80",
    "amount": "1.0",
    "requested_execution_date": "2026-04-23",
    "currency": "GBP",
    "debtor": {
      "account": {
        "value": "3046697121",
        "currency": "GBP"
      },
      "own_reference": "own message"
    },
    "creditor": {
      "account": {
        "value": "30466971"
      },
      "name": "Name",
      "bank": {
        "address": {
          "line_1": "22 Market Road",
          "line_2": "Manchester"
        },
        "bank_code": "445566",
        "country": "GB",
        "name": "Example Bank"
      },
      "message": "message"
    },
    "payment_status": "AUTHORIZATION_PARTIAL",
    "payment_status_reason": "info.payment.verification_required",
    "_links": [
      {
        "rel": "self",
        "href": "/uk/v1/payments"
      },
      {
        "rel": "verify",
        "href": "/uk/v1/payments/7f8bb693-47b3-40b8-8db3-f923aa6429f8/verify"
      },
      {
        "rel": "cancel",
        "href": "/uk/v1/payments/7f8bb693-47b3-40b8-8db3-f923aa6429f8/cancel"
      },
      {
        "rel": "details",
        "href": "/uk/v1/payments/7f8bb693-47b3-40b8-8db3-f923aa6429f8"
      }
    ]
  }
}
 

In this example, the payment has been created successfully and beneficiary verification is required. The next step for the TPP is to call PUT /uk/v1/payments/{payment_id}/verify.

The same endpoint can also return other states, for example:

• AUTHORIZATION_PARTIAL with payment_status_reason: info.payment.confirmation_required
• AUTHORIZATION_PENDING with payment_status_reason: info.payment.confirmation_in_progress
• PAYMENT_ACCEPTED
• PAYMENT_EXECUTED
• PAYMENT_CANCELLED
• PAYMENT_REJECTED
• AUTHORIZATION_FAILED

Verify Payment examples

PUT /uk/v1/payments/{payment_id}/verify

This endpoint is used when the payment is in AUTHORIZATION_PARTIAL with payment_status_reason: info.payment.verification_required.

Request example

This example continues the Faster Payments example above and starts beneficiary verification using the decoupled SCA flow.

{
  "authentication_type": "DECOUPLED",
  "authentication_method": "MTA"
}

Response example

{
  "group_header": {
    "message_identification": "3e86b80d01e488c5",
    "creation_date_time": "2026-04-22T12:03:07.515600485Z",
    "http_code": 200
  },
  "response": {
    "_id": "7f8bb693-47b3-40b8-8db3-f923aa6429f8",
    "template_id": "FASTER_PAYMENT_UK",
    "external_id": "f1642fe6-ebdf-4f71-b5ab-14dd88da3a80",
    "amount": "1.0",
    "requested_execution_date": "2026-04-23",
    "execution_date": "2026-04-23",
    "currency": "GBP",
    "debtor": {
      "account": {
        "value": "3046697121",
        "currency": "GBP"
      },
      "own_reference": "own message"
    },
    "creditor": {
      "account": {
        "value": "30466971"
      },
      "name": "Name",
      "bank": {
        "address": {
          "line_1": "22 Market Road",
          "line_2": "Manchester"
        },
        "bank_code": "445566",
        "country": "GB",
        "name": "Example Bank"
      },
      "message": "message"
    },
    "payment_status": "AUTHORIZATION_PENDING",
    "payment_status_reason": "info.payment.verification_in_progress",
    "_links": [
      {
        "rel": "self",
        "href": "/uk/v1/payments/7f8bb693-47b3-40b8-8db3-f923aa6429f8/verify"
      },
      {
        "rel": "details",
        "href": "/uk/v1/payments/7f8bb693-47b3-40b8-8db3-f923aa6429f8"
      }
    ]
  }
}

In this example, Open Banking has created a verification signing order and the payment is now waiting for PSU action in Nordea App.

After the PSU successfully signs, the payment will transition to:

• AUTHORIZATION_PARTIAL with payment_status_reason: info.payment.confirmation_required

The TPP should poll GET /uk/v1/payments/{payment_id} and, once the payment reaches that state, continue with PUT /uk/v1/payments/{payment_id}/confirm.

Confirm Payment examples

PUT /uk/v1/payments/{payment_id}/confirm

This endpoint is used when the payment is in AUTHORIZATION_PARTIAL with payment_status_reason: info.payment.confirmation_required.

Request example

This example continues the Faster Payments example above after beneficiary verification has been completed and the payment is ready for confirmation.

{
  "authentication_type": "DECOUPLED",
  "authentication_method": "MTA"
}

Response example

{
  "group_header": {
    "message_identification": "97fec32d3f0db402",
    "creation_date_time": "2026-04-22T12:05:31.834792973Z",
    "http_code": 200
  },
  "response": {
    "_id": "7f8bb693-47b3-40b8-8db3-f923aa6429f8",
    "template_id": "FASTER_PAYMENT_UK",
    "external_id": "f1642fe6-ebdf-4f71-b5ab-14dd88da3a80",
    "amount": "1.0",
    "requested_execution_date": "2026-04-23",
    "execution_date": "2026-04-23",
    "currency": "GBP",
    "debtor": {
      "account": {
        "value": "3046697121",
        "currency": "GBP"
      },
      "own_reference": "own message"
    },
    "creditor": {
      "account": {
        "value": "30466971"
      },
      "name": "Name",
      "bank": {
        "address": {
          "line_1": "22 Market Road",
          "line_2": "Manchester"
        },
        "bank_code": "445566",
        "country": "GB",
        "name": "Example Bank"
      },
      "message": "message"
    },
    "payment_status": "AUTHORIZATION_PENDING",
    "payment_status_reason": "info.payment.confirmation_in_progress",
    "_links": [
      {
        "rel": "self",
        "href": "/uk/v1/payments/7f8bb693-47b3-40b8-8db3-f923aa6429f8/confirm"
      },
      {
        "rel": "details",
        "href": "/uk/v1/payments/7f8bb693-47b3-40b8-8db3-f923aa6429f8"
      }
    ]
  }
}

In this example, Open Banking has created a confirmation signing order and the payment is now waiting for PSU action in Nordea App.

After the PSU successfully signs, the payment will transition to:

• PAYMENT_ACCEPTED

From there, the payment is processed automatically and will later move to a final state such as PAYMENT_EXECUTED or PAYMENT_REJECTED.

The TPP should poll GET /uk/v1/payments/{payment_id} until the payment reaches the next state.

Cancel Payment examples

PUT /uk/v1/payments/{payment_id}/cancel

This endpoint is used to cancel a payment that is still cancellable. This example uses the CHAPS payment created in Create Payment examples.

Request example

This example assumes that the CHAPS payment has not yet been executed and is still eligible for cancellation.

{
  "authentication_type": "DECOUPLED",
  "authentication_method": "MTA"
}

Response example

{
  "group_header": {
    "message_identification": "6373625f227b7289",
    "creation_date_time": "2026-04-22T12:09:21.678957383Z",
    "http_code": 200
  },
  "response": {
    "_id": "1a9485ba-aee8-4412-bfcb-a5be44779964",
    "template_id": "CHAPS_PAYMENT_UK",
    "external_id": "0c2efdc7-a2cb-4df8-9d4e-dc3bfc508e71",
    "amount": "285000.00",
    "requested_execution_date": "2026-04-23",
    "execution_date": "2026-04-23",
    "currency": "GBP",
    "debtor": {
      "account": {
        "value": "3046697121",
        "currency": "GBP"
      },
      "own_reference": "Property completion"
    },
    "creditor": {
      "account": {
        "value": "87654321"
      },
      "name": "Smith and Co Client Account",
      "address": {
        "line_1": "22 Market Road",
        "line_2": "Manchester"
      },
      "bank": {
        "address": {
          "line_1": "22 Market Road",
          "line_2": "Manchester"
        },
        "bank_code": "445566",
        "country": "GB",
        "name": "Example Bank"
      },
      "message": "Completion funds. Ref 2026-041. Client A",
      "srd_roll_number": "MATTER7788"
    },
    "payment_status": "AUTHORIZATION_PENDING",
    "payment_status_reason": "info.payment.cancellation_in_progress",
    "_links": [
      {
        "rel": "self",
        "href": "/uk/v1/payments/1a9485ba-aee8-4412-bfcb-a5be44779964/cancel"
      },
      {
        "rel": "details",
        "href": "/uk/v1/payments/1a9485ba-aee8-4412-bfcb-a5be44779964"
      }
    ]
  }
}

In this example, Open Banking has created a cancellation signing order and the payment is now waiting for PSU action in Nordea App.

After the PSU successfully signs, the payment will normally transition to:

• PAYMENT_CANCELLED

If the payment has already been executed before the cancellation is completed, cancellation will fail and the payment may instead remain in PAYMENT_EXECUTED.

The TPP should poll GET /uk/v1/payments/{payment_id} until the payment reaches its final state.

Payment List examples

GET /corporate/v3/payments This endpoint returns a list of payments filtered by the specified query parameters.

The following query parameters are supported:

creation_from_timestamp: {creation_from_timestamp}
creation_to_timestamp: {creation_to_timestamp}
execution_from_date: {execution_from_date}
execution_to_date: {execution_to_date}
requested_execution_from_date: {requested_execution_from_date}
requested_execution_to_date: {requested_execution_to_date}
debtor_account: {debtor_account}
min_amount: {min_amount}
max_amount: {max_amount}
payment_status: {payment_status}
created_by: {created_by}
page: {page}
size: {size}
created_by_me: {true/false}
confirmable_by_me: {true/false}

Where the request is valid the response will be 200 SUCCESS and formatted like the example below

{
  "group_header": {
    "message_identification": "4f8c4dc934a6ca20",
    "creation_date_time": "2026-04-22T12:15:45.858435217Z",
    "http_code": 200
  },
  "response": {
    "payments": [
      {
        "_id": "1a9485ba-aee8-4412-bfcb-a5be44779964",
        "template_id": "CHAPS_PAYMENT_UK",
        "external_id": "0c2efdc7-a2cb-4df8-9d4e-dc3bfc508e71",
        "amount": "285000.00",
        "requested_execution_date": "2026-04-23",
        "execution_date": "2026-04-23",
        "currency": "GBP",
        "debtor": {
          "account": {
            "value": "3046697121",
            "currency": "GBP"
          },
          "own_reference": "Property completion"
        },
        "creditor": {
          "account": {
            "value": "87654321"
          },
          "name": "Smith and Co Client Account",
          "address": {
            "line_1": "22 Market Road",
            "line_2": "Manchester"
          },
          "bank": {
            "address": {
              "line_1": "22 Market Road",
              "line_2": "Manchester"
            },
            "bank_code": "445566",
            "country": "GB",
            "name": "Example Bank"
          },
          "message": "Completion funds. Ref 2026-041. Client A",
          "srd_roll_number": "MATTER7788"
        },
        "payment_status": "PAYMENT_CANCELLED",
        "_links": [
          {
            "rel": "details",
            "href": "/uk/v1/payments/1a9485ba-aee8-4412-bfcb-a5be44779964"
          }
        ]
      },
      {
        "_id": "7f8bb693-47b3-40b8-8db3-f923aa6429f8",
        "template_id": "FASTER_PAYMENT_UK",
        "external_id": "f1642fe6-ebdf-4f71-b5ab-14dd88da3a80",
        "amount": "1.0",
        "requested_execution_date": "2026-04-23",
        "execution_date": "2026-04-23",
        "currency": "GBP",
        "debtor": {
          "account": {
            "value": "3046697121",
            "currency": "GBP"
          },
          "own_reference": "own message"
        },
        "creditor": {
          "account": {
            "value": "30466971"
          },
          "name": "Name",
          "bank": {
            "address": {
              "line_1": "22 Market Road",
              "line_2": "Manchester"
            },
            "bank_code": "445566",
            "country": "GB",
            "name": "Example Bank"
          },
          "message": "message"
        },
        "payment_status": "PAYMENT_ACCEPTED",
        "_links": [
          {
            "rel": "details",
            "href": "/uk/v1/payments/7f8bb693-47b3-40b8-8db3-f923aa6429f8"
          },
          {
            "rel": "cancel",
            "href": "/uk/v1/payments/7f8bb693-47b3-40b8-8db3-f923aa6429f8/cancel"
          }
        ]
      }
    ],
    "_links": [
      {
        "rel": "first",
        "href": "/uk/v1/payments?execution_from_date=2026-04-23&execution_to_date=2026-04-23&page=1&size=20"
      },
      {
        "rel": "self",
        "href": "/uk/v1/payments?execution_from_date=2026-04-23&execution_to_date=2026-04-23&page=1&size=20"
      },
      {
        "rel": "last",
        "href": "/uk/v1/payments?execution_from_date=2026-04-23&execution_to_date=2026-04-23&page=1&size=20"
      }
    ]
  }
}

Sandbox Test Data

This section lists the test data available in the sandbox environment for the UK Corporate Payments API.

Agreement and Users

The following agreement has UK payment accounts available. The sandbox provides five users with different payment authorization permissions on every account:

Agreement number: 164301528862

Use user 11497209006 (ACT_ALONE) for straightforward single-user payment flow testing. Use users 11497209007 together with another TWO_TOGETHER user for multi-authorization testing.

UK Payment Accounts

All accounts below belong to agreement 164301528862. The retail_number is the 10-digit account number used in the debtor.account.value field when initiating a payment.

All five users listed in Agreement and Users section have access to every account above, each with their respective permission level.