As [Chris Michael](https://www.linkedin.com/in/cjemichael/) stated in his recent blog, Open Banking is going to be [awesome](https://www.linkedin.com/pulse/open-banking-awesome-chris-michael?articleId=6449732898202406912#comments-6449732898202406912&trk=prof-post) and as promised, we want to help the ecosystem by Open Sourcing the payment App we created during [ForgeRock](https://www.forgerock.com/) hackathon. Read the blog until the end to find the link to the code…

Imagine the ability of making a mobile payment [app](https://medium.com/yapily/building-a-payment-app-that-connects-to-open-banking-in-a-weekend-open-source-f24448d05488), that gives the user the ability to use his bank account in no time. And all of that just by asking the user’s permission to do so. No user credentials persistence, no need for backend infrastructure, no need to come up with a hacky approach. Just straight interaction between the user and the bank with a little help from Yapily.

It all starts with registering to the Yapily [dashboard](https://dashboard.yapily.com/register), creating your application and choosing the financial institutions that you want your user to interact with.

![head 1](//images.ctfassets.net/3ndxs7efitel/ize65LZOKexcsmGveLPKq/85aa835cf4a3dc0047d2a2d4b866322f/head_1.png)
![head 2](//images.ctfassets.net/3ndxs7efitel/GJLkNPrJQ6ZlmoBBrIhKg/da1db44c21f66c73932f67e14ed335c4/head_2.png)
![head 3](//images.ctfassets.net/3ndxs7efitel/1LZDgVGyFspMV8zZLVBse3/dd297d6444a711917f4a6caebf7017e4/head_3.png)

Once you are done, you will receive your Yapily credentials and you are ready to interact with the Yapily [API](https://docs.yapily.com/).

## Generating the SDK

Obviously based on your stack in order to interact with an API you need to implement each call using the programming language of your choice. That’s way too much effort, shouldn’t it be easier?

Of course it should be easier, that’s why we provide our API’s [Swagger](https://api.yapily.com/docs/swagger.json) specification. By providing our API’s Swagger specification you can generate the Yapily SDK with the language of you choice.

Cross platform application’s rock, thus [Flutter](https://flutter.io/) is a no brainer when it comes to mobile applications.

So let’s generate our SDK using the Swagger [codegen](https://swagger.io/tools/swagger-codegen/) tool.

    java -jar swagger-codegen-cli-2.3.0.jar generate -i  https://api.yapily.com/docs/swagger.json -l dart

## Configuring the Yapily SDK to your Flutter app

Now if you generate your own SDK it is up to you on how to distribute it and use it. For the [Dart](https://www.dartlang.org/) SDK we already did this for you by hosting it to our [github](https://github.com/yapily) profile, so no need to do anything whatsoever.

Supposing you already have a Flutter application up running all you need is to just include the Yapily SDK dependency at the pubspec.yaml file.
 
    dependencies:
      flutter:    
    sdk: flutter  
      yapily_sdk:    
    git:    
      url: git@github.com:yapily/yapily-sdk-dart.git    
      flutter_webview_plugin: '0.2.1+2'
  
## Use your Yapily application’s credentials
Now let’s put our Yapily credentials to our app. For the sake of this blog’s simplicity we are going to place them at the asset folder. Always be careful on how you distribute your credentials.

We will create a yapily-assets folder which shall contain the yapily-config.json file containing the the credentials of our Yapily app and some other configuration.

    {
     "key":"<your api key>",  
     "secret":"<your api secret>",  
     "userName": "moneyme_user",  
     "callback": "moneyme://whatever/"  
    }

Then specify the the yapily-assets folder in the assets section of the pubspec.yaml file.

    assets:  
    - graphics/  
    - yapily-assets/
    
Before proceeding to our application code we need to add a retrieval method for the Yapily config.

    import 'dart:convert' show json;  
    import 'dart:async';  
    import 'package:flutter/services.dart' show rootBundle;  
    
    class ConfigLoader {  
    
    static Future<YapilyConfig> loadAsync() {  
    return rootBundle.loadStructuredData<YapilyConfig>("yapily-assets/yapily-config.json",  
    (jsonStr) async {  
      final yapilyConfig = YapilyConfig.fromJson(json.decode(jsonStr));  
      return yapilyConfig;  
    });  
      }  
    }  
    
    class YapilyConfig {  
    
      final String key;  
      final String secret;  
      final String userName;  
      final String callback;  
      final String basePath;  
      
    YapilyConfig({this.key = "", this.secret = "", this.userName = "",   this.callback = "", this.basePath = ""});  
    
    factory YapilyConfig.fromJson(Map<String,dynamic> jsonMap) {  
    return new YapilyConfig(key: jsonMap["key"], secret: jsonMap["secret"],   userName: jsonMap["userName"], callback: jsonMap["callback"]);  
      }  
    } 

And that’s it! Now we are ready to add some open banking functionality backed by the Yapily SDK.

## Set up the Yapily client

First things first, let’s make a factory for our Yapily ApiClient

    import 'dart:async';  
    import 'yapily_config.dart';  
    import 'package:yapily_sdk/api.dart';  
    class ApiClientFactory {  
    static Future<ApiClient> create() {  
    return ConfigLoader.loadAsync().then( (yapilyConfig) {  
      var httpBasicAuth = HttpBasicAuth.setCredentials(username:   yapilyConfig.key, password: yapilyConfig.secret);  
      var apiClient = ApiClient.withAuth(httpBasicAuth);  
      return apiClient;  
    });  
      }  
    }

This factory will create a client eligible to issue requests upon the Yapily SDK.

Let’s create a Yapily user first. Our application’s config contains a username, so we are going to create a Yapily user and add a reference to that username.

In case the user already exists then we can just get his userUuid, which is needed to interact with the Yapily API.

    var apiClientFactory = ApiClientFactory.create();  
    apiClientFactory.then((apiClient) {  
      ApplicationUsersApi yapilyUsersApi = new ApplicationUsersApi(apiClient);  
      yapilyUsersApi.getUsersUsingGET().then((userList) {  
    userList.asMap().forEach((key, user) {  
      if (user.referenceId == yapilyConfig.userName) {  
    userUuid = user.uuid;  
      }  
    });  
    if (userUuid == null) {  
      //No user exists with this username  
      NewApplicationUser applicationUser = __new__ NewApplicationUser();  
      applicationUser.referenceId = yapilyConfig.userName;  
      yapilyUsersApi.addUserUsingPOST(applicationUser).then((yapilyUser) {  
    userUuid = yapilyUser.uuid;  
      });  
    }  
      });  
    });
    
## Get the user’s consent for a payment

Wouldn’t it be great if the user could just give his consent only for one payment and everything else like payment execution or payment completion being taken care of behind the scenes? That is what is so great with Open Banking and Yapily, they make things so simple.

We will ask the user to give his permission for a certain payment.

    var sortCodePaymentRequest = new SortCodePaymentRequest();  
    sortCodePaymentRequest.paymentReferenceId = new   Uuid().v4().toString().replaceAll("-", "");  
    sortCodePaymentRequest.senderAccountId = "9bd5ae68-2266-4dad-865b-4980550a72b7";  
    sortCodePaymentRequest.accountNumber = paymentData.accountNumber;  
    sortCodePaymentRequest.sortCode = paymentData.sortCode;  
    sortCodePaymentRequest.country = "GB";  
    sortCodePaymentRequest.currency = paymentData.currency;  
    sortCodePaymentRequest.name = paymentData.name;  
    sortCodePaymentRequest.reference = "moneyme payment";  
    .  
    .  
    .  
    var apiClientFactory = ApiClientFactory.create();  
      return apiClientFactory.then( (apiClient) {  
    return new   PaymentsApi(apiClient).createPaymentInitiationUsingPOST(id,paymentRequest:
    sortCodePaymentRequest, userUuid: userUuid, callback: callback);  
      }).then((apiResponse) {  
    //Open apiResponse.data.authUrl in a browser  
    });  

This will redirect the user to the institution of his choice in order to give consent for the payment.

![head 4](//images.ctfassets.net/3ndxs7efitel/5hE2V2mNJgDzvGc31JR0F9/4deb758649cb593588d0e35813aea48f/head_4.jpeg)
![head 5](//images.ctfassets.net/3ndxs7efitel/2iRxBl3nsAId7GsW1wcsuy/fbf9a46fe0575b06fb145cbe6601b42f/head_5.jpeg)
![head 6](//images.ctfassets.net/3ndxs7efitel/1MhXAkah6GzfKPRh1NkQTg/d0be0aed9a6811ec51e80d3f47acd945/head_6.jpeg)
*The user selects the bank and gives the consent for the payment*

## Execute the payment

What we just did is a crucial step that needs to be done before executing a payment request. First the user has to give his consent to you to execute a payment and then you can execute that payment using this consent. Eventually you shall be able to retrieve the user’s consent from the url passed back and thus executing the payment would be a walk in the park.

    var consentLookupString = 'consent=';  
    var consent = url.substring(  
    url.indexOf(consentLookupString) + consentLookupString.__length__, url.length);  
    var apiClientFactory = ApiClientFactory.create();  
    return apiClientFactory.then( (apiClient) {  
      return new PaymentsApi(apiClient).createPaymentUsingPOST(consent,   paymentRequest: sortCodePaymentRequest);  
    });

## Conclusion

You made it ! You just executed your first payment using Yapily and Open Banking. Back in the past you had to make the user to give his credentials, take full responsibility of them and ScreenScrap your way through it. Well not anymore! Who could imagine it could be so easy?

And as promised, you can find the source code on [github](https://github.com/yapily/yapily-demo-pisp-flutter).



Get a head start on building open banking applications using Flutter and Yapily

[Yapily](https://www.yapily.com/) developers participated to (and runner-ed? up) the [ForgeRock Hackathon](https://www.forgerock.com/about-us/press-releases/forgerock-hosts-its-first-ever-hackathon-dedicated-open-banking-ecosystem) last weekend! It was a great event and our congrats to the winning team, [IT Smart Systems](http://www.itsmartsystems.eu/), for their impressive payment request app. What both companies demonstrated is how fun and easy it will be to innovate in fintech with Open Banking going forward. Here, I’ll walk you through how in just 2 days we were able to demo a production quality app.

We knew we wanted to make a payment app that worked with [QR codes](https://en.wikipedia.org/wiki/QR_code). A couple of the scenarios that we imagined were:
1. QR codes for static payment requests (e.g. charity donations) to remove the need for typing in credit card details
2. Generating QR codes on your mobile device so you can chase debts immediately from your friends

Keeping in mind that QR codes are more secure than typing credit card details, the name of the game for us was __speed__. And thanks to our selection of tools, we achieved quite a lot in a short amount of time. Those tools that we would like to thank (in no particular order) are:

- [Flutter](https://flutter.io/) — a mobile development framework for building Android and iOS compatible apps
- [Firebase](https://firebase.google.com/) — a Google tool that provides backend functionality for web and mobile applications. We used this to handle image uploads but it offers a lot more
- [Yapily](https://www.yapily.com/) (of course) — our API that we used to obtain the login URL and authorise the payment for the [ForgeRock](https://www.forgerock.com/) test bank
- [ForgeRock sandbox](https://directory.ob.forgerock.financial/dashboard) — [ForgeRock](https://www.forgerock.com/) provided the mock bank for us to simulate user authentication, third party app authorisation and payments
- [Open Banking directory](https://directory.openbanking.org.uk/) — this is where entities must register in order to be able to connect to Open Banking APIs. It’s also worth noting that ForgeRock provides a testing directory as an alternative.

## MONEY ME — The app that makes payment requests easy

![building](//images.ctfassets.net/3ndxs7efitel/vkQkCdTsEU6RS1iY5XsMo/ff4bff4ec52485a3523bfb2627310a15/building.jpeg) ![building 3](//images.ctfassets.net/3ndxs7efitel/510mNbwTNgL4G0GPVIevqw/4b4d10dd9dd575d03a6a57949cfd88fc/building_3.jpeg) ![building 2](//images.ctfassets.net/3ndxs7efitel/3qki15rqtS6JrDMYFmqMN0/61296f552ba775643dbf4f72a155fd71/building_2.jpeg)
![building 4](//images.ctfassets.net/3ndxs7efitel/1Jo5ZbpmW51TCkdnflS0hj/637b26e43be03aff2bfbab5411fe62e1/building_4.jpeg) ![building 5](//images.ctfassets.net/3ndxs7efitel/69KchUGNaW1UVtHrXmvlhm/7feec632cd5c6768328afda1bd1310cf/building_5.jpeg)![building 6](//images.ctfassets.net/3ndxs7efitel/t5w1SepM354ARbmoPPYyw/122e0030b6aa934f694872b54f54ad31/building_6.jpeg) 
*The user selects his/her institution of choice and is directed to the bank website to authorise our payment app to execute this payment*

## Making the connection to ForgeRock.. and a bunch of other banks!
This part of the hack was done by creating an application in the [Yapily Dashboard.](https://dashboard.yapily.com/)

![building 7](//images.ctfassets.net/3ndxs7efitel/l6Ht6vQNAKzOk8sHlNKow/bcace85d4470e130333f87dd35772734/building_7.png)

Our application SSA (software statement assertion) registered in the [Open Banking directory](https://directory.openbanking.org.uk/) was used to sign our requests and create the authorisation url for the end user. And to leverage the power of our [Swagger](https://swagger.io/) documentation for the [Yapily API](https://api.yapily.com/docs/swagger.json), we generated a [Dart SDK](https://github.com/yapily/yapily-sdk-dart) to work with our Flutter app.

Details of our technical implementation to follow in another post ([here’s the code for now](https://github.com/yapily/yapily-demo-pisp-flutter)).

## However…

Making this connection was likely the most challenging aspect of connecting to the __ForgeRock sandbox bank__, largely due to the requirements of understanding the [Open Banking specification](https://openbanking.atlassian.net/wiki), generating the necessary signing and transport certificates, sharing and obtaining the relevant keys, knowing how to use the SSA’s and configuring your API client and the rest of your code to make properly-authorised requests.

Kudos to the teams that managed to get connected in that short time and the hackathon mentors for guiding the teams through the process.

## Connecting via Yapily

Each TPP ([third party provider](https://www.openbanking.org.uk/about-us/glossary/), aka the app connecting to the bank), even [connecting using Yapily](https://docs.yapily.com/), will still need to be registered in the [Open Banking directory](https://directory.openbanking.org.uk/). A key difference is that the usage of certificates, SSAs and the subsequent signing of API requests are handled by the [Yapily API](https://www.yapily.com/).

In our experience during the hackathon, even for a small prototype/hackathon project, some benefits became clear:

1. Quicker integrations to bank APIs
2. An app that is ready to connect to __multiple banks__

In a real application we would have seen even more benefits, including reducing the number of APIs to manage, response normalisation, various token management features, centralised analytics and monitoring.

## To conclude

It was a fun experience to use [Flutter](https://flutter.io/) to quickly build a nice clean mobile app; it was also great to use [Firebase](https://firebase.google.com/) for backend functionality without having to write code for a single controller, even if we didn’t get to play with the database; but the easiest part was connecting our mobile app to ForgeRock using our very own [Yapily API](https://www.yapily.com/)!



---



*Innovating in fintech just became so much easier! So what’s your idea? Get in touch at hello@yapily.com, we would love to help!*


---



And finally thanks to the rest of the Yapily team and the judges:

- [Will Beeson](https://www.linkedin.com/in/willbeeson/)
- [Chris Michael](https://www.linkedin.com/in/cjemichael/)
- [Megan Caywood](https://www.linkedin.com/in/megcaywood/)

the [ForgeRock](https://www.forgerock.com/) team:  

- Allan Foster
- Agnes Blach-Barth
- Hollie Dabson
- Ranjana Sharma
- Nick Caley
- Ben Jefferies
- Jamie Bowen
- Steve Ferris
- Fraser Wallace
- Quentin
- Wayne Blacklock
- Maxime Salnikov

volunteers:

- Julian Coombes
- Glyn Jackson

the [Raidiam](https://www.raidiam.com/) team:

- Barry O’Donohoe
- Ralph Bragg
- John Heaton-Armstrong
- Mark Haine

Disclaimer: This post is about a hackathon project. Any names used in this project, including Money Me, are in no way affiliated with any brand bearing the same or a similar name.

Building a payment app that connects to Open Banking in a weekend (open source)

However, we at Yapily are a curious bunch! 🤓 We are passionate problem solvers and focus on __How__ and __Why__ of the Open Banking. We believe

> Simplicity is the ultimate sophistication

and we are here to answer some of those nagging questions in simple words. So without much adieu, let us get started with Open Banking basics and what we do with simple questions and answers!

## So, What is Open Banking? English, please.
Open Banking is an initiative led by the UK Competition and Market Authority to push the 9 UK biggest banks to comply with the UK implementation of the Payment Service Directive 2. The directive is a consumer-focused regulatory change designed to open up competition in the European retail banking space (not just the UK!). Basically to make financial services __better__ 📈 and __cheaper__ 💸 for everyone. It will benefit everyone with a bank account (like me and you, who use bank accounts on a daily basis and small business owners who have current accounts with banks). The regulators in each of the 🇪🇺 European countries are asked to [make banks work harder for people](https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/544942/overview-of-the-banking-retail-market.pdf). Nowadays how, however, term Open Banking is used globally to refer to Open API in the banking space and this creates a bit of confusion…

## What do you mean by “making Banks work harder for people”?
By that we mean, banks 🏦 are asked to open up their channels to other players (who are called Third Party Providers — TPPs) and share customers data when requested.

## I mean, why should banks do that? Isn’t it bad for their business?
Because it is NOT banks data that is being requested, __*data rightfully*__ belongs to the customer and they have rights to share it with other providers at their discretion, in a secure & easy way. 🔐

## So, How can individual customers benefit from this open banking and bank data sharing?
The main benefit is that customers like you and me have more control over our bank data (not just one bank, but all our bank accounts!). We can now provide easy access to;

1. 💰Our favourite app that does budgeting for us,
2. ✔️Quickly verify our affordability for a mortgage with the lender, and
3. 🔎 Verify our identity using bank accounts, and much much more!

Also, most importantly __we now will know who has access to our data__, what is the access level (only accounts/ only payments/ duration of access) and ability to easily allow/ deny access to our banks. Want to know more, visit [www.openbanking.co.uk](http://www.openbanking.co.uk/) to see some of the regulated providers

## All sounds great! Now, how do various financial providers access this data?
This is where regulators have oversight over these financial providers and there are few regulatory and security measures to respect. For the 9 biggest UK banks, once that is done, the providers will have to be recognised by [Open Banking Implementation Entity (OBIE)](http://www.openbanking.co.uk/) in the UK 🇬🇧 as authorised TPPs.

Now, TPPs can get their users permission online and then banks and TPPs can share their users' data via secure digital communication channels called Application Programming Interfaces, in short — APIs. ⚙️

## What is this API? I’m lost again! 🧐

Simplistically, APIs are the machine to machine communication channels to access users data present in banks by these TPPs. Just like we are now reading this post in English, Imagine “ Mr Bank” as a person talking to another person “ Mr Financial Service Providers” in English over a radio. Just think this radio as API! When it comes to APIs, there are a set of agreed protocols and methodologies to be followed to successfully to get the communication, think of it like military communications with the set of instructions for the repeated set of actions!

## How to use the API technology to enable the benefits of open banking to end customers?
As mandated by the regulators, Banks needs to provide their own set of APIs to access and modify users data 📒 like account profile information, balances, transactions and also initiate payments 💳 on their behalf. Before banks provide access to data, very rightly so, the user needs to provide permission🔏 from their choice of Third Party Providers which is called access & consent token when it comes to computer communications.

## Very well, then what is the problem?
Each bank has a slightly different approach. For example, the way service provider signs up to them, to their users' authorisation flow to customer support and availability of banking systems to access this data. For this, service providers need to have the backend infrastructure setup and establish connectivity with each of the banks which would obviously take a lot of time, resources and money in setting up but also maintaining these connectivities. It is also worth noting that just in the UK, there are more than 300 banks and in Europe almost 5000!! 👀

Imagine setting up and maintaining connectivity with each of those banks to cater to your users.

## That to me sounds like a scalability and maintainability problem! What have you built to make things easier and enable open banking for financial providers?
You are absolutely right!🎯 We have focused on lifting this heavyweight backend infrastructure work while innovative fintech service providers can focus on their users and making banking better for them. Over the past few months, we have closely studied and witnessed the maturity of the 🇪🇺European Open Banking ecosystem as an insider to build a robust connectivity ecosystem to connect to banks. What we have built is an easy to use plug & play solution 🔌

## What do you mean by robust connectivity ecosystem and how does it help service providers?
We have built a single interface through which service providers can connect to banks via the API. Using our platform, service providers can easily create, configure and maintain all their bank connections. Instead of creating dedicated teams, spending upfront time and struggling to keep up with banks changes and downtime, service providers can easily integrate with us in few minutes and plug into all banks.🏦We enable companies to innovate and focus on their product, while we take care of the connectivity.

## So do you cater to all service providers?
We focus on the regulated service provider and we ensure they are authorised to access users data or make payments. We would never sit between our clients and their customers.

## After connecting, what can they do?
Once providers connect using our system, we have made it simple for service providers to manage their users' consent to access bank data from multiple banks.

After authorisation, service providers can receive data such as users accounts, account identity information, account transaction or make payments on their behalf.

## How is the data received any different from bank data?
Our API receives real-time raw data aggregated from various banks and normalises the user data so that it is cleaned and ready-to-use in service providers application.

## What about the security of customers data? 🔑
We put utmost importance on data security and especially when it comes to sensitive banking data. Hence, we don’t store/access user credentials and don’t store/access users data. Also when it comes to security, we have dedicated experts working on our infrastructure security and we are 🛡ISO 27001🛡 certified. We take data security very seriously!

## Who is your user? 👤 & What is the product you have built?
We focus on making the work of our client development teams easier and productive.

At the core, we offer development teams of service providers, a single powerful and RESTful Yapily API to connect to bank APIs. To manage connectivity, we provide a very easy to use app dashboard which helps connect to sandboxes and live banks plus built-in simulator to mimic bank connectivity before launching to production. We also provide very useful toolkits with each catering to specific needs of the developer such as API collection, software development kits, code examples, API docs, swagger and more. Visit [https://github.com/yapily ](https://github.com/yapily)for more info.

## Brilliant! How can my development team access your platform and get started? 🛠️
To get started with any API, developers typically look at API docs. We suggest you do the same. Visit [https://docs.yapily.com/#get-started](https://docs.yapily.com/#get-started) and it takes less than 5 mins to start making API calls. ⏰

## Lastly and more importantly, how many banks have you connected to? 🏦
Thought you’d never ask! We are currently connected to all the biggest banks and building societies in the UK🇬🇧 ([Open Banking entities](https://github.com/yapily/developer-resources/wiki/Open-Banking-UK)) which covers 90+% of the UK bank accounts. And, we offer connectivity to innovative challenger banks🚀 such as Revolut, Monzo, Starling and Tide. Together with UK banks, we have few international Bank APIs in our kitty — check out Nordea, BBVA, BNP, Hellenic & Deutsche Bank. In total, we have 35 banking entities connected, only via API!

We are very happy to have a chat with businesses looking to tap into Open Banking opportunity, learn about the needs and/or have a product demo. Feel free to reach out to us at 💬 [hello@yapily.com](mailto:hello@yapily.com).

We are eager to hear from you! 💙

Team Yapily

[www.yapily.com](https://www.yapily.com)

A Service Provider’s Guide to Open Banking

Learn more about open banking, explore use cases, and stay up-to-date on industry and company news...all in one place

Learn more about open banking, explore use cases, and be the first to hear about industry news and product updates. Free content in accessible formats. 

Payment Products

Data Products

Tools & Services

Industries

Technical Resources

Company

Insights

Yapily blog

Get a head start on building open banking applications using Flutter and Yapily

Building a payment app that connects to Open Banking in a weekend (open source)

A Service Provider’s Guide to Open Banking