Catalogue purpose
Sandbox Mock Data contains the synthetic values required for the published fixtures.
It does not contain credentials, certificates, internal routing values or implementation triggers.
Nature of the sandbox
The sandbox is a static API simulator. It returns predefined responses for the documented operations and does not connect to SMBC customer, account, payment or authentication systems.
The sandbox does not maintain a stateful end-to-end lifecycle. An operation does not change the response returned by a later operation. For example:
- deleting the predefined payment returns the documented successful deletion response, but does not remove the payment fixture;
- starting payment authorisation returns the documented authorisation resource, but does not change the payment status;
- the predefined authorisation-status response remains finalised;
- creating or retrieving a signing basket does not change the predefined scaStatus or transactionStatus returned for the Sandbox fixture; and
- an scaRedirect value does not provide a working SCA journey.
Use each operation as an independent response-contract test. Do not rely on the result of one sandbox call to alter the result of another.
Supported institutions and synthetic customers
Supported institutions, synthetic customers and account labels
SMBC institution
SMBC Bank International plc, London
Synthetic customer
Silk Harbour London Plc
Account labels
- SH London GBP Account
- SH London JPY Account
SMBC institution
SMBC Düsseldorf Branch
Synthetic customer
Silk Harbour Düsseldorf GmbH
Account labels
- SH Düsseldorf EUR Account
- SH Düsseldorf USD Account
SMBC institution
SMBC Brussels Branch
Synthetic customer
Silk Harbour Brussels SA
Account labels
- SH Brussels EUR Account
- SH Brussels USD Account
SMBC institution
SMBC Bank EU AG, Frankfurt
Synthetic customer
Silk Harbour Frankfurt GmbH
Account labels
- SH Frankfurt EUR Account
- SH Frankfurt USD Account
SMBC institution
SMBC Bank EU AG, Paris Branch
Synthetic customer
Silk Harbour Paris SA
Account labels
- SH Paris EUR Account
- SH Paris USD Account
Use the sandbox endpoint for the selected institution as described in Institution and resource scope.
Persona types
The three PSU persona types apply to each synthetic customer listed above.
Published PSU persona types and capabilities
PSU-ID
PSU1
Public capability
Account-information access; no payment-creation or payment-authorisation access
Recommended use
Consent and account-information testing
PSU-ID
PSU2
Public capability
Account-information, payment-creation and payment-authorisation access
Recommended use
Payment-capable consent and access testing
PSU-ID
PSU3
Public capability
Account-information, payment-creation and payment-authorisation access
Recommended use
Tests involving another payment-capable user
Payment-related capability in a consent fixture confirms the access returned by the consent response; it does not indicate that a payment-operation fixture is published in this catalogue.
Accounts
All three published PSU personas can access the two accounts belonging to their synthetic customer.
Published synthetic accounts
SMBC institution
SMBC Bank International plc, London
Account label
SH London GBP Account
BBAN
220001
IBAN
GB98SMBC40512500220001
Currency
GBP
SMBC institution
SMBC Bank International plc, London
Account label
SH London JPY Account
BBAN
220002
IBAN
GB71SMBC40512500220002
Currency
JPY
SMBC institution
SMBC Düsseldorf Branch
Account label
SH Düsseldorf EUR Account
BBAN
440001
IBAN
DE10301103000000440001
Currency
EUR
SMBC institution
SMBC Düsseldorf Branch
Account label
SH Düsseldorf USD Account
BBAN
440002
IBAN
DE80301103000000440002
Currency
USD
SMBC institution
SMBC Brussels Branch
Account label
SH Brussels EUR Account
BBAN
770001
IBAN
BE42189770001033
Currency
EUR
SMBC institution
SMBC Brussels Branch
Account label
SH Brussels USD Account
BBAN
770002
IBAN
BE08189770002033
Currency
USD
SMBC institution
SMBC Bank EU AG, Frankfurt
Account label
SH Frankfurt EUR Account
BBAN
000001
IBAN
DE07505103000000000001
Currency
EUR
SMBC institution
SMBC Bank EU AG, Frankfurt
Account label
SH Frankfurt USD Account
BBAN
000002
IBAN
DE77505103000000000002
Currency
USD
SMBC institution
SMBC Bank EU AG, Paris Branch
Account label
SH Paris EUR Account
BBAN
720001
IBAN
FR7615250000010000072000149
Currency
EUR
SMBC institution
SMBC Bank EU AG, Paris Branch
Account label
SH Paris USD Account
BBAN
720002
IBAN
FR7615250000010000072000246
Currency
USD
The accounts can be used for the published account-list, account-details, balance and transaction fixtures.
Use the resourceId returned by the account-list operation in later account-specific requests. Do not construct an account resource ID from an institution, BBAN or IBAN.
Consent fixtures
Predefined consent fixtures
Fixture and Consent ID
Valid PSU1 consentId
b1c5db7a-e9ce-48ee-b94b-1ac63b1fd9c8
PSU-ID
PSU1
Consent status
valid
SCA status
finalised
Supported use
Account-information operations
Fixture and Consent ID
Valid PSU2 consentId
d63f3bbd-4245-4a59-b468-384289bdb941
PSU-ID
PSU2
Consent status
valid
SCA status
finalised
Supported use
Account-information operations and confirmation of payment-related access in the consent response
Fixture and Consent ID
Valid PSU3 consentId
e3819ed5-3f58-4aa8-ab12-1ac18630e1a6
PSU-ID
PSU3
Consent status
valid
SCA status
finalised
Supported use
Account-information operations and confirmation of payment-related access in the consent response
Fixture and Consent ID
Consent awaiting completion
fa38d8a7-68a6-4bb2-abf0-62be1348ce6b
PSU-ID
Not specified for this fixture
Consent status
received
SCA status
started
Supported use
Consent-status retrieval and unusable-consent testing
Fixture and Consent ID
Expired consent
9a7e2c1f-5b44-4a91-8e6d-3f2b7c8e91ab
PSU-ID
Not specified for this fixture
Consent status
expired
SCA status
failed
Supported use
Consent-status retrieval and unusable-consent testing
Use each fixture through the selected institution endpoint and only for its documented response.
Do not assume that creating, deleting or otherwise acting on a fixture changes its later response unless this catalogue explicitly states that behaviour.
Accounts fixtures
For account-specific operations, use a resourceId returned by A-01 through the same institution endpoint.
Published account-information fixtures
Scenario ID
A-01
Operation
Retrieve account list
Test input
Selected institution endpoint and one of the three valid Consent IDs
Expected public result
The two published accounts for the selected synthetic customer are returned
Scenario ID
A-02
Operation
Retrieve account details
Test input
Account resourceId returned by A-01
Expected public result
The predefined details for the selected account are returned
Scenario ID
A-03
Operation
Retrieve account balances
Test input
Account resourceId returned by A-01
Expected public result
The predefined synthetic balance records for the selected account are returned
Scenario ID
A-04
Operation
Retrieve booked transactions
Test input
Account resourceId returned by A-01
Expected public result
The predefined booked-transaction report for the selected account is returned
Scenario ID
A-05
Operation
Retrieve an unrecognised account resource
Test input
An unrecognised account resource ID
Expected public result
HTTP 404 with RESOURCE_UNKNOWN
Scenario ID
A-06
Operation
Retrieve account list / details / balances / transactions
Test input
All operations defined in A-01, A-02, A-03, A-04 using consentId pending or consentId expired
Expected public result
HTTP 401 with CONSENT_INVALID
Scenario ID
A-07
Operation
Retrieve account list / details / balances / transactions
Test input
All operations defined in A-01, A-02, A-03, A-04 using any other consentId not defined in the consent fixtures
Expected public result
HTTP 403 with CONSENT_UNKNOWN
Scenario ID
A-08
Operation
Any account operation
Test input
TPP certificate is PIS only.
Expected public result
HTTP 401 with ROLE_INVALID
Balance responses contain predefined synthetic amounts. Use the returned values when validating response parsing.
Each published account returns a predefined booked-transaction report.
Pagination is not included in the current deterministic fixture catalogue.
Payments fixtures
The sandbox provides one predefined payment fixture accessible to all five institution endpoints. It represents a bulk SEPA credit transfer using pain.001.001.03.
Field
Payment product
Published value
pain.001-sepa-credit-transfers
Field
Payment ID
Published value
P2-sepa-credit-bulk
Field
Payment status
Published value
PATC
Field
Payment format
Published value
pain.001.001.03
Field
Payment type
Published value
Bulk SEPA credit transfer
Field
Authorisation ID
Published value
1b27cc11-3027-435e-a7fa-86db03f9cc0b
The operations described below are independent static mocks. Calling one operation does not alter the response returned by another.
Required consent
Use one of the published valid payment-capable Consent IDs for PSU2 or PSU3, together with the corresponding PSU-ID and selected institution endpoint.
Create the payment fixture
Call: POST /payments/pain.001-sepa-credit-transfers
Submit a schema-valid pain.001.001.03 bulk SEPA credit transfer. The request content does not select or create a different sandbox payment fixture.
The sandbox returns 201 Created, echoes X-Request-ID, Location, and returns the current UTC date in the Date response header.
The response is predefined. The sandbox does not create or persist a new payment resource from the submitted pain.001.
Retrieve the payment fixture
Call: GET /payments/pain.001-sepa-credit-transfers/P2-sepa-credit-bulk
The sandbox returns:
- 200 OK;
- the request’s X-Request-ID;
- the current UTC date in the Date response header; and
- the predefined pain.001.001.03 bulk SEPA credit-transfer payload.
The returned XML is the predefined payment fixture. It is not generated from an earlier POST /payments request.
Retrieve payment status
Call: GET /payments/pain.001-sepa-credit-transfers/P2-sepa-credit-bulk/status
The sandbox returns:
- 200 OK;
- the request’s X-Request-ID;
- the current UTC date in the Date response header; and
- the predefined pain.002 status report for P2-sepa-credit-bulk.
The pain.002 response reports the fixture’s predefined status. Its content does not progress as a result of payment creation, authorisation, deletion or repeated status retrieval.
Delete the payment fixture
Call: DELETE /payments/pain.001-sepa-credit-transfers/P2-sepa-credit-bulk
The sandbox returns: 204 No Content, and echoes the X-Request-ID and returns the current UTC date in the response header.
The response has no body.
This validates the successful cancellation response contract only. The static fixture is not removed. A later retrieval of P2-sepa-credit-bulk continues to return the predefined payment response.
Start payment authorisation
Call: POST /payments/pain.001-sepa-credit-transfers/P2-sepa-credit-bulk/authorisations
The sandbox returns 201 Created with:
- the request’s X-Request-ID;
- the current UTC date in the Date response header;
- Location: /payments/pain.001-sepa-credit-transfers/P2-sepa-credit-bulk/authorisations/1b27cc11-3027-435e-a7fa-86db03f9cc0b
- ASPSP-SCA-Approach: REDIRECT
The scaRedirect value is a static response fixture. It is not a working SCA URL and does not initiate an SMBC Digital journey. Opening it may return an error.
The authorisation response does not change the payment’s predefined PATC status.
Retrieve payment authorisation status
Call: GET /payments/pain.001-sepa-credit-transfers/P2-sepa-credit-bulk/authorisations/1b27cc11-3027-435e-a7fa-86db03f9cc0b
The sandbox returns 200, "scaStatus": "finalised" and echoes the X-Request-ID and returns the current UTC date in the response header.
This is a predefined static response. It does not mean that a sandbox SCA challenge was completed, and it does not cause the payment status to change.
The difference between:
- received returned when the authorisation fixture is created; and
- finalised returned when that fixture is retrieved
is part of the predefined response set. It is not a lifecycle transition caused by the TPP’s calls.
Signing-basket fixtures
The sandbox provides one predefined signing-basket response. The complete predefined creation and retrieval responses are provided in the signing-basket operation examples in the Payments API Reference.
Required consent
Use one of the published valid payment-capable Consent IDs for PSU2 or PSU3, together with the corresponding PSU-ID and selected institution endpoint.
Create the signing basket
Call: POST /signing-baskets
The sandbox returns 201 Created with:
- the request’s X-Request-ID;
- the current UTC date in the Date response header;
- Location: /signing-baskets/basketId-4760-acac-eba4fbbbf780
- ASPSP-SCA-Approach: REDIRECT
The returned scaRedirect value is a static fixture. It does not provide a working SCA journey and does not change the basket or its included payments.
Retrieving the signing basket
Call: GET /signing-baskets/basketId-4760-acac-eba4fbbbf780
The response returns predefined Payment IDs together with the basket’s scaStatus and transactionStatus. The transactionStatus identifies whether the predefined basket authorisation is awaiting successful completion, was successful or was unsuccessful, using PATC, ACTC or RJCT as defined in the Payments API Reference.
The response is static. Creating the signing basket or using the returned scaRedirect does not change the response returned by a later retrieval request.
The Payment IDs returned in the basket response are predefined fixture values. Their inclusion does not mean that separate payment retrieval, status, cancellation or authorisation fixtures are available for those Payment IDs.
The basket transaction status does not provide the individual lifecycle status of an included payment. Use the applicable payment-status operation where a corresponding payment fixture is available.
Funds-confirmation fixture
Required consent
Use one of the published valid payment-capable Consent IDs for PSU2 or PSU3, together with the corresponding PSU-ID and selected institution endpoint.
Perform a funds confirmation check
Call: POST /funds-confirmations
The sandbox returns 200 OK and the predefined positive funds-availability result. The response body is defined in the funds-confirmation operation example in the Payments API Reference.
The result is static and always indicates that funds are available. The sandbox does not:
- check a live or simulated account balance;
- reserve funds;
- reduce a balance;
- create a payment; or
- change the result of a later request.
Use this fixture to validate handling of the successful funds-confirmation response only.
Payment-related errors
The sandbox may return the following published errors for payment-related operations:
Error
ROLE_INVALID
Meaning
The certificate does not provide the required PISP role.
Required TPP action
Use a certificate representing the required PISP role.
Error
CONSENT_INVALID
Meaning
The supplied consent is not in a usable lifecycle state.
Required TPP action
Use a valid authorised consent.
Error
CONSENT_UNKNOWN
Meaning
The supplied consent is not available in the request context.
Required TPP action
Verify the Consent ID and institution endpoint.
Error
RESOURCE_UNKNOWN
Meaning
The referenced payment, authorisation, basket or account is not available in the request context.
Required TPP action
Use the identifiers published for the selected fixture.
Error
PRODUCT_UNKNOWN
Meaning
The payment product is not supported for the selected institution or is not recognised.
Required TPP action
Use a supported product for the selected institution.
Error
STATUS_INVALID
Meaning
The requested action is not permitted for the resource in its current status.
Required TPP action
Use the operation supported by the selected fixture.
Common sandbox errors
Common sandbox error fixtures
Scenario ID
E-01
Operation
Any Accounts Service operation
Test condition
Use a certificate without the AISP role
HTTP status
401
Public error code
ROLE_INVALID
Required TPP action
Use a certificate representing the required AISP role
Scenario ID
E-02
Operation
Protected consent or account operation
Test condition
Use the consent awaiting completion or the expired Consent ID
HTTP status
401
Public error code
CONSENT_INVALID
Required TPP action
Use a valid authorised consent
Scenario ID
E-03
Operation
Consent or account operation
Test condition
Use an unrecognised Consent ID
HTTP status
403
Public error code
CONSENT_UNKNOWN
Required TPP action
Verify the Consent ID and institution endpoint
Scenario ID
E-04
Operation
Account-specific operation
Test condition
Use an unrecognised account resource ID
HTTP status
404
Public error code
RESOURCE_UNKNOWN
Required TPP action
Use an account resource returned through the selected institution endpoint
Use one representative test for each error category. The same error does not need to be repeated for every account operation or institution.