Skip to main content

Service User Testing

bLink offers a testing tool for Service User that enables the simulation of the counterpart Service Provider.

Service Provider Simulator

info

Please contact the bLink Support Portal to get access to the authorize endpoint of the SP-Simulator.

XE → SP-Simulator XP → SP-Simulator

Features:

  • Simulate Consent-Flow with a Service Provider (no UI-interaction)
  • Simulate API Responses (all business-APIs)
Simulated API Responses

Please note that the responses from the Service Provider Simulator are mostly static ("Slim-Mock"). Therefore, it can only be used to test if consent-flow and routing works as expected, not for actual business-content.

Testing Capabilities Account & Payment Services

The bLink Service Provider Simulator provides six predefined bank accounts, each with unique properties, enabling API consumers to simulate various test cases:

  • Account 1: No intraday data, no bookings.
  • Account 2: Contains past bookings.
  • Account 3: Held in EUR, with one initial booking and unprocessed data from the previous working day.
  • Account 4: Bookings only for today’s date.
  • Account 6: Valid IBAN with today’s bookings (designation will change).
  • Account 7: Held in CHF but allows both CHF and EUR transactions.

All accounts, except Account 3, are held in CHF. Account 7 supports both CHF and EUR currencies, with CHF as the primary.

Data Generation and History

When consent is established, transaction history is generated for five working days before the current day. Weekends are treated as non-working days, returning a 204 status code if data is requested for non-working days or more than six days in the past.

DayMondayTuesdayWednesdayThursdayFridaySaturdaySundayMondayTuesdayWednesdayThursdayFridaySaturdaySunday
Date (relative)today - 8dtoday - 7dtoday - 6dtoday - 5dtoday - 4dWeekendWeekendtoday - 3dtoday - 2dtoday - 1dtoday---
Response204204204Data availableData available204204Data availableData availableData availableData available---

If consent is established on a weekend, the history of transactions is generated backwards from the previous working day on.

Payments

Users can submit a payment in JSON or XML using the PSS API (/payments or /iso20022/payments endpoint) in the Simulator. The payload is predefined, but users must adjust the following details:

  • messageId / MsgId: Unique message identifier
  • requestedExecutionDate / ReqdExctnDt: Date when the payment is to be executed
  • debtorAccount / DbtrAcct: The account number from which the payment will be made

The transaction will appear in the debtor account’s history, but not in the creditor account.

info
  • Batch bookings in XML are not supported.
  • Transactions remain persistent as long as consent is active. However, all data, including transactions, is automatically reset approximately every two weeks. If consent is manually deleted, all associated accounts and transactions are also removed.

Specific Test-Cases for Account Information Service

  • Account 1: Simulates a Service Provider that does not support intraday data. Requests will return a 404 status with Error-Type /problems/NOT_IMPLEMENTED.
  • Account 2: Provides transaction history for past days.
  • Account 3: Held in Euro, with one initial booking for a historic day. This account can be used to simulate the behavior when a provider has not yet processed the previous booking day. As a result, Status Code 202 will be returned, if data is retrieved for the last booking day.
  • Account 4 & 6: Contains transactions only for the day when the user established consent.
  • Account 7: No transaction history, allows both CHF and EUR currencies, with CHF as the main currency.

Data is reset roughly every two weeks, and deleting consent removes all associated accounts and transactions.