Skip to main content

Sandbox Mock Data

Common

#

Step > Sub-Step

PSU 1 using TPP 1

PSU 2 using TPP 1

1

TPP creates consent

The TPP creates a new consent for the PSU to authorise

1.1

> Get TPP access token

Not applicable – the TPP access token you receive is an authentic access token issued by the API Gateway.

As per PSU 1.

1.2

> Create consent

If the request is valid – see Testing Your Application above – the sandbox will always return a fixed consent response for PSU 1. Let’s call this consent 1.

  • PSU-ID="psu_01" (without double quotes)

As per PSU 2 but will return a fixed consent response for PSU 2 that will be different from that for PSU 1. Let’s call this Consent 2.

  • PSU-ID="psu_02" (without double quotes)

2

PSU Authorises Consent with OAuth

The PSU must explicitly authorise the TPP to act on his behalf

2.1

> TPP redirects PSU to SMBC Sandbox Authorisation Service

You must use the Consent ID for Consent 1, notably "d3a7cbff-76da-42b3-a90e-58ef0bff6f25" (without double quotes). Note that these identifiers are fixed and pre-configured in the Sandbox mock data. Note that the code_challenge, and by extension the code_verifier, are determined by you. The Sandbox will use any values you supply and enforce the PKCE checks in Step 2.4.

As per PSU 1 but using Consent 2, notably "q3j4pmrr-76jp-51o7-z35k-24qu0ljj3z41" (without double quotes).

2.2

> Get PSU authorisation code

Not applicable – this is an internal SMBC step.

As per PSU 1.

2.3

> SMBC redirects PSU back to TPP

Not applicable – no mock data in the redirection back to your TPP application.

As per PSU 1.

2.4

> Exchange PSU authorisation code for PSU access token

Not applicable – no mock data used in this step. Do note that you responsible for ensuring the correct code_verifier is supplied in this step. In particular, code_challenge in Step 2.1 must match SHA256(code_verifier).

As per PSU 1.

Account Service

#

Step > Sub-Step

PSU 1 using TPP 1

PSU 2 using TPP2

3

AIS Operation

The TPP performs the operation using the PSU access token

3.1

> Get Account List

Consent 1 is authorised to access three accounts that we shall refer to as Account 1, Account 2 and Account 3. Each account has a unique identifier that you can use to retrieve the balances and transactions for that given account. The accounts list also returns the interim available balance.

Consent 2 is authorised for Account 1, Account 4 and Account 5. Note that there is an overlap between the two consents, namely Account 1.

3.2

> Get Account Balance

This returns all the balances of a given account as follows:

Account 1 (EUR)

  • Interim available = 1001.21
  • Interim booked = 1000.11
  • Opening booked = 1000.01
  • Closing booked = 1000.31

Account 2 (KWD)

  • Interim available = -200.022
  • Interim booked = -200.012
  • Opening booked = -200.002
  • Closing booked = 200.032

Account 3 (USD)

  • Interim available = 30000.23
  • Interim booked = 30000.13
  • Opening booked = 30000.03
  • Closing booked = 30000.33

This returns all the balances of a given account as follows:

Account 1 (EUR) – as per PSU 1.

Account 4 (JPY)

  • Interim available = 400024
  • Interim booked = 400014
  • Opening booked = 400004
  • Closing booked = 400034

Account 5 (GBP)

  • Interim available = 50.25
  • Interim booked = 50.15
  • Opening booked = 50.05
  • Closing booked = 50.35

3.3

> Get Account Transactions

This returns the transactions of a given account as follows:

Account 1 (EUR)

  • Txn1 = EUR 1001.01
  • Txn2 = JPY 20002
  • Tnx3 = EUR -3000.03

Account 2 (KWD)

  • Txn4 = KWD 4000.004
  • Txn5 = EUR -5000.05

Account 3 (USD) – no transactions

This returns all the balances of a given account as follows:

Account 1 (EUR) – As per PSU 1

Account 4 (JPY)

  • Txn6 = EUR -6000.06
  • Txn7 = DKK -7000.07

Account 5 (GBP)

  • Txn8 = GBP 8000.08
  • Txn9 = GBP-9000.09
  • Tnx10 = EUR 10000.10

Payment Service

The following payments are pre-loaded in the sandbox for all non-POST operations.

Payment# Unique Identifier Product Type Currency Debit Amount Status Create Payment Authorisation Get Payment Authorisation Delete Payment

 

PIS Operation

The TPP performs the operation using the PSU access token

Payment1 GPTPP190409125959000001 pain.001-sepa-credit-transfers EUR 100.55 PATC - partially accepted, technically correct

Awaiting SCA - locked
Failure - HTTP 409 Status Invalid Started Success - HTTP 204 No Content
Payment2 GPTPP190409125959000002 pain.001-internal-transfers USD 200.15 RJCT - rejected Failure - 409 Status Invalid Finalised Failure - HTTP 405 Cancellation Invalid
Payment3 GPTPP190409125959000003 pain.001-swift-transfers JPY 30035 PATC - partially accepted, technically correct Success - SCA redirection Finalised Success - HTTP 204 No Content
Payment5 GPTPP190409125959000005 pain.001-chaps-payments GBP 500000.55 n.a. Failure - HTTP 409 Status Invalid Finalised Failure - HTTP 405 Cancellation Invalid
Payment6 GPTPP190409125959000006 pain.001-faster-payments GBP 600.65 RJCT - rejected Failure - HTTP 409 Status Invalid Finalised Failure - HTTP 405 Cancellation Invalid

For example, the following operations are applicable to Payment1:

  1. Get payment details: GET /payments/pain.001-sepa-credit-transfers/GPTPP190409125959000001
  2. Create payment authorisation: POST /payments/pain.001-sepa-credit-transfers/GPTPP190409125959000001/authorisations
  3. Delete payment: DELETE /payments/pain.001-sepa-credit-transfers/GPTPP190409125959000001

Additionally, POST /payments always returns a fixed payment identifier for a given payment product, that is pre-loaded in the sandbox. This never changes regardless of the request payload. For example, POST /payments/pain.001-sepa-credit-transfers always returns GPTPP190409125959000008.

Signing Basket Service

The following signing baskets are pre-loaded in the sandbox for all non-POST operations.

Basket#

Unique Identifier

Payments in Basket

Basket Status

 

PIS Operation

The TPP performs the operation using the PSU access token

Basket1

a9f28b85-9ac1-4aab-965c-e871cf2683e6

Payment1

Payment7

Finalised

Basket2

fab2d89e-5130-461b-9526-a738d96e728c

Payment5

Payment6

Failed

Basket3

7b461c2c-14ee-489f-b524-288359a94faf

Payment4

Payment5

Payment6

Payment7

Finalised

POST /signing-baskets always returns a fixed basket identifier, that is pre-loaded in the sandbox. This never changes regardless of the request payload. For example, POST /signing-baskets always returns 0de5878f-06dd-4f1c-9563-8e05e962bed3.

Funds Confirmation Service

The funds confirmation service always returns "true" regardless of the request payload.

Need help?

Check our FAQs for common queries, otherwise please get in touch with our API support team to discuss your on-boarding.