Introduction

Welcome to Credrails Developer Documentation, where you get exclusive guides and relevant resources on how to access financial data and connect with financial accounts seamlessly via our secured and easy-to-integrate API.

3528

Credrails offers open banking connectivity to merchants or third parties (users of this API) for their customer's financial accounts domiciled in Deposit-Taking Institutions (DTI) such as banks, mobile money and SACCOs.

The account holders give consent to access their accounts through our API. The consent given is non-transferrable (can only be used by the party given) and immutable (only works for the scope requested).

Consent requested or obtained covers the following (scopes/actions):

  1. Read transactions (bank statements, mobile money and transactions in DTIs.

  2. Read balance (know the actual and available balance in an account.

  3. Make a one-time payment.

  4. Make recurring payments.

When an application, merchant or third-party (TP) is requesting consent, it can be either one of, or a combination of the above. Upon successful consent provision, a unique key will be issued to TP for use in the consented actions.

A TP must ensure the following conditions are satisfied before performing an action on a customer account:

1. Callback URL

The TP must have a URL on their service/website/API that can accept a POST request with request id and some payload.TP can secure this URL using a key that is passed in the URL as URL params: For example https://my-third-party-application.service.com/credrails-response?API-KEY={secure-key-here}Alternatively, TP can ensure that the callback URL is only accessed by Credrail using other strategies like IP whitelisting. The URL will be provided during registration.

2. Registration on our API

A TP must be registered and whitelisted to use our APIs.Once registered, verified and whitelisted. A JWT token must be used in the headers for Authorization and Authentication. The token will be obtained in the /API/{version}/auth/login step and must be set in the HTTP headers like: Authentication: Bearer 3. Obtaining consent
A TP uses their JWT token to get a consent URL which must be embedded in the TP's channel. An iframe can be used to embed the form in a TP website.The "src" attribute would the consent url as the value. The consent URL displays a consent form which shows the scope/access being requested. The customers give consent by entering their bank account credentials and submitting the form.Without this step, the TP cannot perform any action on the customer's account. 4. TP Access token
The TP needs to obtain a key that will use to access the customer's account. The response that has the consent URL also has a TP Access token for subsequent requests. This key will only be available after the consent has been given by the customer. This token is put in the HTTP payload.

A user in our API, the TP with non-expired JWT and third-party access tokens, can perform actions on a customer who consent to them accessing their account.

GETTING STARTED

|EndPoints||
|Environment| BaseUrl|
|Test|https://dev-openbanking.pub.credrails.com|

Welcome to ReadMe! :owlbert:

You're on your way to building an awesome Developer Hub! Here's some of the things you'll want to check out.

πŸ“ Customize your docs

What you're looking at right now is what we call our Guides. Basically, a free-form place to write to your heart's content! And the best part is... you aren't alone! Your users can contribute (with your approval, of course!) using the Suggested Edits feature on every page. It's like GitHub Pull Requests, but for text!

Want to ease your users into it with some fancy marketing pages? You can enable a Landing Page, and write as much HTML as you want to make it look just like your brand.

πŸ’¬ We're here to help!

If you get stuck, shoot us an email or use the Intercom widget on the bottom right of any page.

We're excited you're here! :blue-heart:

This won't be fun to clean up...