Mock sample for your project: Swiss NextGen Banking API-Framework

Integrate with "Swiss NextGen Banking API-Framework" from openbankingproject.ch in no time with Mockoon's ready to use mock sample

Swiss NextGen Banking API-Framework

openbankingproject.ch

Version: 1.3.8_2020-12-14 - Swiss edition 1.3.8.1-CH


Use this API in your project

Speed up your application development by using "Swiss NextGen Banking API-Framework" ready-to-use mock sample. Mocking this API will help you accelerate your development lifecycles and allow you to stop relying on an external API to get the job done. No more API keys to provision, accesses to configure or unplanned downtime, just work.
Enhance your development infrastructure by mocking third party APIs during integrating testing.

Description

Summary
The Swiss NextGen API is based on the NextGenPSD2 Framework Version 1.3.4 of the Berlin Group which offers a modern, open, harmonised and interoperable set of
Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely.
The NextGen Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards
in Europe and, aligned with the goals of the Euro Retail Payments Board,
enables European banking customers to benefit from innovative products and services ('Banking as a Service')
by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data.
The Swiss edtion refines the message formats specific to Switzerland and defines some matching examples.
The possible Approaches are:
Redirect SCA Approach
(Not recommended by obp.ch community) OAuth SCA Approach
(Not recommended by obp.ch community) Decoupled SCA Approach
(Not recommended by obp.ch community) Embedded SCA Approach without SCA method
(Not recommended by obp.ch community) Embedded SCA Approach with only one SCA method available
(Not recommended by obp.ch community) Embedded SCA Approach with Selection of a SCA method
Not every message defined in this API definition is necessary for all approaches.
Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional
Therefore for a particular implementation of a compliant API it is only necessary to support
a certain subset of the methods defined in this API definition.
**Please have a look at the implementation guidelines if you are not sure
which message has to be used for the approach you are going to use.**
Some General Remarks Related to this version of the OpenAPI Specification:
This API definition is based on the Implementation Guidelines of the Berlin Group API.
It is not a replacement in any sense.
The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group API.
This API definition contains the REST-API for requests from the PISP to the ASPSP.
This API definition contains the messages for all different approaches defined in the Implementation Guidelines.
According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md]
"If in is "header" and the name field is "Accept", "Content-Type" or "Authorization", the parameter definition SHALL be ignored."
The element "Accept" will not be defined in this file at any place.
The elements "Content-Type" and "Authorization" are implicitly defined by the OpenApi tags "content" and "security".
There are several predefined types which might occur in payment initiation messages,
but are not used in the standard JSON messages in the Implementation Guidelines.
Therefore they are not used in the corresponding messages in this file either.
We added them for the convenience of the user.
If there is a payment product, which needs these fields, one can easily use the predefined types.
But the ASPSP need not to accept them in general.
**We omit the definition of all standard HTTP header elements (mandatory/optional/conditional)
except they are mentioned in the Implementation Guidelines.**
Therefore the implementer might add these in his own realisation of a comlient API in addition to the elements defined in this file.
General Remarks on Data Types
The Berlin Group definition of UTF-8 strings in context of the API have to support at least the following characters
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
/ - ? : ( ) . , ' +
Space

Other APIs in the same category

Xero Bank Feeds API

The Bank Feeds API is a closed API that is only available to financial institutions that have an established financial services partnership with Xero. If you're an existing financial services partner that wants access, contact your local Partner Manager. If you're a financial institution who wants to provide bank feeds to your business customers, contact us to become a financial services partner.

1Forge Finance APIs

Stock and Forex Data and Realtime Quotes

Tradematic Cloud API

