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.
|
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.
|
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)
Account 2 (KWD)
Account 3 (USD)
|
This returns all the balances of a given account as follows: Account 1 (EUR) – as per PSU 1. Account 4 (JPY)
Account 5 (GBP)
|
3.3 |
> Get Account Transactions |
This returns the transactions of a given account as follows: Account 1 (EUR)
Account 2 (KWD)
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)
Account 5 (GBP)
|
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:
- Get payment details: GET /payments/pain.001-sepa-credit-transfers/GPTPP190409125959000001
- Create payment authorisation: POST /payments/pain.001-sepa-credit-transfers/GPTPP190409125959000001/authorisations
- 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.