-
Notifications
You must be signed in to change notification settings - Fork 0
Use of this spec
For direct communication via the Card API, both parties must negotiate the level of the API used and agree on a level.
If only GET requests are used, it is possible that the sender supports a higher level of the API. In this case, the recipient must ignore additional information in the response.
In practice, communication is often redirected via third parties, so-called proxies. An example of such an implementation would be the bLink platform of SIX. A proxy supports all levels of the API and leaves the selection of the level to the communicating entities. The selection of the level determines the information content of the delivered data. In this scenario, it is also possible to communicate via different levels:
- Data provider supports higher level
In this case, the proxy filters all undefined fields of the level and the TPP receives all data as defined in its level. - Data provider supports lower level
In this case, the proxy fills in the missing fields with dummy data. In this way, the TPP receives a data structure with the expected fields. Caution: This response still only contains the information content of the level supported by the data provider.
SFTI | ca-card
Wiki
Operational Guide
- Scope of the Card API
- Central Design Decisions
- Card API Level 1
- Card API Level 2
- Card API Level 3
- Use of this spec
- Appendix
Version Management
Common Implementation Guidelines