tradematic.com
Overview
Tradematic Cloud is a trading infrastructure for building investment services.
It’s a trading engine + API + ready-made adapters to stock and forex brokers, crypto exchanges, and market data providers.
You can use it as a cloud API, or you can deploy it on your servers.
How to use Tradematic Cloud API
Sign up at tradematic.cloud. After signing up, you will receive your API key.
Authorization
Add the 'X-API-KEY' header with your API key to each request.
Examples of writing code with Tradematic Cloud API
Examples are available at tradematic.cloud.
Swagger (.yaml) File
Swagger (.yaml) file can be found here.

VAT API

vatapi.com
A developer friendly API to help your business achieve VAT compliance

Afterbanks API

afterbanks.com
La estandarización de la conexión con cualquier banco en tiempo real.

Nordigen Account Information Services API

nordigen.com

Reimbursements API

linuxfoundation.org

Accounting

Introduction
The Xero Accounting API is a RESTful web service and uses the OAuth (v1.0a) protocol to authenticate 3rd party applications. The Accounting API exposes accounting and related functions of the main Xero application and can be used for a variety of purposes such as creating transactions like invoices and credit notes, right through to extracting accounting data via our reports endpoint.

Account and Transaction API Specification

openbanking.org.uk
Swagger for Account and Transaction API Specification

GOV.UK Pay API

payments.service.gov.uk
GOV.UK Pay API (This version is no longer maintained. See openapi/publicapi_spec.json for latest API specification)

Xero Assets API

The Assets API exposes fixed asset related functions of the Xero Accounting application and can be used for a variety of purposes such as creating assets, retrieving asset valuations etc.

NOWPayments API

