Skip to content

Commit

Permalink
Added Payment API contents
Browse files Browse the repository at this point in the history
  • Loading branch information
@malagappan
malagappan committed Sep 13, 2017
1 parent bd6904a commit c8c8bb1
Showing 1 changed file with 53 additions and 27 deletions.
80 changes: 53 additions & 27 deletions README.md
View file
Original file line number Diff line number Diff line change
@@ -1,10 +1,11 @@
# [![apigee.com](http://apigee.com/about/sites/all/themes/apigee_themes/apigee_mktg/images/logo.png)](http://apigee.com) Openbank
# [![apigee.com](http://apigee.com/about/sites/all/themes/apigee_themes/apigee_mktg/images/logo.png)](http://apigee.com) Open bank

The Apigee Open Banking APIx solution simplifies and accelerates the process of delivering open banking by providing secure, ready-to-use APIs along with the computing infrastructure to support internal and external innovation.

## Update!

This repository is organized into the following sections
This document is organized into the following sections

[Overview](#overview)

[Design](#design)
- [Architecture](#architecture)
Expand All @@ -14,6 +15,7 @@ This repository is organized into the following sections
[Setup](#setup)
- [Getting Started](#getting-started)
- [Installation](#installation)
- [Test](#Test)
- [Developer Portal](#developer-portal)

[Changelog](#changelog)
Expand All @@ -31,16 +33,20 @@ The OpenBank solution is built on Apigee Edge API Management Platform, and featu
- Standing Orders
- Products

**Payment Initiation APIs**
- Single Immediate Payment
- Payment Submission

**Security APIs**
- OAuth
- UserInfo

![enter image description
here](http://openbank.apigee.com/sites/default/files/openbank_architecture.png)

The Account Access API follows the Open Banking ![Account and Transaction API Specification - v1.0.0](https://www.openbanking.org.uk/read-write-apis/account-transaction-api/v1-0-0/)
The Account Access APIs follow the Open Banking [Account and Transaction API Specification - v1.0.0](https://www.openbanking.org.uk/read-write-apis/account-transaction-api/v1-0-0/) and Payment Initiation APIs follow [Payment Initiation API Specification - v1.0.0](https://www.openbanking.org.uk/read-write-apis/payment-initiation-api/v1-0-0/)

It also provides an implementation of ![Open Banking Security Profile v1.0.0](https://www.google.com/url?q=https%3A%2F%2Fopenbanking.atlassian.net%2Fwiki%2Fspaces%2FWOR%2Fpages%2F4297946%2F1.%2BOpen%2BBanking%2BSecurity%2BProfile%2B-%2Bv1.0.0&sa=D&sntz=1&usg=AFQjCNGeP_lI2auSpn6nZi9csdk5Fnidhw). It is **OpenID** and **oAuth** based authentication, having **consent** and **two-factor authentication** using phone number and PIN based authentication using external SMS API.
It also provides an implementation of [Open Banking Security Profile v1.0.0](https://www.openbanking.org.uk/read-write-apis/security-profile/id1-0-1/). It is **OpenID** and **oAuth** based authentication, having **consent** and **two-factor authentication** using phone number and PIN based authentication using external SMS API.

### Repository Overview

Expand All @@ -51,8 +57,8 @@ with a **Developer Portal**, dummy backend and a sample app.

## Design

The APIs provided are configurable to connect to one's own Core Banking systems and
for the use of ones own applications to manage end user consent. The following sections will help you
The APIs provided are configurable to connect to your Core Banking systems and
for the use of developer applications, and to obtain end user consent. The following sections will help you
understand this solution so that you can go about this on your own.


Expand All @@ -66,17 +72,18 @@ As shown in the architecture diagram above, the message flow is as follows:
End user Application <-> _Northbound APIs_ <-> _Southbound APIs_ <-> Backend Systems (Core Banking / Payment etc)


The Northbound API provides a fixed set of interfaces that can be used by
The Northbound API provides a fixed set of interfaces, complying with respective Open Banking specification, that can be used by
the external consumers. In order to minimize changes to the contract, and there by to applications that connect to it, this API may not be required to change as often.

The Southbound API connects to the actual backend of the bank. We have used a dummy

The Southbound API connects to the actual backend of the bank. We have used a Sandbox
backend as a default as part of this solution build out. Therefore you may want to modify the southbound interfaces to suite your specific backend needs.

All **Southbound APIs** end with the suffix _'-connector'_

In addition, there are some internal APIs which are not exposed outside, but
which are used internally from the other APIs and provide common services such as
sending out SMS, storing and fetching session data etc.
which are used internally from the other APIs and provide common services like
sending out SMS.


Each API deployed in Apigee Edge is encapsulated withing a unit of deployment called a [Proxy](http://docs.apigee.com/api-services/content/understanding-apis-and-api-proxies).
Expand All @@ -85,11 +92,11 @@ http://docs.apigee.com/api-services/content/what-apigee-edge

Each of the following entities in the sequence diagram below, such as oAuth, consent-app , session,authentication-connector are examples of proxies.

There are two broad sets of proxy defenitions in the solution. One set, **Security**, helps manage the security around the APIs while the other is the set of **Functional APIs** that a bank would like to expose. For example: accounts, payments, branch locations etc.
There are two broad sets of proxy definitions in the solution. One set, **Security**, helps manage the security around the APIs while the other is the set of **Functional APIs** that a bank would like to expose. For example: accounts, payments, etc.


### Security
In this solution, access to all APIs are protected via a security mechanism, that requires explicit end user authentication and authorization to make a successful API call. We have broadly used the OAuth 2.0 framework to secure these APIs, with integrated consent management application to manage end user authorization. Therefore, one has to obtain a valid **Access Token** or a one time Token via the Security APIs before making an call to the Functional APIs.
In this solution, access to all APIs are protected via a security mechanism, that requires explicit end user authentication and authorization to make a successful API call. We have broadly used the OAuth 2.0 framework to secure these APIs, with integrated consent management application to manage end user authorization. Therefore, one has to obtain a valid **Access Token** or a one time Token via the Security APIs before making a call to the Functional APIs.
In order to enable **two-factor authentication** for the functional APIs, OTP(one time password) mechanism via SMS has been enabled for each of the APIs, which can be disabled on demand. The sequence diagram below gives an overview on the call flow between various security related proxies to fetch a valid Access Token with two-factor authentication enabled.
#### OAuth API Flow

Expand All @@ -98,34 +105,47 @@ Interaction](./images/oauth-consent-flow.png)

#### Login App

The login app provides a basic user authentication funcationality. The banks might want to replace it with their corporate login app
The Login app provides a basic user authentication functionality. It uses User Management API to verify the user credentials. The User Management APIs connect to a Sandbox user store. The banks might want to replace the Login App with their corporate login page

#### Consent App

The consent app plays a key role in helping the user securely authenticate with the bank. The consent app is a trusted app of the bank which will allow the user to login and subsequently provide consent information.
The consent app uses login app for the user securely authenticate with the bank. The consent app is a trusted app of the bank which will allow the user to login and subsequently provide consent information.

The consent app will talk to the following APIs in order to
fulfill its functionality : Session API, SMS API, Accounts-connector API, Authentication-connector API.
fulfill its functionality : Consent API, SMS API, Accounts-connector API, Payment-connector API, Authentication-connector API and Customer Management API.
For more details on each of these APIs, refer to the README.md of the respective proxy which exposes these APIs.

### Functional APIs

The Functional APIs deployed and available as part of OpenBank solution are broadly classified as follow:

#### **1. Accounts Information APIS**
Account information APIs provide information for a single account held by the consumer. Information is categorized into:
#### **1. Accounts Information APIs**
Account Information APIs provide account information for accounts held by the consumer. Information is categorized into:

- Request (for Account Information)
- Information
- Balance
- Transactions
- Transactions
- Direct debits
- Standing Orders
- Products

An API end point is provided for each type of information.
These Account Information APIs are secured with **oAuth 2.0** and need a **valid Access token** for making API calls.
Banking APIs provide developers with the information needed to create innovative fintech apps for consumers.There are a few obvious use cases worth mentioning:
These Account Information APIs are secured with **oAuth 2.0** and need a **valid Access token** for making API calls.


- Aggregation of financial metrics such as net worth and savings across multiple accounts.
- Analysis and recommendations for better money management.
- Reccomendation of products and deals based on monthly statements.
- Recommendation of products and deals based on monthly statements.

#### **2. Payment Initiation APIs**
Payment Initiation APIs provide a simple one time payment functionality. It has two sets of APIs:
- Payment request - (CREATE, GET and DELETE) to request for a one time payment
- Payment submission - (CREATE, GET) to submit payment request for actual payment.

The Payment Initiation APIs are also secured with **oAuth 2.0** and need a **valid Access token**.

Banking APIs provide developers with the information needed to create innovative Fintech apps for consumers.There are a few obvious use cases worth mentioning:


## Apigee Edge Setup
Expand All @@ -134,7 +154,7 @@ Banking APIs provide developers with the information needed to create innovative

+ Create an [Apigee API Management Developer Account](https://enterprise.apigee.com)
+ Create an [Apigee BaaS Account](https://apibaas.apigee.com)
+ Request For [Apigee Developer Portal](https://goo.gl/j8Vbew)
+ Request For [Apigee Developer Portal](https://goo.gl/j8Vbew), if you want to use portal

To Learn more on the basic concepts of Apigee Edge, please refer to :
http://docs.apigee.com/api-services/content/what-apigee-edge
Expand Down Expand Up @@ -180,9 +200,7 @@ This will interactively prompt you for following details, and will then create /
+ Login App Key for signing the user details




#### Test
### Test

Once the deploy script is complete, run the following command to do a basic sanity test that the APIs are working

Expand All @@ -201,11 +219,19 @@ run tests
gulp test
```

### Developer Portal

Developer Portal setup is detailed in separate [document](./src/devportal/README.md)

## Changelog

#### 2017/09/13
* APIs / API Spec
* Payment Initiation APIs added

#### 2017/08/24
* APIs / API Spec
* APIs are made compliant with OpenBanking v1.0.0
* Account APIs are made compliant with OpenBanking v1.0.0
* Support for Open Bank Security Profile v1.0.0 - hybrid flow


Expand Down

0 comments on commit c8c8bb1

Please sign in to comment.