How does Online Data Provisioning work?
This method provides the most up-to-date check results. Each time SurePay receives a request for one of your accounts, we fetch the account data in real time via your data provisioning API. The data will be as current as you provide it to SurePay. However, this method requires additional work on your side, as a data provisioning API must be created.
Document History
| Version | Date | Description |
|---|---|---|
| 1.0 | 15 Jan 2025 | Original Digital Version, Aligned with PDF V1.3 |
| 1.1 | 20 Mar 2025 | Format & grammar changes, nothing impacting implementation |
Functional Overview
- API Request Initiation: The process begins when a Requesting PSP sends a request to SurePay through either the IBAN Name Check API or the VoP Gateway API. This request is made to verify the payee’s identity by matching the provided account details.
- Routing: SurePay routes the request based on the IBAN or BIC to the appropriate Data Provisioning API implemented by the PSP that holds the account.
- Account Data Retrieval: The PSP’s Data Provisioning API retrieves the relevant account information from its data lake. The API then returns the available data to SurePay, where it is processed by SurePay’s algorithm.
- Verification and Response: Using the retrieved account data, the SurePay algorithm verifies the payee’s information. Based on the matching results, SurePay provides feedback on whether the entered details align with the account data, enabling the requesting PSP to inform its Payment Service User (PSU).
Non-Functional Aspects and Security
The Online Provisioning API should include the following security controls:
- TLS (minimum TLS 1.2) or MTLS
- OAuth 2.0 Client Credentials Grant flow
- IP whitelisting (optional)
OAuth 2.0
Application layer security should be implemented in accordance with the OAuth 2.0 standard, using the client credentials grant type. The standard specification for this flow is available online: https://tools.ietf.org/html/rfc6749#section-4.4.
Technical Details
SurePay expects the following information from the API provider:
- Exact endpoints for both the production and test environments.
- Client credentials (provided either through dynamic registration or manually).
- The
/tokenendpoint, used with the client credentials to retrieve the access token.
Performance and Availability
- The Online Provisioning API should adhere to the highest availability standards, operating 24/7 to ensure the uninterrupted functionality of the SurePay solution. This extreme availability requirement necessitates at least an active-active infrastructure setup on the API provider's side, abstracted by a highly available DNS service for consumers.
- In the event of any downtime of the Online Data Provisioning API, SurePay will respond to requests with an internal server error.
- The latency of the Online Data Provisioning API significantly impacts overall response times. The target response time is 150ms, though, based on our experience, a fast yet realistic response time ranges between 50 and 100ms.
- Service Level Agreements (SLAs) for support, resolution times, availability, and other factors will be defined in a separate agreement with the PSP providing the Data Provisioning service.
Encoding and Special Characters
API requests and responses must use UTF-8 character encoding, which is the default encoding for JSON (RFC 7158 - Section 8.1).
From the SurePay solution’s perspective, any special characters provided by the API are excluded or replaced during the matching phase. However, in the case of name suggestions, SurePay will return the exact data received from the Online Data Provisioning API.