nowpayments.io
NOWPayments is a non-custodial cryptocurrency payment processing platform. Accept payments in a wide range of cryptos and get them instantly converted into a coin of your choice and sent to your wallet. Keeping it simple – no excess.
Sandbox
Before production usage, you can test our API using the Sandbox. Details can be found here
Authentication
To use the NOWPayments API you should do the following:
Sign up at nowpayments.io
Specify your outcome wallet
Generate an API key
Standard e-commerce flow for NOWPayments API:
API - Check API availability with the "GET API status" method. If required, check the list of available payment currencies with the "GET available currencies" method.
UI - Ask a customer to select item/items for purchase to determine the total sum;
UI - Ask a customer to select payment currency
API - Get the minimum payment amount for the selected currency pair (payment currency to your Outcome Wallet currency) with the "GET Minimum payment amount" method;
API - Get the estimate of the total amount in crypto with "GET Estimated price" and check that it is larger than the minimum payment amount from step 4;
API - Call the "POST Create payment" method to create a payment and get the deposit address (in our example, the generated BTC wallet address is returned from this method);
UI - Ask a customer to send the payment to the generated deposit address (in our example, user has to send BTC coins);
UI - A customer sends coins, NOWPayments processes and exchanges them (if required), and settles the payment to your Outcome Wallet (in our example, to your ETH address);
API - You can get the payment status either via our IPN callbacks or manually, using "GET Payment Status" and display it to a customer so that they know when their payment has been processed.
API - you call the list of payments made to your account via the "GET List of payments" method. Additionally, you can see all of this information in your Account on NOWPayments website.
Alternative flow
API - Check API availability with the "GET API status" method. If required, check the list of available payment currencies with the "GET available currencies" method.
UI - Ask a customer to select item/items for purchase to determine the total sum;
UI - Ask a customer to select payment currency
API - Get the minimum payment amount for the selected currency pair (payment currency to your Outcome Wallet currency) with the "GET Minimum payment amount" method;
API - Get the estimate of the total amount in crypto with "GET Estimated price" and check that it is larger than the minimum payment amount from step 4;
API - Call the "POST Create Invoice method to create an invoice. Set "success_url" - parameter so that the user will be redirected to your website after successful payment.
UI - display the invoice url or redirect the user to the generated link.
NOWPayments - the customer completes the payment and is redirected back to your website (only if "success_url" parameter is configured correctly!).
API - You can get the payment status either via our IPN callbacks or manually, using "GET Payment Status" and display it to a customer so that they know when their payment has been processed.
API - you call the list of payments made to your account via the "GET List of payments" method. Additionally, you can see all of this information in your Account on NOWPayments website.
API Documentation
Instant Payments Notifications
IPN (Instant payment notifications, or callbacks) are used to notify you when transaction status is changed.
To use them, you should complete the following steps:
Generate and save the IPN Secret key in Store Settings tab at the Dashboard.
Insert your URL address where you want to get callbacks in createpayment request. The parameter name is ipn\callback\_url. You will receive payment updates (statuses) to this URL address.
You will receive all the parameters at the URL address you specified in (2) by POST request.
The POST request will contain the x-nowpayments-sig parameter in the header.
The body of the request is similiar to a get payment status response body.
Example:
{"paymentid":5077125051,"paymentstatus":"waiting","payaddress":"0xd1cDE08A07cD25adEbEd35c3867a59228C09B606","priceamount":170,"pricecurrency":"usd","payamount":155.38559757,"actuallypaid":0,"paycurrency":"mana","orderid":"2","orderdescription":"Apple Macbook Pro 2019 x 1","purchaseid":"6084744717","createdat":"2021-04-12T14:22:54.942Z","updatedat":"2021-04-12T14:23:06.244Z","outcomeamount":1131.7812095,"outcome_currency":"trx"}
Sort all the parameters from the POST request in alphabetical order.
Convert them to string using
JSON.stringify (params, Object.keys(params).sort()) or the same function.
Sign a string with an IPN-secret key with HMAC and sha-512 key
Compare the signed string from the previous step with the x-nowpayments-sig , which is stored in the header of the callback request.
If these strings are similar it is a success.
Otherwise, contact us on [email protected] to solve the problem.
Example of creating a signed string at Node.JS
const hmac = crypto.createHmac('sha512', notificationsKey);
hmac.update(JSON.stringify(params, Object.keys(params).sort()));
const signature = hmac.digest('hex');
Example of comparing signed strings in PHP
function checkipnrequestisvalid()
{
$error_msg = "Unknown error";
$auth_ok = false;
$request_data = null;
if (isset($SERVER['HTTPXNOWPAYMENTSSIG']) && !empty($SERVER['HTTPXNOWPAYMENTSSIG'])) {
$recivedhmac = $SERVER['HTTPXNOWPAYMENTS_SIG'];
$requestjson = fileget_contents('php://input');
$requestdata = jsondecode($request_json, true);
ksort($request_data);
$sortedrequestjson = jsonencode($requestdata);
if ($requestjson !== false && !empty($requestjson)) {
$hmac = hashhmac("sha512", $sortedrequestjson, trim($this->ipnsecret));
if ($hmac == $recived_hmac) {
$auth_ok = true;
} else {
$error_msg = 'HMAC signature does not match';
}
} else {
$error_msg = 'Error reading POST data';
}
} else {
$error_msg = 'No HMAC signature sent.';
}
}
Recurrent payment notifications
If an error is detected, the payment is flagged and will receive additional recurrent notifications (number of recurrent notifications can be changed in your Store Settings-> Instant Payment Notifications).
If an error is received again during processing of the payment, recurrent notifications will be initiated again.
Example: "Timeout" is set to 1 minute and "Number of recurrent notifications" is set to 3.
Once an error is detected, you will receive 3 notifications at 1 minute intervals.
Several payments for one order
If you want to create several payments for one Order you should do the following:
Create a payment for the full order amount.
Save "purchaseid" which will be in "createpayment" response
Create next payment or payments with this "purchaseid" in "createpayment" request.
Only works for partially_paid payments
It may be useful if you want to give your customers opportunity to pay a full order with several payments, for example, one part in BTC and one part in ETH. Also, if your customer accidentally paid you only part of a full amount, you can automatically ask them to make another payment.
Packages
Please find our out-of-the box packages for easy integration below:
JavaScript package
More coming soon!
Payments