Skip to main content
This page documents sandbox credentials and known behaviours for each bank supported by Kashimi. Use these details when testing payment flows in the sandbox environment.
Sandbox credentials are shared test accounts. Do not use real personal or financial information in any sandbox environment.
FieldValue
Mobile phone+44 7255581517
Passcode0000
Revolut’s sandbox will always reject the payment after successful confirmation, due to insufficient funds in the test account. This is expected behaviour — use it only to test the authorisation flow.
FieldValue
Customer namePSU 1
User Nameobcoop1
Passwordobcoop1
There is also a obcoop2 account, but this is the receiver account hardcoded in the demo page. Always use obcoop1 as the payer.
Account EE264204278608993910 (the first account shown on the list) has no funds. Select a different account when initiating a payment.
Known issuesIf you encounter login or flow issues, delete the site cookies or use an incognito window.
FieldValue
User Name1234567
Password11111111111
Swedbank accepts any 7-digit username and any 11-digit password in sandbox. The values above are just one valid example.
FieldValue
User NameibsUser1
PasswordibsUser1
ibsUser1, ibsUser2, and ibsUser3 are all available. The appropriate user may vary depending on which country’s SEB instance you are testing.
FieldValue
User Name9311219639
The SCA redirect link in SEB Sweden’s sandbox is static — the fill flow cannot be tested.SCA authorisation finalises automatically after 30 seconds. The scaRedirect link will only appear if the authorisation is fetched within that window. After 30 seconds, the sandbox payment status changes to RJCT.
No credentials required — simply click and select when prompted in the sandbox flow.
FieldValue
Username111111
Luminor’s sandbox is frequently broken and may fail to log in or generate a valid URL. This is a known upstream issue with the bank’s sandbox environment.
Bunq’s sandbox requires additional setup before testing can begin.Setup steps
  1. Install the Android sandbox Bunq app: Android Emulator setup. You will need Android Studio or a physical Android device.
  2. Create a test user for the sandbox app: Bunq API documentation — create sandbox user
  3. Add money to your sandbox user account via the Request Inquiry API. You can also request money from [email protected] directly in the sandbox app (maximum €500 per request).
Bunq’s documentation site has a cookie-related bug — use an incognito window to view the full documentation.
FieldValue
User Name81954753
Password86xUKSWPgHy2H2XBt8cv
Credentials are stored in 1Password.You can also reset test accounts under Sandboxes in the Crosskey developer portal: crosskey.io — Sandbox management
FieldValue
User Nameuser1
Password1234
FieldValue
User NamepushDec
Passwordok
TAN1111111
Browser certificate setupTo access the Sparkassen sandbox bank portal, the sandbox certificate must be installed in your browser:
  1. Generate a .p12 certificate from your QWAC key and certificate: 
    openssl pkcs12 -export -inkey QWAC.key -in QWAC.pem -out QWAC.p12
  2. Import the generated QWAC.p12 into your browser’s private certificate store.
PSU IDs by brand
BankPSU IDNotes
Deutsche Bank6154033403Payment will be stuck in PENDING
NorisbankTBC—
Postbank33882000Payment will end up FAILED
You will be redirected twice during the flow (once for the AIS consent, once for the payment SCA). On both redirects, simply click SCA OK to proceed.
Deutsche Bank: Only one account is available per sandbox user. The bank pre-programmes it to simulate ACTC payment status — the payment will remain pending.Postbank: The sandbox requires different PSU IDs for the AIS consent request and the payment request, which cannot be simulated through the Kashimi demo page.
For additional test scenarios (e.g. SCA NOK), refer to the bank’s test data file: Test Data_6.0.xlsx.
PSU-IDPasswordOTPIBAN
VRK1234567890ALL123456DE39499999600000005111
For the full list of test PSU-IDs and scenarios, refer to:
N26’s sandbox uses email addresses to simulate different payment outcomes. Refer to the N26 sandbox documentation for full details.SEPA Credit Transfer
User emailUse caseStatus flow
[email protected]Payment is successfulRCVD → ACCP (2s) → ACFC (2s) → ACSC (2s)
[email protected]Payment successful after account selectionRCVD → ACCP (5s) → ACFC (5s) → ACSC (5s)
Instant SEPA Credit Transfer
User emailUse caseStatus flow
[email protected]Payment is successfulRCVD → ACCP (2s) → ACFC (2s) → ACCC (2s)
[email protected]Payment successful after account selectionRCVD → ACCP (5s) → ACFC (5s) → ACCC (5s)
Failure scenarios (SEPA & Instant SEPA)
User emailUse caseStatus flow
[email protected]Payment fails after account selection expiresRCVD → RJCT (5s)
[email protected]Payment fails — customer rejects certificationRCVD → RJCT (2s)
[email protected]Payment fails — user not authorised from given accountRCVD → RJCT
[email protected]Payment fails — provided account does not existRCVD → RJCT
PSU-IDOTP SMS
999999990412345678
Sandbox credentials reference: BPCE API Store — Payment Initiation
CountrySandbox UserIBANBBAN
SESANDBOX-INDIVIDUAL-SE-1SE3460000000000923450017923450017
SESANDBOX-INDIVIDUAL-SE-2SE4660000000000923462023923462023
The sandbox is mocked to SANDBOX-INDIVIDUAL-SE-1. When testing, use SE4660000000000923462023 as the receiver account.
Full account list: Handelsbanken sandbox test data (PDF)