From 7a7960956a94fb58b5f670533645cba029aa833d Mon Sep 17 00:00:00 2001 From: Christian Wick Date: Wed, 23 Jun 2021 13:04:01 +0200 Subject: [PATCH 01/10] Updates to Merchant /pos REST resources Added support for hiding internal REST resources --- docs/.vuepress/config.js | 258 ++++------- .../nav/left/rest/v1/reference/merchant.js | 411 +++++++++--------- docs/.vuepress/nav/left/rest/v1/resources.js | 187 ++++---- docs/.vuepress/plugins/getResource.js | 168 ++++--- docs/.vuepress/styles/index.styl | 2 +- .../theme/components/PageReference.vue | 34 +- .../theme/components/PageResource.vue | 35 +- .../api/guides/introduction/authentication.md | 34 +- .../create.md | 6 +- .../delete.md | 6 +- .../get.md | 6 +- .../rest/v1/merchant.apiKeys/index.md | 13 + .../rest/v1/merchant.apiKeys/list.md | 12 + .../update.md | 6 +- .../reference/rest/v1/merchant.pos/create.md | 6 +- .../reference/rest/v1/merchant.pos/delete.md | 6 +- .../api/reference/rest/v1/merchant.pos/get.md | 4 +- .../reference/rest/v1/merchant.pos/list.md | 6 +- .../reference/rest/v1/merchant.pos/update.md | 6 +- .../reference/rest/v1/merchant.users/index.md | 13 - 20 files changed, 586 insertions(+), 633 deletions(-) rename docs/api/reference/rest/v1/{merchant.users => merchant.apiKeys}/create.md (60%) rename docs/api/reference/rest/v1/{merchant.users => merchant.apiKeys}/delete.md (60%) rename docs/api/reference/rest/v1/{merchant.users => merchant.apiKeys}/get.md (61%) create mode 100644 docs/api/reference/rest/v1/merchant.apiKeys/index.md create mode 100644 docs/api/reference/rest/v1/merchant.apiKeys/list.md rename docs/api/reference/rest/v1/{merchant.users => merchant.apiKeys}/update.md (60%) delete mode 100644 docs/api/reference/rest/v1/merchant.users/index.md diff --git a/docs/.vuepress/config.js b/docs/.vuepress/config.js index 464c1e9..ebd4d6c 100644 --- a/docs/.vuepress/config.js +++ b/docs/.vuepress/config.js @@ -1,8 +1,6 @@ -const { - description -} = require('../../package'); -require("dotenv").config({ - path: ".env.local" +const { description } = require('../../package'); +require('dotenv').config({ + path: '.env.local', }); // require('dotenv').config() const moment = require('moment'); @@ -15,7 +13,6 @@ console.log('Sidebar Guides: ', sidebar.guides()); // console.log('Sidebar: ', sidebar.bar()); module.exports = (ctx) => ({ - chainWebpack: (config) => { config.module .rule('yaml') @@ -26,62 +23,85 @@ module.exports = (ctx) => ({ .use('yaml-loader') .loader('yaml-loader'); }, - head: [ - ['link', { - rel: 'apple-touch-icon', - sizes: '180x180', - href: '/icons/apple-touch-icon.png' - }], - ['link', { - rel: 'icon', - type: 'image/png', - sizes: '32x32', - href: '/icons/favicon-32x32.png' - }], - ['link', { - rel: 'icon', - type: 'image/png', - sizes: '16x16', - href: '/icons/favicon-16x16.png' - }], + [ + 'link', + { + rel: 'apple-touch-icon', + sizes: '180x180', + href: '/icons/apple-touch-icon.png', + }, + ], + [ + 'link', + { + rel: 'icon', + type: 'image/png', + sizes: '32x32', + href: '/icons/favicon-32x32.png', + }, + ], + [ + 'link', + { + rel: 'icon', + type: 'image/png', + sizes: '16x16', + href: '/icons/favicon-16x16.png', + }, + ], // ['link', { // rel: 'manifest', // href: 'icons/site.webmanifest' // }], - ['link', { - rel: 'mask-icon', - href: '/icons/safari-pinned-tab.svg', - color: '#ff4731' - }], - ['link', { - rel: 'shortcut icon', - href: '/icons/favicon.ico' - }], - ['meta', { - name: 'msapplication-TileColor', - content: '#ff4731' - }], - ['meta', { - name: 'msapplication-config', - content: '/icons/browserconfig.xml' - }], - ['meta', { - name: 'theme-color', - content: '#ff4731' - }], - ['meta', { - name: 'viewport', - content: 'width=device-width, initial-scale=1' - }], + [ + 'link', + { + rel: 'mask-icon', + href: '/icons/safari-pinned-tab.svg', + color: '#ff4731', + }, + ], + [ + 'link', + { + rel: 'shortcut icon', + href: '/icons/favicon.ico', + }, + ], + [ + 'meta', + { + name: 'msapplication-TileColor', + content: '#ff4731', + }, + ], + [ + 'meta', + { + name: 'msapplication-config', + content: '/icons/browserconfig.xml', + }, + ], + [ + 'meta', + { + name: 'theme-color', + content: '#ff4731', + }, + ], + [ + 'meta', + { + name: 'viewport', + content: 'width=device-width, initial-scale=1', + }, + ], ], - extend: '@vuepress/theme-default', - // markdown: { // extractHeaders: ['h2', 'h3', 'h4'] // }, - /** * Ref:https://v1.vuepress.vuejs.org/config/#title */ @@ -90,7 +110,6 @@ module.exports = (ctx) => ({ * Ref:https://v1.vuepress.vuejs.org/config/#description */ description: description, - // base: '/docs/', /** * Theme configuration, here is the default theme configuration for VuePress. @@ -114,138 +133,7 @@ module.exports = (ctx) => ({ '/api/guides/': sidebar.guides(), '/': sidebar.support(), }, - // sidebar: { - // '/api/guides/': [{ - // title: 'Guides', // required - // collapsable: false, // optional, defaults to true - // sidebarDepth: 1, // optional, defaults to 1 - // children: [ - // ['/api/guides/', 'Overview'], - // { - // title: 'Quickstarts', // required - // collapsable: false, - // children: [ - // ['/api/guides/quickstarts/node', 'Node.js'], - // ['/api/guides/quickstarts/python', 'Python'], - // ], - // }, - // { - // title: 'Request and Send Payments', // required - // collapsable: false, - // children: [ - // ['/api/guides/payments/request', 'Request Payment'], - // ['/api/guides/payments/send', 'Send Payment'], - // ], - // }, - // ], - // }, ], - // '/api/reference/rest/': [{ - // title: 'REST Reference', // required - // collapsable: false, // optional, defaults to true - // sidebarDepth: 0, // optional, defaults to 1 - // children: [ - // ['/api/reference/rest/v1/', 'Resource Summary'] - // ], - // }, - // { - // title: 'REST Resources', // required - // collapsable: false, // optional, defaults to true - // sidebarDepth: 1, // optional, defaults to 1 - // // children: getApiSidebar(), - // children: [ - // get_sidebar_reference_merchant(), - // get_sidebar_reference_merchant_balance(), - // get_sidebar_reference_merchant_logo(), - // get_sidebar_reference_merchant_payment_request(), - // get_sidebar_reference_merchant_payment_request_outcome(), - // get_sidebar_reference_merchant_payment_send(), - // get_sidebar_reference_merchant_payment_send_outcome(), - // get_sidebar_reference_merchant_pos(), - // get_sidebar_reference_merchant_sales_summary(), - // get_sidebar_reference_merchant_settlement(), - // get_sidebar_reference_merchant_settlement_account(), - // get_sidebar_reference_merchant_settlement_latest(), - // get_sidebar_reference_merchant_settlement_report(), - // get_sidebar_reference_merchant_shortlink(), - // get_sidebar_reference_merchant_ssp_users(), - // get_sidebar_reference_merchant_statusCodes(), - // get_sidebar_reference_merchant_users(), - // get_sidebar_reference_oauth2(), - // get_sidebar_reference_oauth2_auth_code(), - // get_sidebar_reference_oauth2_auth_request(), - // get_sidebar_reference_oauth2_auth_token(), - // get_sidebar_reference_oauth2_error(), - // get_sidebar_reference_oauth2_qrImage(), - // get_sidebar_reference_oauth2_user_info(), - // get_sidebar_reference_users_permissions(), - // get_sidebar_reference_users_permissions_request(), - // get_sidebar_reference_users_permissions_request_outcome(), - // get_sidebar_reference_users_permissions_scope(), - // ], - // }, - // '/api/reference/rest/v1/types', - // // { - // // title: 'Resources', // required - // // collapsable: false, // optional, defaults to true - // // sidebarDepth: 1, // optional, defaults to 1 - // // children: getResourcesSidebar(), - // // }, - // ], - // '/api/support': [{ - // title: 'Support', // required - // collapsable: false, // optional, defaults to true - // sidebarDepth: 0, // optional, defaults to 1 - // children: [ - // // get_sidebar_support(), - // ['/api/support/', 'How to Get Help'], - // [ - // 'https://stackoverflow.com/questions/tagged/settle-api', - // 'Stack Overflow', - // ], - // [ - // 'https://stackoverflow.com/questions/tagged/settle-api', - // 'Issue Tracker', - // ], - // [ - // 'https://stackoverflow.com/questions/tagged/settle-api', - // 'Feature Request', - // ], - // ['/api/release-notes', 'Release Notes'], - // ['/api/terms', 'Terms of Service'], - // ], - // }, ], - // '/discovery': [{ - // title: 'API Discovery Service', // required - // collapsable: false, // optional, defaults to true - // sidebarDepth: 1, // optional, defaults to 1 - // children: [ - // get_sidebar_discovery_home(), - // get_sidebar_discovery_guides(), - // get_sidebar_discovery_reference(), - // ], - // }, ], - // '/': [{ - // title: 'Introduction', // required - // collapsable: false, // optional, defaults to true - // sidebarDepth: 2, // optional, defaults to 1 - // children: getIntroductionSidebar(), - // }, - // { - // title: 'Guides', // required - // collapsable: false, // optional, defaults to true - // sidebarDepth: 2, // optional, defaults to 1 - // children: getGuidesSidebar(), - // }, - // { - // title: 'Tutorials', // required - // collapsable: false, // optional, defaults to true - // sidebarDepth: 0, // optional, defaults to 1 - // children: getImpIntSidebar(), - // }, - // ], - // }, }, - /** * Apply plugins,ref:https://v1.vuepress.vuejs.org/zh/plugin/ */ @@ -324,4 +212,4 @@ module.exports = (ctx) => ({ // Plugins '.vuepress/plugins/getOpenAPI.js', ], -}); \ No newline at end of file +}); diff --git a/docs/.vuepress/nav/left/rest/v1/reference/merchant.js b/docs/.vuepress/nav/left/rest/v1/reference/merchant.js index eebeafe..d0a2e0c 100644 --- a/docs/.vuepress/nav/left/rest/v1/reference/merchant.js +++ b/docs/.vuepress/nav/left/rest/v1/reference/merchant.js @@ -1,250 +1,265 @@ +function merchant_apiKeys() { + return { + title: 'merchant.apiKeys', // required + collapsable: true, + sidebarDepth: 0, + children: [ + ['/api/reference/rest/v1/merchant.apiKeys/', 'Overview'], + ['/api/reference/rest/v1/merchant.apiKeys/create', 'create'], + ['/api/reference/rest/v1/merchant.apiKeys/get', 'get'], + ['/api/reference/rest/v1/merchant.apiKeys/update', 'update'], + ['/api/reference/rest/v1/merchant.apiKeys/delete', 'delete'], + ], + }; +} + function merchant_balance() { - return { - title: 'merchant.balance', // required - collapsable: true, - sidebarDepth: 0, - children: [ - ['/api/reference/rest/v1/merchant.balance/', 'Overview'], - ['/api/reference/rest/v1/merchant.balance/get', 'get'], - ], - }; + return { + title: 'merchant.balance', // required + collapsable: true, + sidebarDepth: 0, + children: [ + ['/api/reference/rest/v1/merchant.balance/', 'Overview'], + ['/api/reference/rest/v1/merchant.balance/get', 'get'], + ], + }; } function merchant_logo() { - return { - title: 'merchant.logo', // required - // path: '/api/reference/rest/v1/merchant.logo.paymentRequest/', - collapsable: true, - sidebarDepth: 0, - children: [ - ['/api/reference/rest/v1/merchant.logo/', 'Overview'], - ['/api/reference/rest/v1/merchant.logo/get', 'get'], - ], - }; + return { + title: 'merchant.logo', // required + // path: '/api/reference/rest/v1/merchant.logo.paymentRequest/', + collapsable: true, + sidebarDepth: 0, + children: [ + ['/api/reference/rest/v1/merchant.logo/', 'Overview'], + ['/api/reference/rest/v1/merchant.logo/get', 'get'], + ], + }; } function merchant_payment_request() { - return { - title: 'merchant.payment.request', // required - // path: '/api/reference/rest/v1/merchant.paymentRequest/', - collapsable: true, - sidebarDepth: 0, - children: [ - ['/api/reference/rest/v1/merchant.payment.request/', 'Overview'], - ['/api/reference/rest/v1/merchant.payment.request/create', 'create'], - ['/api/reference/rest/v1/merchant.payment.request/list', 'list'], - ['/api/reference/rest/v1/merchant.payment.request/update', 'update'], - ['/api/reference/rest/v1/merchant.payment.request/get', 'get'], - // ['/api/reference/rest/v1/merchant.paymentRequest/getOutcome', 'getOutcome'], - ], - }; + return { + title: 'merchant.payment.request', // required + // path: '/api/reference/rest/v1/merchant.paymentRequest/', + collapsable: true, + sidebarDepth: 0, + children: [ + ['/api/reference/rest/v1/merchant.payment.request/', 'Overview'], + ['/api/reference/rest/v1/merchant.payment.request/create', 'create'], + ['/api/reference/rest/v1/merchant.payment.request/list', 'list'], + ['/api/reference/rest/v1/merchant.payment.request/update', 'update'], + ['/api/reference/rest/v1/merchant.payment.request/get', 'get'], + // ['/api/reference/rest/v1/merchant.paymentRequest/getOutcome', 'getOutcome'], + ], + }; } - function merchant_payment_request_outcome() { - return { - title: 'merchant.payment.request.outcome', // required - // path: '/api/reference/rest/v1/merchant.paymentRequest/', - collapsable: true, - sidebarDepth: 0, - children: [ - ['/api/reference/rest/v1/merchant.payment.request.outcome/', 'Overview'], - ['/api/reference/rest/v1/merchant.payment.request.outcome/get', 'get'], - ], - }; + return { + title: 'merchant.payment.request.outcome', // required + // path: '/api/reference/rest/v1/merchant.paymentRequest/', + collapsable: true, + sidebarDepth: 0, + children: [ + ['/api/reference/rest/v1/merchant.payment.request.outcome/', 'Overview'], + ['/api/reference/rest/v1/merchant.payment.request.outcome/get', 'get'], + ], + }; } function merchant_payment_send() { - return { - title: 'merchant.payment.send', // required - // path: '/api/reference/rest/v1/merchant.paymentsend/', - collapsable: true, - sidebarDepth: 0, - children: [ - ['/api/reference/rest/v1/merchant.payment.send/', 'Overview'], - ['/api/reference/rest/v1/merchant.payment.send/create', 'create'], - ], - }; + return { + title: 'merchant.payment.send', // required + // path: '/api/reference/rest/v1/merchant.paymentsend/', + collapsable: true, + sidebarDepth: 0, + children: [ + ['/api/reference/rest/v1/merchant.payment.send/', 'Overview'], + ['/api/reference/rest/v1/merchant.payment.send/create', 'create'], + ], + }; } function merchant_payment_send_outcome() { - return { - title: 'merchant.payment.send.outcome', // required - // path: '/api/reference/rest/v1/merchant.paymentsend/', - collapsable: true, - sidebarDepth: 0, - children: [ - ['/api/reference/rest/v1/merchant.payment.send.outcome/', 'Overview'], - ['/api/reference/rest/v1/merchant.payment.send.outcome/get', 'get'], - ], - }; + return { + title: 'merchant.payment.send.outcome', // required + // path: '/api/reference/rest/v1/merchant.paymentsend/', + collapsable: true, + sidebarDepth: 0, + children: [ + ['/api/reference/rest/v1/merchant.payment.send.outcome/', 'Overview'], + ['/api/reference/rest/v1/merchant.payment.send.outcome/get', 'get'], + ], + }; } function merchant_pos() { - return { - title: 'merchant.pos', // required - collapsable: true, - sidebarDepth: 0, - children: [ - ['/api/reference/rest/v1/merchant.pos/', 'Overview'], - ['/api/reference/rest/v1/merchant.pos/create', 'create'], - ['/api/reference/rest/v1/merchant.pos/list', 'list'], - ['/api/reference/rest/v1/merchant.pos/get', 'get'], - ['/api/reference/rest/v1/merchant.pos/update', 'update'], - ['/api/reference/rest/v1/merchant.pos/delete', 'delete'], - ], - }; + return { + title: 'merchant.pos', // required + collapsable: true, + sidebarDepth: 0, + children: [ + ['/api/reference/rest/v1/merchant.pos/', 'Overview'], + ['/api/reference/rest/v1/merchant.pos/create', 'create'], + ['/api/reference/rest/v1/merchant.pos/list', 'list'], + ['/api/reference/rest/v1/merchant.pos/get', 'get'], + ['/api/reference/rest/v1/merchant.pos/update', 'update'], + ['/api/reference/rest/v1/merchant.pos/delete', 'delete'], + ], + }; } function merchant_profile() { - return { - title: 'merchant.profile', // required - // path: '/api/reference/rest/v1/merchant.paymentRequest/', - collapsable: true, - sidebarDepth: 0, - children: [ - ['/api/reference/rest/v1/merchant.profile/', 'Overview'], - ['/api/reference/rest/v1/merchant.profile/get', 'get'], - ['/api/reference/rest/v1/merchant.profile/lookup', 'lookup'], - ], - } + return { + title: 'merchant.profile', // required + // path: '/api/reference/rest/v1/merchant.paymentRequest/', + collapsable: true, + sidebarDepth: 0, + children: [ + ['/api/reference/rest/v1/merchant.profile/', 'Overview'], + ['/api/reference/rest/v1/merchant.profile/get', 'get'], + ['/api/reference/rest/v1/merchant.profile/lookup', 'lookup'], + ], + }; } function merchant_sales_summary() { - return { - title: 'merchant.sales.summary', // required - collapsable: true, - sidebarDepth: 0, - children: [ - ['/api/reference/rest/v1/merchant.sales.summary/', 'Overview'], - ['/api/reference/rest/v1/merchant.sales.summary/get', 'get'], - ], - }; + return { + title: 'merchant.sales.summary', // required + collapsable: true, + sidebarDepth: 0, + children: [ + ['/api/reference/rest/v1/merchant.sales.summary/', 'Overview'], + ['/api/reference/rest/v1/merchant.sales.summary/get', 'get'], + ], + }; } function merchant_settlement() { - return { - title: 'merchant.settlement', // required - collapsable: true, - sidebarDepth: 0, - children: [ - ['/api/reference/rest/v1/merchant.settlement/', 'Overview'], - ['/api/reference/rest/v1/merchant.settlement/get', 'get'], - ], - }; + return { + title: 'merchant.settlement', // required + collapsable: true, + sidebarDepth: 0, + children: [ + ['/api/reference/rest/v1/merchant.settlement/', 'Overview'], + ['/api/reference/rest/v1/merchant.settlement/get', 'get'], + ], + }; } function merchant_settlement_account() { - return { - title: 'merchant.settlement.account', // required - collapsable: true, - sidebarDepth: 0, - children: [ - ['/api/reference/rest/v1/merchant.settlement.account/', 'Overview'], - ['/api/reference/rest/v1/merchant.settlement.account/get', 'get'], - ['/api/reference/rest/v1/merchant.settlement.account/update', 'update'], - ], - }; + return { + title: 'merchant.settlement.account', // required + collapsable: true, + sidebarDepth: 0, + children: [ + ['/api/reference/rest/v1/merchant.settlement.account/', 'Overview'], + ['/api/reference/rest/v1/merchant.settlement.account/get', 'get'], + ['/api/reference/rest/v1/merchant.settlement.account/update', 'update'], + ], + }; } function merchant_settlement_latest() { - return { - title: 'merchant.settlement.latest', // required - collapsable: true, - sidebarDepth: 0, - children: [ - ['/api/reference/rest/v1/merchant.settlement.latest/', 'Overview'], - ['/api/reference/rest/v1/merchant.settlement.latest/get', 'get'], - ], - }; + return { + title: 'merchant.settlement.latest', // required + collapsable: true, + sidebarDepth: 0, + children: [ + ['/api/reference/rest/v1/merchant.settlement.latest/', 'Overview'], + ['/api/reference/rest/v1/merchant.settlement.latest/get', 'get'], + ], + }; } function merchant_settlement_report() { - return { - title: 'merchant.settlement.report', // required - collapsable: true, - sidebarDepth: 0, - children: [ - ['/api/reference/rest/v1/merchant.settlement.report/', 'Overview'], - ['/api/reference/rest/v1/merchant.settlement.report/get', 'get'], - ], - }; + return { + title: 'merchant.settlement.report', // required + collapsable: true, + sidebarDepth: 0, + children: [ + ['/api/reference/rest/v1/merchant.settlement.report/', 'Overview'], + ['/api/reference/rest/v1/merchant.settlement.report/get', 'get'], + ], + }; } function merchant_shortlink() { - return { - title: 'merchant.shortlink', // required - collapsable: true, - sidebarDepth: 0, - children: [ - ['/api/reference/rest/v1/merchant.shortlink/', 'Overview'], - ['/api/reference/rest/v1/merchant.shortlink/create', 'create'], - ['/api/reference/rest/v1/merchant.shortlink/list', 'list'], - ['/api/reference/rest/v1/merchant.shortlink/get', 'get'], - ['/api/reference/rest/v1/merchant.shortlink/update', 'update'], - ['/api/reference/rest/v1/merchant.shortlink/delete', 'delete'], - ], - }; + return { + title: 'merchant.shortlink', // required + collapsable: true, + sidebarDepth: 0, + children: [ + ['/api/reference/rest/v1/merchant.shortlink/', 'Overview'], + ['/api/reference/rest/v1/merchant.shortlink/create', 'create'], + ['/api/reference/rest/v1/merchant.shortlink/list', 'list'], + ['/api/reference/rest/v1/merchant.shortlink/get', 'get'], + ['/api/reference/rest/v1/merchant.shortlink/update', 'update'], + ['/api/reference/rest/v1/merchant.shortlink/delete', 'delete'], + ], + }; } function merchant_ssp_users() { - return { - title: 'merchant.ssp.users', // required - collapsable: true, - sidebarDepth: 0, - children: [ - ['/api/reference/rest/v1/merchant.ssp.users/', 'Overview'], - ['/api/reference/rest/v1/merchant.ssp.users/create', 'create'], - ['/api/reference/rest/v1/merchant.ssp.users/get', 'get'], - ['/api/reference/rest/v1/merchant.ssp.users/delete', 'delete'], - ], - }; + return { + title: 'merchant.ssp.users', // required + collapsable: true, + sidebarDepth: 0, + children: [ + ['/api/reference/rest/v1/merchant.ssp.users/', 'Overview'], + ['/api/reference/rest/v1/merchant.ssp.users/create', 'create'], + ['/api/reference/rest/v1/merchant.ssp.users/get', 'get'], + ['/api/reference/rest/v1/merchant.ssp.users/delete', 'delete'], + ], + }; } function merchant_statusCodes() { - return { - title: 'merchant.statusCodes', // required - collapsable: true, - sidebarDepth: 0, - children: [ - ['/api/reference/rest/v1/merchant.statusCodes/', 'Overview'], - ['/api/reference/rest/v1/merchant.statusCodes/list', 'list'], - ['/api/reference/rest/v1/merchant.statusCodes/get', 'get'], - ], - }; + return { + title: 'merchant.statusCodes', // required + collapsable: true, + sidebarDepth: 0, + children: [ + ['/api/reference/rest/v1/merchant.statusCodes/', 'Overview'], + ['/api/reference/rest/v1/merchant.statusCodes/list', 'list'], + ['/api/reference/rest/v1/merchant.statusCodes/get', 'get'], + ], + }; } function merchant_users() { - return { - title: 'merchant.users', // required - collapsable: true, - sidebarDepth: 0, - children: [ - ['/api/reference/rest/v1/merchant.users/', 'Overview'], - ['/api/reference/rest/v1/merchant.users/create', 'create'], - ['/api/reference/rest/v1/merchant.users/get', 'get'], - ['/api/reference/rest/v1/merchant.users/update', 'update'], - ['/api/reference/rest/v1/merchant.users/delete', 'delete'], - ], - }; + return { + title: 'merchant.users', // required + collapsable: true, + sidebarDepth: 0, + children: [ + ['/api/reference/rest/v1/merchant.users/', 'Overview'], + ['/api/reference/rest/v1/merchant.users/create', 'create'], + ['/api/reference/rest/v1/merchant.users/get', 'get'], + ['/api/reference/rest/v1/merchant.users/update', 'update'], + ['/api/reference/rest/v1/merchant.users/delete', 'delete'], + ], + }; } module.exports = { - merchant_balance: merchant_balance(), - merchant_logo: merchant_logo(), - merchant_payment_request: merchant_payment_request(), - merchant_payment_request_outcome: merchant_payment_request_outcome(), - merchant_payment_send: merchant_payment_send(), - merchant_payment_send_outcome: merchant_payment_send_outcome(), - merchant_pos: merchant_pos(), - merchant_profile: merchant_profile(), - merchant_sales_summary: merchant_sales_summary(), - merchant_settlement: merchant_settlement(), - merchant_settlement_account: merchant_settlement_account(), - merchant_settlement_latest: merchant_settlement_latest(), - merchant_settlement_report: merchant_settlement_report(), - merchant_shortlink: merchant_shortlink(), - merchant_ssp_users: merchant_ssp_users(), - merchant_statusCodes: merchant_statusCodes(), - merchant_users: merchant_users(), -}; \ No newline at end of file + merchant_apiKeys: merchant_apiKeys(), + merchant_balance: merchant_balance(), + merchant_logo: merchant_logo(), + merchant_payment_request: merchant_payment_request(), + merchant_payment_request_outcome: merchant_payment_request_outcome(), + merchant_payment_send: merchant_payment_send(), + merchant_payment_send_outcome: merchant_payment_send_outcome(), + merchant_pos: merchant_pos(), + merchant_profile: merchant_profile(), + merchant_sales_summary: merchant_sales_summary(), + merchant_settlement: merchant_settlement(), + merchant_settlement_account: merchant_settlement_account(), + merchant_settlement_latest: merchant_settlement_latest(), + merchant_settlement_report: merchant_settlement_report(), + merchant_shortlink: merchant_shortlink(), + merchant_ssp_users: merchant_ssp_users(), + merchant_statusCodes: merchant_statusCodes(), + merchant_users: merchant_users(), +}; diff --git a/docs/.vuepress/nav/left/rest/v1/resources.js b/docs/.vuepress/nav/left/rest/v1/resources.js index 98bcc17..4916b29 100644 --- a/docs/.vuepress/nav/left/rest/v1/resources.js +++ b/docs/.vuepress/nav/left/rest/v1/resources.js @@ -1,122 +1,121 @@ // Import Merchant menus const { - merchant_balance, - merchant_logo, - merchant_payment_request, - merchant_payment_request_outcome, - merchant_payment_send, - merchant_payment_send_outcome, - merchant_pos, - merchant_profile, - merchant_sales_summary, - merchant_settlement, - merchant_settlement_account, - merchant_settlement_latest, - merchant_settlement_report, - merchant_shortlink, - merchant_ssp_users, - merchant_statusCodes, - merchant_users, + merchant_apiKeys, + merchant_balance, + merchant_logo, + merchant_payment_request, + merchant_payment_request_outcome, + merchant_payment_send, + merchant_payment_send_outcome, + merchant_pos, + merchant_profile, + merchant_sales_summary, + merchant_settlement, + merchant_settlement_account, + merchant_settlement_latest, + merchant_settlement_report, + merchant_shortlink, + merchant_ssp_users, + merchant_statusCodes, + // merchant_users, } = require('./reference/merchant.js'); // Import OAuth2 menus const { - // oauth2, - oauth2_auth_code, - oauth2_auth_request, - oauth2_auth_token, - oauth2_error, - oauth2_qrImage, - oauth2_user_info, + // oauth2, + oauth2_auth_code, + oauth2_auth_request, + oauth2_auth_token, + oauth2_error, + oauth2_qrImage, + oauth2_user_info, } = require('./reference/oauth2.js'); // Import Users menus const { - users_permissions, - users_permissions_request, - users_permissions_request_outcome, - users_permissions_scope, + users_permissions, + users_permissions_request, + users_permissions_request_outcome, + users_permissions_scope, } = require('./reference/users.js'); - // Define Merchant Group function merchantGroup() { - return { - title: 'Merchant', // required - collapsable: false, - sidebarDepth: 0, - children: [ - merchant_balance, - merchant_logo, - merchant_payment_request, - merchant_payment_request_outcome, - merchant_payment_send, - merchant_payment_send_outcome, - merchant_pos, - merchant_profile, - merchant_sales_summary, - merchant_settlement, - merchant_settlement_account, - merchant_settlement_latest, - merchant_settlement_report, - merchant_shortlink, - merchant_ssp_users, - merchant_statusCodes, - merchant_users, - ], - initialOpenGroupIndex: -1 - } + return { + title: 'Merchant', // required + collapsable: false, + sidebarDepth: 0, + children: [ + merchant_apiKeys, + merchant_balance, + merchant_logo, + merchant_payment_request, + merchant_payment_request_outcome, + merchant_payment_send, + merchant_payment_send_outcome, + merchant_pos, + merchant_profile, + merchant_sales_summary, + merchant_settlement, + merchant_settlement_account, + merchant_settlement_latest, + merchant_settlement_report, + merchant_shortlink, + // merchant_ssp_users, + merchant_statusCodes, + // merchant_users, + ], + initialOpenGroupIndex: -1, + }; } // Define OAuth2 Group function OAuth2Group() { - return { - title: 'OAuth2', // required - collapsable: false, - sidebarDepth: 0, - children: [ - // oauth2, - oauth2_auth_code, - oauth2_auth_request, - oauth2_auth_token, - oauth2_error, - oauth2_qrImage, - oauth2_user_info, - ], - initialOpenGroupIndex: -1 - } + return { + title: 'OAuth2', // required + collapsable: false, + sidebarDepth: 0, + children: [ + // oauth2, + oauth2_auth_code, + oauth2_auth_request, + oauth2_auth_token, + oauth2_error, + oauth2_qrImage, + oauth2_user_info, + ], + initialOpenGroupIndex: -1, + }; } // Define Permission Request Group function permissionRequestGroup() { - return { - title: 'Permission Requests', // required - collapsable: false, - sidebarDepth: 0, - children: [ - users_permissions, - users_permissions_request, - users_permissions_request_outcome, - users_permissions_scope, - ], - initialOpenGroupIndex: -1 - } + return { + title: 'Permission Requests', // required + collapsable: false, + sidebarDepth: 0, + children: [ + users_permissions, + users_permissions_request, + users_permissions_request_outcome, + users_permissions_scope, + ], + initialOpenGroupIndex: -1, + }; } - // Merge sidebar-groups together const sidebars = [ - // Merchant Group - merchantGroup(), - // OAuth2 Group - OAuth2Group(), - // Users - permissionRequestGroup() -] - + // Merchant Group + merchantGroup(), + // OAuth2 Group + OAuth2Group(), + // Users + permissionRequestGroup(), +]; module.exports = { - title: 'REST Resources', // required - collapsable: false, // optional, defaults to true - children: sidebars, -} \ No newline at end of file + title: 'REST Resources', // required + collapsable: false, // optional, defaults to true + children: sidebars, +}; diff --git a/docs/.vuepress/plugins/getResource.js b/docs/.vuepress/plugins/getResource.js index 5775da9..39677e7 100644 --- a/docs/.vuepress/plugins/getResource.js +++ b/docs/.vuepress/plugins/getResource.js @@ -1,90 +1,84 @@ module.exports = () => ({ - async extendPageData($page) { - const listContent = require('list-github-dir-content'); - const axios = require('axios'); - const _ = require('lodash'); - - const yaml = require('js-yaml'); - - const myToken = process.env.GITHUB_TOKEN; - - let endpoints = []; - let fileNames = []; - let api = { - merchant: null, - oauth2: null, - users: null, - }; - - // let page = $page; - let page = $page; - - const modelDirectoryFiles = await listContent.viaContentsApi({ - user: 'SettleAPI', - repository: 'settle-api-description', - directory: 'reference', - token: myToken, - }); - - _.filter(modelDirectoryFiles, function (r) { - // console.log(r); - - // let fileName = r.split('reference/')[1]; - let fileName = r.split('reference/')[1]; - - fileNames.push(fileName); - }); - - _.filter(fileNames, function (file) { - let apiName = file.split('.')[0]; - // console.log(apiName); - - axios - .get( - 'https://raw.githubusercontent.com/SettleAPI/settle-api-description/main/reference/' + - file - ) - .then(function (bender) { - let bendersBigScore = yaml.load(bender.data, { - encoding: 'utf-8', - }); - - _.filter(bendersBigScore.components.schemas, function (fry) { - - if (fry.properties) { - _.filter(fry.properties, function (props) { - // console.log(props); - if (props.$ref) { - let $ref = props.$ref.split('../models/')[1].split('.')[0]; - props.$ref = $ref; - // console.log($ref); - } - }); - } - - if (fry.required) { - _.filter(fry.required, function (req) { - _.filter(fry.properties, function (prop, amy) { - if (req === amy) { - prop.required = true; - // console.log(amy, prop); - } - }); - }); - } - - }); - - api[apiName] = bendersBigScore; - }) - .catch(function (error) { - // handle error - console.log(error); - }) - .then(function () { - page.reference = api; + async extendPageData($page) { + const listContent = require('list-github-dir-content'); + const axios = require('axios'); + const _ = require('lodash'); + + const yaml = require('js-yaml'); + + const myToken = process.env.GITHUB_TOKEN; + + let endpoints = []; + let fileNames = []; + let api = { + merchant: null, + oauth2: null, + users: null, + }; + + // let page = $page; + let page = $page; + + const modelDirectoryFiles = await listContent.viaContentsApi({ + user: 'SettleAPI', + repository: 'settle-api-description', + directory: 'reference', + token: myToken, + }); + + _.filter(modelDirectoryFiles, function(r) { + // console.log(r); + + // let fileName = r.split('reference/')[1]; + let fileName = r.split('reference/')[1]; + + fileNames.push(fileName); + }); + + _.filter(fileNames, function(file) { + let apiName = file.split('.')[0]; + // console.log(apiName); + + axios + .get('https://raw.githubusercontent.com/SettleAPI/settle-api-description/main/reference/' + file) + .then(function(bender) { + let bendersBigScore = yaml.load(bender.data, { + encoding: 'utf-8', + }); + + _.filter(bendersBigScore.components.schemas, function(fry) { + if (fry.properties) { + _.filter(fry.properties, function(props) { + // console.log(props); + if (props.$ref) { + let $ref = props.$ref.split('../models/')[1].split('.')[0]; + props.$ref = $ref; + // console.log($ref); + } + }); + } + + if (fry.required) { + _.filter(fry.required, function(req) { + _.filter(fry.properties, function(prop, amy) { + if (req === amy) { + prop.required = true; + // console.log(amy, prop); + } }); + }); + } + }); + + api[apiName] = bendersBigScore; + }) + .catch(function(error) { + // handle error + console.log(error); + }) + .then(function() { + page.reference = api; }); - - }, -}); \ No newline at end of file + }); + }, +}); diff --git a/docs/.vuepress/styles/index.styl b/docs/.vuepress/styles/index.styl index d297b7a..40a4c78 100644 --- a/docs/.vuepress/styles/index.styl +++ b/docs/.vuepress/styles/index.styl @@ -178,7 +178,7 @@ table background-color: #E07166; .md-api_reference_request_heading - font-size: 1.65rem; + font-size: 1.55rem; font-weight: 600; line-height: 1.25; // margin-block-start: 3.33em; diff --git a/docs/.vuepress/theme/components/PageReference.vue b/docs/.vuepress/theme/components/PageReference.vue index 17142ee..af5ac9c 100644 --- a/docs/.vuepress/theme/components/PageReference.vue +++ b/docs/.vuepress/theme/components/PageReference.vue @@ -71,7 +71,11 @@
-
+

-
+
@@ -242,6 +246,8 @@ export default { let resourceEntry = { name: resourceName, methods: {}, + deprecated: false, + internal: false, }; _.filter(reference, function (api, name) { @@ -331,9 +337,13 @@ export default { thisMetod.api = thisMetod.operationId.split(".")[0]; // console.log('thisMetod: ', thisMetod.description); - let excerpt = thisMetod.description - .replace(/([.?!])\s*(?=[A-Z])/g, "$1|") - .split("|")[0]; + let excerpt; + + if (thisMetod.description) { + excerpt = thisMetod.description + .replace(/([.?!])\s*(?=[A-Z])/g, "$1|") + .split("|")[0]; + } // console.log(excerpt); thisMetod.excerpt = excerpt; @@ -379,8 +389,20 @@ export default { // resourceData[hmm[0]].methods.push(boy) resourceData[hmm[0]].methods[boy] = bender; - // console.log("bender: ", bender); + console.log( + "resourceData[hmm[0]].methods[boy]: ", + resourceData[hmm[0]].methods[boy] + ); // console.log(resourceData[hmm[0]].methods[boy]); + if (bender.deprecated) { + console.log("deprecated: ", bender.deprecated); + resourceData[hmm[0]].deprecated = true; + } + + if (bender["x-internal"]) { + console.log("x-internal: ", bender["x-internal"]); + resourceData[hmm[0]].internal = true; + } } }); }); diff --git a/docs/.vuepress/theme/components/PageResource.vue b/docs/.vuepress/theme/components/PageResource.vue index 70816ef..adeb702 100644 --- a/docs/.vuepress/theme/components/PageResource.vue +++ b/docs/.vuepress/theme/components/PageResource.vue @@ -40,12 +40,12 @@ Required Auth Level: {{ $frontmatter.authLevel }} {{ $frontmatter.authLevel }} @@ -70,12 +70,13 @@
  • {{ code.code }} --> - {{ code.title }}, {{ code.description }} + + {{ code.title }} + , {{ code.description }}

-

+

# Schema

@@ -139,6 +140,23 @@

{{ type.description }}

+
+ -
+

-

- # Status Codes -

-
    -
  • - {{ code.code }} --> - - {{ code.title }} - , {{ code.description }} -
  • -
- -

- # Schema -

-
-
-

- # - {{ type.name }} +
+

+ # Status Codes

    -
  • - Type: - - - {{ type.$ref }} - - {{ type.type }} -
  • - -
  • - Required: - {{ type.required }} -
  • -
  • - Enum: {{ type.enum }} -
  • -
  • - Default: {{ type.default }} -
  • -
  • - Length: {{ type.minLength }} -
  • -
  • - Length: ≥ {{ type.minLength }} -
  • -
  • - Length: ≤ {{ type.maxLength }} -
  • -
  • - Value: ≥ {{ type.minimum }} -
  • -
  • - Value: ≤ {{ type.maximum }} -
  • -
  • - RegExp: {{ type.pattern }} +
  • + {{ code.code }} --> + {{ code.title }}, {{ code.description }}
-

{{ type.description }}

+
+

+ # Schema +

+
+
+

+ # + {{ type.name }} +

+
    +
  • + Type: + + + {{ type.$ref }} + + {{ type.type }} +
  • + +
  • + Required: + {{ type.required }} +
  • +
  • + Enum: {{ type.enum }} +
  • +
  • + Default: {{ type.default }} +
  • +
  • + Length: {{ type.minLength }} +
  • +
  • + Length: ≥ {{ type.minLength }} +
  • +
  • + Length: ≤ {{ type.maxLength }} +
  • +
  • + Value: ≥ {{ type.minimum }} +
  • +
  • + Value: ≤ {{ type.maximum }} +
  • +
  • + RegExp: {{ type.pattern }} +
  • +
+

{{ type.description }}

+
+
+
+
+

--> + + {{ type.title }} -

+

{{ type.description }}

@@ -112,7 +112,7 @@

{{ property.description }}

-
+

No info available for {{ type.title }} at of this moment. Please @@ -187,7 +187,7 @@ export default { } else if (site.pages[0].models) { data.types = site.pages[0].models; } else { - console.warn('Neither page.models or site.pages[0].models found...'); + console.warn("Neither page.models or site.pages[0].models found..."); } // console.log(data.types); diff --git a/docs/.vuepress/theme/components/PageResource.vue b/docs/.vuepress/theme/components/PageResource.vue index 2807872..0459d09 100644 --- a/docs/.vuepress/theme/components/PageResource.vue +++ b/docs/.vuepress/theme/components/PageResource.vue @@ -48,6 +48,16 @@ :to="'/api/guides/introduction/authentication/#authentication-using-key'" >{{ $frontmatter.authLevel }} + {{ $frontmatter.authLevel }} + + {{ $frontmatter.authLevel }} +

  • Authorized Roles: {{ $frontmatter.authRoles }}
  • @@ -123,6 +133,13 @@ > Length: {{ type.minLength }} +
  • + Length: + ≤ {{ type.minLength }} && ≥ + {{ type.maxLength }} +
  • Length: ≥ {{ type.minLength }}
  • diff --git a/docs/.vuepress/theme/components/PageResourceOverview.vue b/docs/.vuepress/theme/components/PageResourceOverview.vue index b19e839..4598e08 100644 --- a/docs/.vuepress/theme/components/PageResourceOverview.vue +++ b/docs/.vuepress/theme/components/PageResourceOverview.vue @@ -17,9 +17,14 @@ # Resource -

    There is no persistent data associated with this resource.

    -       - +
    + +
    +
    +

    There is no persistent data associated with this resource.

    +
    + +

    # HTTP Requests @@ -52,7 +57,10 @@

    WARNING

    -

    No Methods found for {{ $frontmatter.schema }}.

    +

    + No Methods found for {{ $frontmatter.schema }}. +

    @@ -72,7 +80,7 @@ const _ = require("lodash"); const yaml = require("js-yaml"); -console.clear(); +// console.clear(); let getMethods; @@ -98,6 +106,9 @@ export default { methods: [], }; }, + async extendPageData($page) { + $page.size = await getAsyncData(); + }, async beforeMount() { site = this.$site; page = this.$page; diff --git a/docs/api/reference/rest/v1/merchant.apiKeys/create.md b/docs/api/reference/rest/v1/merchant.apiKeys/create.md index 3c0933e..e42b167 100644 --- a/docs/api/reference/rest/v1/merchant.apiKeys/create.md +++ b/docs/api/reference/rest/v1/merchant.apiKeys/create.md @@ -7,6 +7,6 @@ schema: merchant.apiKeys operationId: merchant.apiKeys.create operation: post method: create -authLevel: KEY -authRoles: All +authLevel: RSA +authRoles: SUPERUSER, INTEGRATOR --- diff --git a/docs/api/reference/rest/v1/merchant.apiKeys/delete.md b/docs/api/reference/rest/v1/merchant.apiKeys/delete.md index 7d19d1e..d7b9b54 100644 --- a/docs/api/reference/rest/v1/merchant.apiKeys/delete.md +++ b/docs/api/reference/rest/v1/merchant.apiKeys/delete.md @@ -7,6 +7,6 @@ schema: merchant.apiKeys operationId: merchant.apiKeys.delete operation: delete method: delete -authLevel: KEY -authRoles: All +authLevel: RSA +authRoles: SUPERUSER, INTEGRATOR --- diff --git a/docs/api/reference/rest/v1/merchant.apiKeys/get.md b/docs/api/reference/rest/v1/merchant.apiKeys/get.md index b47245f..5f490e1 100644 --- a/docs/api/reference/rest/v1/merchant.apiKeys/get.md +++ b/docs/api/reference/rest/v1/merchant.apiKeys/get.md @@ -7,6 +7,6 @@ schema: merchant.apiKeys operationId: merchant.apiKeys.get operation: get method: get -authLevel: SECRET -authRoles: All +authLevel: JWT +authRoles: USER, SUPERUSER, INTEGRATOR --- diff --git a/docs/api/reference/rest/v1/merchant.apiKeys/index.md b/docs/api/reference/rest/v1/merchant.apiKeys/index.md index 594bc93..8974a5d 100644 --- a/docs/api/reference/rest/v1/merchant.apiKeys/index.md +++ b/docs/api/reference/rest/v1/merchant.apiKeys/index.md @@ -4,10 +4,11 @@ title: merchant.apiKeys description: Overview schema: merchant.apiKeys api: merchant +resourceDesc: true --- -## Merchant API Keys +::: slot resource +In order to gain access to the [Merchant API](/api/reference/rest) a client must authenticate itself using the `X-Settle-User` ID and the JWT/RSA KEY of an existing user. This means that the first user for a Merchant must be created in the **Self Service Portal** or by an Integrator on behalf of the Merchant. -In order to gain access to the [Merchant API](/api/reference/rest) a client must authenticate itself using the ID and the secret/public key of an existing user. This means that the first user for a merchant must be created in the Self Service Portal or by an integrator on behalf of the merchant. - -Each user is created for a specific merchant, which ID is given by the value of the **X-Settle-Merchant** header when making a [ `merchant.apiKeys.create` ](/api/reference/rest/v1/merchant.apiKeys/create/) request. A user can only interact with the API on behalf of the merchant which it was created for. The user ID is chosen on create and is has to be unique for the parent Merchant. +Each `X-Settle-User` is created for a specific Merchant, which ID is given by the value of the `X-Settle-Merchant` header when making a [ `merchant.apiKeys.create` ](/api/reference/rest/v1/merchant.apiKeys/create/) request. An API User can only interact with the API on behalf of the Merchant which it was created for. The `X-Settle-User` ID is chosen on `merchant.apiKeys.create` and is has to be unique for the parent Merchant. +::: diff --git a/docs/api/reference/rest/v1/merchant.apiKeys/list.md b/docs/api/reference/rest/v1/merchant.apiKeys/list.md index 5544f54..1d9cc57 100644 --- a/docs/api/reference/rest/v1/merchant.apiKeys/list.md +++ b/docs/api/reference/rest/v1/merchant.apiKeys/list.md @@ -7,6 +7,6 @@ schema: merchant.apiKeys operationId: merchant.apiKeys.list operation: get method: list -authLevel: KEY -authRoles: SUPERUSER, INTEGRATOR +authLevel: RSA +authRoles: USER, SUPERUSER, INTEGRATOR --- diff --git a/docs/api/reference/rest/v1/merchant.apiKeys/update.md b/docs/api/reference/rest/v1/merchant.apiKeys/update.md index 8d95a82..766c228 100644 --- a/docs/api/reference/rest/v1/merchant.apiKeys/update.md +++ b/docs/api/reference/rest/v1/merchant.apiKeys/update.md @@ -7,6 +7,6 @@ schema: merchant.apiKeys operationId: merchant.apiKeys.update operation: put method: update -authLevel: KEY -authRoles: All +authLevel: RSA +authRoles: SUPERUSER, INTEGRATOR --- diff --git a/docs/api/reference/rest/v1/merchant.balance/get.md b/docs/api/reference/rest/v1/merchant.balance/get.md index 8b20a9f..0fd2303 100644 --- a/docs/api/reference/rest/v1/merchant.balance/get.md +++ b/docs/api/reference/rest/v1/merchant.balance/get.md @@ -7,8 +7,8 @@ schema: merchant.balance operationId: merchant.balance.get operation: get method: get -authLevel: SECRET -authRoles: Any +authLevel: JWT +authRoles: USER, SUPERUSER, INTEGRATOR --- ::: slot example diff --git a/docs/api/reference/rest/v1/merchant.logo/get.md b/docs/api/reference/rest/v1/merchant.logo/get.md index 8d8c4a3..a5fe525 100644 --- a/docs/api/reference/rest/v1/merchant.logo/get.md +++ b/docs/api/reference/rest/v1/merchant.logo/get.md @@ -7,6 +7,6 @@ schema: merchant.logo operationId: merchant.logo.get operation: get method: get -authLevel: SECRET -authRoles: Any ---- \ No newline at end of file +authLevel: JWT +authRoles: USER, SUPERUSER, INTEGRATOR +--- From 3ec4ca51984a9e5cc210bde89eec17e5572a8577 Mon Sep 17 00:00:00 2001 From: Wick Date: Wed, 18 Aug 2021 10:35:35 +0200 Subject: [PATCH 04/10] Fix typo in menu --- docs/.vuepress/nav/left/guides.js | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/.vuepress/nav/left/guides.js b/docs/.vuepress/nav/left/guides.js index e9d6949..30d06d8 100644 --- a/docs/.vuepress/nav/left/guides.js +++ b/docs/.vuepress/nav/left/guides.js @@ -30,10 +30,10 @@ const introduction = { ['/api/guides/introduction/permission-requests.md','Permission Requests'], ['/api/guides/introduction/qr-acceptance.md','QR Acceptance'], ['/api/guides/introduction/resiliency.md','Resiliency'], - ['/api/guides/introduction/sandbox-environment.md','Sandbox Enviroment #1'], - ['/api/guides/introduction/settle-sandbox-environment.md',' Sandbox Enviroment #2'], + ['/api/guides/introduction/sandbox-environment.md','Sandbox Environment #1'], + ['/api/guides/introduction/settle-sandbox-environment.md',' Sandbox Environment #2'], ['/api/guides/introduction/settlements.md','Settlements'], - ['/api/guides/introduction/versioning.md','Verioning'], + ['/api/guides/introduction/versioning.md','Versioning'], ], }; From 7499051e17f1a2075da52217e899ba35aff3223c Mon Sep 17 00:00:00 2001 From: Wick Date: Mon, 4 Oct 2021 12:54:49 +0200 Subject: [PATCH 05/10] Remove all content except API Reference --- docs/.vuepress/config.js | 38 +- .../nav/left/rest/v1/reference/merchant.js | 21 +- docs/.vuepress/nav/left/rest/v1/resources.js | 4 +- docs/.vuepress/nav/sidebars.js | 22 +- docs/.vuepress/nav/top/mainNav.js | 27 +- .../theme/components/PageResourceOverview.vue | 13 +- .../api/guides/best-practices/introduction.md | 5 - docs/api/guides/index.md | 11 - .../a-note-on-settle-api-users.md | 9 - docs/api/guides/introduction/attachments.md | 46 -- .../api/guides/introduction/authentication.md | 134 ----- docs/api/guides/introduction/callbacks.md | 469 ------------------ .../guides/introduction/error-responses.md | 34 -- docs/api/guides/introduction/interacting.md | 136 ----- docs/api/guides/introduction/ledgers.md | 114 ----- docs/api/guides/introduction/media-type.md | 23 - docs/api/guides/introduction/payment-flows.md | 64 --- .../introduction/permission-requests.md | 82 --- docs/api/guides/introduction/qr-acceptance.md | 11 - docs/api/guides/introduction/resiliency.md | 9 - .../introduction/sandbox-environment.md | 40 -- .../settle-sandbox-environment.md | 5 - docs/api/guides/introduction/settlements.md | 98 ---- docs/api/guides/introduction/versioning.md | 7 - docs/api/guides/quickstarts/node.md | 6 - docs/api/guides/quickstarts/python.md | 6 - .../pos-with-dynamic-qr/index.md | 186 ------- .../pos-with-static-qr/index.md | 33 -- docs/api/guides/tutorials/index.md | 5 - .../oauth2/index.md | 6 - .../permission-requests/index.md | 6 - .../request-payment/index.md | 6 - .../send-payment/index.md | 6 - docs/api/reference/index.md | 3 + .../rest/v1/merchant.settlement/list.md | 12 + .../rest/v1/merchant.shortlink/index.md | 16 +- docs/api/samples/index.md | 0 docs/api/support/index.md | 43 -- docs/discovery/index.md | 21 - docs/discovery/v1/guides/getting-started.md | 27 - docs/discovery/v1/reference/apis/index.md | 12 - docs/discovery/v1/reference/apis/list.md | 30 -- docs/discovery/v1/reference/index.md | 16 - docs/index.md | 19 +- docs/sandbox/index.md | 1 - docs/terms/api-services-user-data-policy.md | 0 docs/terms/index.md | 0 docs/terms/site-policies.md | 0 docs/terms/site-terms.md | 0 49 files changed, 92 insertions(+), 1790 deletions(-) delete mode 100644 docs/api/guides/best-practices/introduction.md delete mode 100644 docs/api/guides/index.md delete mode 100644 docs/api/guides/introduction/a-note-on-settle-api-users.md delete mode 100644 docs/api/guides/introduction/attachments.md delete mode 100644 docs/api/guides/introduction/authentication.md delete mode 100644 docs/api/guides/introduction/callbacks.md delete mode 100644 docs/api/guides/introduction/error-responses.md delete mode 100755 docs/api/guides/introduction/interacting.md delete mode 100644 docs/api/guides/introduction/ledgers.md delete mode 100644 docs/api/guides/introduction/media-type.md delete mode 100644 docs/api/guides/introduction/payment-flows.md delete mode 100644 docs/api/guides/introduction/permission-requests.md delete mode 100644 docs/api/guides/introduction/qr-acceptance.md delete mode 100644 docs/api/guides/introduction/resiliency.md delete mode 100644 docs/api/guides/introduction/sandbox-environment.md delete mode 100644 docs/api/guides/introduction/settle-sandbox-environment.md delete mode 100644 docs/api/guides/introduction/settlements.md delete mode 100644 docs/api/guides/introduction/versioning.md delete mode 100644 docs/api/guides/quickstarts/node.md delete mode 100644 docs/api/guides/quickstarts/python.md delete mode 100644 docs/api/guides/tutorials/implementation-and-integration/pos-with-dynamic-qr/index.md delete mode 100644 docs/api/guides/tutorials/implementation-and-integration/pos-with-static-qr/index.md delete mode 100644 docs/api/guides/tutorials/index.md delete mode 100644 docs/api/guides/tutorials/permission-requests-and-oauth/oauth2/index.md delete mode 100644 docs/api/guides/tutorials/permission-requests-and-oauth/permission-requests/index.md delete mode 100644 docs/api/guides/tutorials/send-and-receive-payments/request-payment/index.md delete mode 100644 docs/api/guides/tutorials/send-and-receive-payments/send-payment/index.md create mode 100644 docs/api/reference/rest/v1/merchant.settlement/list.md delete mode 100644 docs/api/samples/index.md delete mode 100644 docs/api/support/index.md delete mode 100644 docs/discovery/index.md delete mode 100644 docs/discovery/v1/guides/getting-started.md delete mode 100644 docs/discovery/v1/reference/apis/index.md delete mode 100644 docs/discovery/v1/reference/apis/list.md delete mode 100644 docs/discovery/v1/reference/index.md delete mode 100644 docs/sandbox/index.md delete mode 100644 docs/terms/api-services-user-data-policy.md delete mode 100644 docs/terms/index.md delete mode 100644 docs/terms/site-policies.md delete mode 100644 docs/terms/site-terms.md diff --git a/docs/.vuepress/config.js b/docs/.vuepress/config.js index 2a9d45a..772b807 100644 --- a/docs/.vuepress/config.js +++ b/docs/.vuepress/config.js @@ -9,7 +9,7 @@ const moment = require('moment'); const sidebar = require('./nav/sidebars.js'); // console.log('Sidebar Rest: ', sidebar.rest()); -console.log('Sidebar Guides: ', sidebar.guides()); +// console.log('Sidebar Guides: ', sidebar.guides()); // console.log('Sidebar: ', sidebar.bar()); module.exports = (ctx) => ({ @@ -130,8 +130,8 @@ module.exports = (ctx) => ({ nav: require('./nav/top/mainNav.js'), sidebar: { '/api/reference/rest/': sidebar.rest(), - '/api/guides/': sidebar.guides(), - '/': sidebar.support(), + // '/api/guides/': sidebar.guides(), + // '/': sidebar.support(), }, }, /** @@ -197,20 +197,20 @@ module.exports = (ctx) => ({ 'redirect-frontmatter', 'img-lazy', ], - extraWatchFiles: [ - // Navigation - '.vuepress/nav/top/mainNav.js', - // Sidebars - '.vuepress/nav/sidebars.js', - '.vuepress/nav/left/guides.js', - '.vuepress/nav/left/rest/rest.js', - '.vuepress/nav/left/rest/v1/summary.js', - '.vuepress/nav/left/rest/v1/resources.js', - '.vuepress/nav/left/rest/v1/models/models.js', - '.vuepress/nav/left/rest/v1/reference/merchant.js', - '.vuepress/nav/left/rest/v1/reference/oauth2.js', - '.vuepress/nav/left/rest/v1/reference/users.js', - // Plugins - '.vuepress/plugins/getOpenAPI.js', - ], + // extraWatchFiles: [ + // // Navigation + // '.vuepress/nav/top/mainNav.js', + // // Sidebars + // '.vuepress/nav/sidebars.js', + // '.vuepress/nav/left/guides.js', + // '.vuepress/nav/left/rest/rest.js', + // '.vuepress/nav/left/rest/v1/summary.js', + // '.vuepress/nav/left/rest/v1/resources.js', + // '.vuepress/nav/left/rest/v1/models/models.js', + // '.vuepress/nav/left/rest/v1/reference/merchant.js', + // '.vuepress/nav/left/rest/v1/reference/oauth2.js', + // '.vuepress/nav/left/rest/v1/reference/users.js', + // // Plugins + // '.vuepress/plugins/getOpenAPI.js', + // ], }); diff --git a/docs/.vuepress/nav/left/rest/v1/reference/merchant.js b/docs/.vuepress/nav/left/rest/v1/reference/merchant.js index c0c8166..d7d046f 100644 --- a/docs/.vuepress/nav/left/rest/v1/reference/merchant.js +++ b/docs/.vuepress/nav/left/rest/v1/reference/merchant.js @@ -144,36 +144,39 @@ function merchant_settlement() { sidebarDepth: 0, children: [ ['/api/reference/rest/v1/merchant.settlement/', 'Overview'], + [`/api/reference/rest/v1/merchant.settlement/list`, 'list'], ['/api/reference/rest/v1/merchant.settlement/get', 'get'], ], }; } -function merchant_settlement_account() { +function merchant_settlement_latest() { return { - title: 'merchant.settlement.account', // required + title: 'merchant.settlement.latest', // required collapsable: true, sidebarDepth: 0, children: [ - ['/api/reference/rest/v1/merchant.settlement.account/', 'Overview'], - ['/api/reference/rest/v1/merchant.settlement.account/get', 'get'], - ['/api/reference/rest/v1/merchant.settlement.account/update', 'update'], + ['/api/reference/rest/v1/merchant.settlement.latest/', 'Overview'], + ['/api/reference/rest/v1/merchant.settlement.latest/get', 'get'], ], }; } -function merchant_settlement_latest() { +function merchant_settlement_account() { return { - title: 'merchant.settlement.latest', // required + title: 'merchant.settlement.account', // required collapsable: true, sidebarDepth: 0, children: [ - ['/api/reference/rest/v1/merchant.settlement.latest/', 'Overview'], - ['/api/reference/rest/v1/merchant.settlement.latest/get', 'get'], + ['/api/reference/rest/v1/merchant.settlement.account/', 'Overview'], + ['/api/reference/rest/v1/merchant.settlement.account/get', 'get'], + ['/api/reference/rest/v1/merchant.settlement.account/update', 'update'], ], }; } + + function merchant_settlement_report() { return { title: 'merchant.settlement.report', // required diff --git a/docs/.vuepress/nav/left/rest/v1/resources.js b/docs/.vuepress/nav/left/rest/v1/resources.js index 4916b29..2c23a1e 100644 --- a/docs/.vuepress/nav/left/rest/v1/resources.js +++ b/docs/.vuepress/nav/left/rest/v1/resources.js @@ -11,8 +11,8 @@ const { merchant_profile, merchant_sales_summary, merchant_settlement, - merchant_settlement_account, merchant_settlement_latest, + merchant_settlement_account, merchant_settlement_report, merchant_shortlink, merchant_ssp_users, @@ -57,8 +57,8 @@ function merchantGroup() { merchant_profile, merchant_sales_summary, merchant_settlement, - merchant_settlement_account, merchant_settlement_latest, + merchant_settlement_account, merchant_settlement_report, merchant_shortlink, // merchant_ssp_users, diff --git a/docs/.vuepress/nav/sidebars.js b/docs/.vuepress/nav/sidebars.js index 274ac64..30b542f 100644 --- a/docs/.vuepress/nav/sidebars.js +++ b/docs/.vuepress/nav/sidebars.js @@ -8,22 +8,22 @@ // } = require('./left/rest/rest.js'); const rest = require('./left/rest/rest.js'); -const guides = require('./left/guides.js'); -const support = require('./left/support.js'); +// const guides = require('./left/guides.js'); +// const support = require('./left/support.js'); const sidebar_rest = () => { return rest; } -const sidebar_guides = () => { - return guides; -} - -const sidebar_support = () => { - return support; -} +// const sidebar_guides = () => { +// return guides; +// } +// +// const sidebar_support = () => { +// return support; +// } exports.rest = sidebar_rest; -exports.guides = sidebar_guides; -exports.support = sidebar_support; \ No newline at end of file +// exports.guides = sidebar_guides; +// exports.support = sidebar_support; diff --git a/docs/.vuepress/nav/top/mainNav.js b/docs/.vuepress/nav/top/mainNav.js index 197e147..720dfba 100644 --- a/docs/.vuepress/nav/top/mainNav.js +++ b/docs/.vuepress/nav/top/mainNav.js @@ -1,11 +1,12 @@ -module.exports = [{ - text: 'Home', - link: '/', - }, - { - text: 'Guides', - link: '/api/guides/', - }, +module.exports = [ + // { + // text: 'Home', + // link: '/', + // }, + // { + // text: 'Guides', + // link: '/api/guides/', + // }, { text: 'Reference', link: '/api/reference/rest/v1/', @@ -16,6 +17,10 @@ module.exports = [{ // }, { text: 'Support', - link: '/api/support/', - } -] \ No newline at end of file + link: 'https://support.settle.eu/hc/en-150/categories/4406888724625-Settle-for-Developers', + }, + // { + // text: 'Support', + // link: '/api/support/', + // } +] diff --git a/docs/.vuepress/theme/components/PageResourceOverview.vue b/docs/.vuepress/theme/components/PageResourceOverview.vue index 4598e08..c42db13 100644 --- a/docs/.vuepress/theme/components/PageResourceOverview.vue +++ b/docs/.vuepress/theme/components/PageResourceOverview.vue @@ -7,16 +7,13 @@ # - REST Resource + REST Resource: {{ $frontmatter.schema }} -
    -

    {{ $frontmatter.schema }}

    -

    -
    -

    + +

    # Resource -

    +
    @@ -24,7 +21,7 @@

    There is no persistent data associated with this resource.

    - +

    # HTTP Requests diff --git a/docs/api/guides/best-practices/introduction.md b/docs/api/guides/best-practices/introduction.md deleted file mode 100644 index b148af8..0000000 --- a/docs/api/guides/best-practices/introduction.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Introduction -description: Introduction ---- -# Introduction \ No newline at end of file diff --git a/docs/api/guides/index.md b/docs/api/guides/index.md deleted file mode 100644 index f50187d..0000000 --- a/docs/api/guides/index.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: Settle API Overview -description: Getting started with the Settle API ---- -# Getting started with the Settle API - -**The Settle API allows merchants in the Settle network to integrate Settle into their payment solutions, such as POS terminals, websites, and mobile apps. The API is a versatile framework of functions to create custom payment flows, with buttons, QR codes, or phone numbers depending on the use case.** - -To get started we recommend that you first create a consumer account and a business account in the [Sandbox environment](/sandbox). This allows you to try out Settle and test your integration without having to worry about real money. - -You can then follow one the tutorials or checkout the API references directly. \ No newline at end of file diff --git a/docs/api/guides/introduction/a-note-on-settle-api-users.md b/docs/api/guides/introduction/a-note-on-settle-api-users.md deleted file mode 100644 index 8084364..0000000 --- a/docs/api/guides/introduction/a-note-on-settle-api-users.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: A Note on Settle API Users -description: A Note on Settle API Users ---- -# A Note on Settle API Users - -All requests to the Settle API must include an X-Auka-User header.† API Users are assigned and created by the Merchant through the Self Service Portal, or by the Integrator using the user endpoint. Each API User has an ID unique to that Merchant and is assigned a shared secret and/or a RSA public key that is used for authentication. A typical use case (and the one we recommend) is assigning separate API Users for each POS in the shop. In another case, the Merchant owns and administrates a central server that acts as a proxy for all POSes: in that case, only one API User is created, and its credentials are used by all POSes when making payment requests. In a third case, an Integrator controls the single proxy server; in that case the Integrator uses the X-Auka-Integrator header in place of an X-Auka-User header. It is up to the Merchant (or, as the case may be, the Integrator) how to set this up. - -† Except when an Integrator is acting as a proxy on behalf of a Merchant client. In that case, the X-Auka-Integrator header is used instead. See above. \ No newline at end of file diff --git a/docs/api/guides/introduction/attachments.md b/docs/api/guides/introduction/attachments.md deleted file mode 100644 index aa9c910..0000000 --- a/docs/api/guides/introduction/attachments.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: Attachments -description: Attachments ---- -# Attachments - - - -Typically the POS uploads an electronic receipt after the payment has been confirmed. By the Merchant Agreement, the Merchant is required to provide information of the purchase to the user. This is done by uploading either Receipts or ItemLists to an attachment URI. - -## How to upload[](https://developer.settle.eu/attachments.html#how-to-upload "Permalink to this headline") - -Attachment URIs are generated by Settle and are given in the attachment_uri field in the JSON response on certain endpoint. At the moment only the [`outcome`](https://developer.settle.eu/handlers.html#get--payment_request--tid--outcome- "GET /payment_request/\/outcome/") endpoint for payment request exposes such a field. When an attachment URI has been acquired, any number of files can be uploaded by making a POST request formatted as *multipart/form-data*. This format is described in **[RFC 2388](http://tools.ietf.org/html/rfc2388.html)**. However, libraries that are able to make multipart/form-data HTTP requests are readily available for most programming languages. - -Note that each upload is "all or nothing". This means that if one or more files fails in a multi-file upload (e.g. due to failed server-side format validation), the entire upload will be discarded by Settle. - -## Supported mime-types[](https://developer.settle.eu/attachments.html#supported-mime-types "Permalink to this headline") - -The uploaded data is validated according to the Content-Type of the part in the request. - -The supported MIME-types and their respective schemas are: - -* * `'application/vnd.mcash.itemlist.v1+json'` - - * * Settle item lists. Will be rendered for the user in the Settle app. - * | | | - | ---------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | - | **store_name** : String : optional : default=null | Information about the Store | - | **organization_number** : String : optional : default=null | Organization number, e.g. "123456789MVA" | - | **items\[]** : [Item](https://developer.settle.eu/types.html#wtforms-fielddoc-attachments-1) : optional : default=null | Items | -* * `'application/vnd.mcash.receipt.v1+json'` - - * | | | - | ----------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- | - | **cashier** : String : optional : default=null | Seller ID or seller name | - | **register** : String : optional : default=null | Cash register/POS identifier | - | **store** : [Store](https://developer.settle.eu/types.html#wtforms-fielddoc-attachments-2) : optional : default=null | Information about the Store | - | **items\[]** : [ReceiptItem](https://developer.settle.eu/types.html#wtforms-fielddoc-attachments-3) : optional : default=null | Items | - | **payments\[]** : [ReceiptPayment](https://developer.settle.eu/types.html#wtforms-fielddoc-attachments-4) : optional : default=null | Payments | - | **currency** : String : optional : default=null | The currency of amounts on this receipt | - | **gross** : String : optional : default=null | Gross amount before discounts | - | **discount** : String : optional : default=null | Discount on the gross | - | **net** : String : optional : default=null | gross - discount | -* * `'image/png'` - - No schema, only size restriction of 1 MB. \ No newline at end of file diff --git a/docs/api/guides/introduction/authentication.md b/docs/api/guides/introduction/authentication.md deleted file mode 100644 index daeadfe..0000000 --- a/docs/api/guides/introduction/authentication.md +++ /dev/null @@ -1,134 +0,0 @@ ---- -title: Authentication -description: Authentication ---- - -# Authentication - -In the Settle API different authentication levels (auth levels) can be achieved depending on the authentication method being used. In the [API Reference](/api/merchant/) the required level for each endpoint in the API is given. A list is given here of the auth levels in the Settle API, ordered from lowest to highest level: - -1. OPEN _(no authentication required)_ -2. [SECRET](#authentication-using-secret) -3. [KEY](#authentication-using-rsa-signature) - -When authenticated with a particular auth level, the client is also authorized for endpoints requiring a lower auth level. E.g. if authenticated with auth level [KEY](/guides/authentication/#authentication-using-rsa-signature), endpoints requiring [SECRET](/guides/authentication/#authentication-using-secret) or OPEN are also accessible. - -## Required Request Headers - -Any request to the Settle API requires the following request headers: - -| X-Auka-Merchant: | This header should contain the Settle ID of the merchant as returned in the `id` field of the [`merchant`](https://developer.settle.eu/handlers.html#get--merchant--merchant_id-- 'GET /merchant//') endpoint. | -| X-Auka-User: | The ID (username) of the user/client doing the request on behalf of the merchant. Users are created by the merchant through the Self Service Portal or by the integrator using the `user` endpoint. Each user has is an ID locally unique for the merchant and is assigned a shared secret and/or a RSA public key that is used for authentication. | -| Authorization: | The value of this field depends on what kind of authentication scheme is being used. Currently the supported schemes are _SECRET_ and _RSA-SHA256_. The general form of this header is: `Authorization: ` | -| X-Auka-Integrator: | Only to be used by integrators acting as a proxy on behalf of merchant client, in which case it replaces the **X-Auka-User** header. The value of this field is the ID issued to the integrator by Settle. When this header is used only authentication using RSA signatures is allowed (not secret) and Settle will check the signature against the public key of the integrator. | - -::: tip NOTE -When using the Settle testbed environment, an **X-Testbed-Token** header is also required. The value of this header is the testbed token you received via email when activating your testbed account. It looks like: - -`s_Qu1gkYsZUvK-RvO43Ij02CYV-3wyMp5uUn1AodymQ` -::: - -::: tip NOTE -The **X-Auka-Integrator** header MUST NOT be used unless the merchant clients are communicating _through_ a server, controlled by the integrator, acting as a proxy. If a client is using a direct connection to Settle, even though the integrator owns the client and may control it through some other channel, it MUST use merchant user credentials and the **X-Auka-User** header. -::: - -## Authentication using SECRET - -- Auth Level: SECRET - -Authentication using a shared secret (JSON Web Token) is the simplest authentication method supported by Settle. This method requires an authorization header on the following form: - -`Authorization: SECRET ` - -Below is an example of a request where user **POS1** is doing an **HTTP POST** to **https://sever.test/some/resource/** on behalf of a merchant whose ID is **T9oWAQ3FSl6oeITuR2ZGWA**. The secret is **MySecretPassword** and the request body is `{"text": "Hello world"}`. - -```http -POST /some/resource/ HTTP/1.1 -HOST: server.test -Accept: application/vnd.mcash.api.merchant.v1+json -Content-Type: application/json -X-Auka-Merchant: T9oWAQ3FSl6oeITuR2ZGWA -X-Auka-User: POS1 -Authorization: SECRET MySecretPassword - -{"text": "Hello world"} -``` - -## Authentication using RSA signature - -- Auth Level: KEY - -Settle generates and validates according to the _PKCS#1 v1.5_ (RSASSA-PKCS1-v1_5) standard described in **[RFC 3447](http://tools.ietf.org/html/rfc3447.html)**. The hash function used in the signing procedure is [SHA256](https://en.wikipedia.org/wiki/SHA-2). - -### Headers - -The RSA authentication method requires two extra headers: - -#### X-Auka-Timestamp - -> The current UTC time. The time format is `YYYY-MM-DD hh:mm:ss`. - -#### X-Auka-Content-Digest - -> The _base64_ encoded hash digest of the request body. If the body is empty, the hash should be computed on an empty string. The value of the header should be on the form `=`. So, if the SHA256 hashing algorithm is used on a request with empty body, the header will be: `X-Auka-Content-Digest: SHA256=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=` Currently only the SHA256 hashing algorithm is supported. - -For RSA authentication the authorization header looks like this: - -```http -Authorization: RSA-SHA256 -``` - -The string that is to be signed (the signature message) is constructed from the request in the following manner: - -``` -|| -``` - -Here, `method` is the HTTP method used in the request, `url` is the full url including protocol and query component (the part after `?`) but without fragment component (The part after `#`). The `scheme name` (typically https) and `hostname` components are always lowercase, while the rest of the `url` is case sensitive. The `headers` part is a querystring using header names and values as key-value pairs. So, the constructed string will be of the form: - -``` -name1=value1&name2=value2... -``` - -::: tip In addition the following requirements apply: - -1. Headers are sorted alphabetically. -2. All header names must be made uppercase before constructing the string. -3. Headers whose names don't start with **X-Auka-** are excluded. - ::: - -Reusing the example in the previous section, a typical HTTP request will look like this: - -```http -POST /some/resource/ HTTP/1.1 -HOST: server.test -Accept: application/vnd.mcash.api.merchant.v1+json -Content-Type: application/json -X-Auka-Merchant: T9oWAQ3FSl6oeITuR2ZGWA -X-Auka-User: POS1 -X-Auka-Timestamp: 2013-10-05 21:33:46 -X-Auka-Content-Digest: SHA256=oWVxV3hhr8+LfVEYkv57XxW2R1wdhLsrfu3REAzmS7k= -Authorization: RSA-SHA256 p8+PdS5dDa6Ig46jNQhE8qQR+J8rRgX77cyXN3EIvUqpQ2lB8Cz1bcUF6lwvdVbz4NSUIQD/OCT8X2WtqRNbPW+5DDzGC1TytiV6p0EXiMOAl7s6kioHnVGaiCSHyfO6ZYB7ubtcMtUE0+7OEUcPeaqSHeL4wwUkO8W0+euwGsfwl9gOoQHBFIOh0bh8z3JNGhUeIZM8fvrk+8kj/s2A70IBvUOLwcFeP8uf6gTi1fz7BtgJ5rHmfvn9HvrsyO53/nx2mXZdAap4MfOZa6dp0ievZ5kU1vEfB2R6f4uPHzKLnaePlDOQMTk+uHlxU0ChkSqenbgJvpGuaOGiQekwsA== - -{"text": "Hello world"} -``` - -In this case the header part of the signature message is: - -```http -X-AUKA-CONTENT-DIGEST=SHA256=oWVxV3hhr8+LfVEYkv57XxW2R1wdhLsrfu3REAzmS7k=&X-AUKA-MERCHANT=T9oWAQ3FSl6oeITuR2ZGWA&X-AUKA-TIMESTAMP=2013-10-05 21:33:46&X-AUKA-USER=POS1 -``` - -and complete signature message is: - -```http -POST|http://server.test/some/resource/|X-AUKA-CONTENT-DIGEST=SHA256=oWVxV3hhr8+LfVEYkv57XxW2R1wdhLsrfu3REAzmS7k=&X-AUKA-MERCHANT=T9oWAQ3FSl6oeITuR2ZGWA&X-AUKA-TIMESTAMP=2013-10-05 21:33:46&X-AUKA-USER=POS1 -``` - -The key-pair that was used for generating the signature in this example can be downloaded here: [`public`](https://developer.settle.eu/_downloads/sample-pubkey.pem), [`private`](https://developer.settle.eu/_downloads/sample-privkey.pem) - -The Python script that was used for generating the signature and `X-Auka-Content-Digest` header can be downloaded [`here`](https://developer.settle.eu/_downloads/rsa_example.py) - -## Verifying signatures from Settle - -Whenever Settle is sending callbacks to the client over HTTPS the request from Settle is signed using the same RSA method as described in the above _[section](/guides/authentication/#authentication-using-rsa-signature)_. The client should authenticate callbacks from Settle by verifying the signature given by Settle in the Authorization header of the request. The public key used by Settle in test environments can be downloaded [`here`](https://developer.settle.eu/_downloads/testserver-pub.pem). The public key for the production environment can be obtained by contacting Settle. diff --git a/docs/api/guides/introduction/callbacks.md b/docs/api/guides/introduction/callbacks.md deleted file mode 100644 index fc9016d..0000000 --- a/docs/api/guides/introduction/callbacks.md +++ /dev/null @@ -1,469 +0,0 @@ ---- -title: Callbacks -description: Callbacks ---- -# Callbacks - -API clients can associate some resources with a `callback_uri` in order to enable asynchronous communication between the client and server. At certain events Settle can trigger a callback to specified `callback_uri`. E.g. if the callback URI is an HTTP URI, an HTTP POST request will be made to the URI. The data sent with the callback is referred to as a "callback message" (or just "message"). The message consists of a `meta` part and an `object` part, the latter containing the actual message data, while the former is meta information about the callback. Note that you do not have to know everything about callbacks in order to implement an API client. However, *all developers should read the* *[Security considerations](#security-considerations)* *section*. - -Callbacks support several protocols (see *[Supported protocols](#supported-protocols)*) For protocols that are considered secure the callback will contain the entire message. Let us first consider an example where the callback is made using a secure protocol. The example `callback_uri` of the resource is `https://callbackserver.test/notification/qWeR/`, which is an HTTPS URI. - -```http -POST /notification/qWeR/ HTTP/1.1 - -HOST: callbackserver.test -Authorization: RSA-SHA256 -X-Auka-Content-Digest: SHA256= -Content-Type: application/vnd.mcash.api.merchant.v1+json - -{ - "meta": { - "id": "RzeUPFP1T5WkWd46tX8Hxg", - "event": "test_event", - "uri": "https://server.test/my_resource/1/" - }, - "object": { "text": "Hello World" } -} -``` - -Notice the headers `Authorization` and `X-Auka-Content-Digest`. The values of these headers contain the information necessary for the client to authenticate the callback from Settle. See *[Verifying signatures from Settle](https://developer.settle.eu/authentication.html#authentication-settle-signatures)* for a description of the signature method used in requests from Settle. - -For insecure protocols, Settle will only send non-sensitive meta-information. In this example the `callback_uri` is `http://callbackserver.test/notification/qWeR/` (HTTP): - -```http -POST /notification/qWeR HTTP/1.1 - -HOST: callbackserver.test -Content-Type: application/vnd.mcash.api.merchant.v1+json - -{ - "meta": { - "id": "RzeUPFP1T5WkWd46tX8Hxg", - "event": "test_event", - "uri": "https://server.test/my_resource/1/" - } -} -``` - -Here the `uri` field contains a URI that points to an endpoint on an Settle server where the `object` part can be retrieved using an HTTPS GET. - -```http -GET /my_resource/1/ HTTP/1.1 - -HOST: server.test -``` - -```http -HTTP/1.1 200 OK -Content-Type: application/vnd.mcash.api.merchant.v1+json - -{"text": "Hello World"} -``` - -## Events - -The value in the `event` field in the `meta` part of the message is called the message event or just event. The event says something about why the callback was made and how to interpret the `object` part (a data schema is defined for each event). - -### Payment request - -Several events are associated with the different transitions in payment request state: - -* `payment_authorized` - - * *(User has accepted a payment request. Used for both AUTH and SALE requests)* -* `payment_captured` -* `payment_auth_released` -* `payment_aborted_by_customer` -* `payment_aborted_by_merchant` -* `payment_authorization_renewed` -* `payment_authorization_expired` -* `payment_request_expired` - -As these events reflect the state of the payment request at the time the callback was made, the `object` part will contain the same data as what can be retrieved from the payment request [`outcome`](https://developer.settle.eu/handlers.html#get--payment_request--tid--outcome- "GET /payment_request/\/outcome/") endpoint. The data schema is: - -
    - -#### currency - -* Type: [`Currency`](/api/resources/types/#currency) -* Required: `true` -* Default: `null` - -ISO 4217 currency code. See [Currency](/api/resources/types/#currency). - -#### amount - -* Type: [`MoneyInteger`](/api/resources/types/#moneyinteger) -* Required: `false` -* Default: `null` - -See [MoneyInteger](/api/resources/types/#moneyinteger). - -#### additional_amount - -* Type: [`MoneyInteger`](/api/resources/types/#moneyinteger) -* Required: `false` -* Default: `null` - -Additional amount might have been changed by user if `additional_edit` was true. See [MoneyInteger](/api/resources/types/#moneyinteger). - -#### auth_amount - -* Type: [`MoneyInteger`](/api/resources/types/#moneyinteger) -* Required: `false` -* Default: `null` - -The authorized amount. If doing partial captures, this will show the amount still available in the authorization for subsequent captures; auth_amount = amount - sum (captured amounts). See [MoneyInteger](/api/resources/types/#moneyinteger). - -#### auth_additional_amount - -* Type: [`MoneyInteger`](/api/resources/types/#moneyinteger) -* Required: `false` -* Default: `null` - -The authorized additional amount. If doing partial captures, this will show the part of additional amount still available in the authorization for subsequent captures; auth_additional_amount = additional_amount - sum(captured additional amounts). See [MoneyInteger](/api/resources/types/#moneyinteger). - -#### captures - -* Type: [`Capture`](/api/resources/types/#capture) -* Required: `false` -* Default: `null` - -List of captures. See [Capture](/api/resources/types/#capture). - -#### refunds - -* Type: [`Refund`](https://developer.settle.eu/types.html#wtforms-fielddoc-callbacks-3) -* Required: `false` -* Default: `null` - -List of refunds. See [Refund](https://developer.settle.eu/types.html#wtforms-fielddoc-callbacks-3). - -#### status - -* Type: `string` -* Required: `false` -* Default: `null` -* Values: `ok` | `fail` | `auth` | `pending` - -Payment request status (see above). - -#### status_code - -* Type: `integer` -* Required: `false` -* Default: `null` -* Values: `ok` | `fail` | `auth` | `pending` - -Payment request status code (see above). - -#### customer - -* Type: [`PersonIdentifier`](https://developer.settle.eu/types.html#wtforms-fielddoc-callbacks-6) -* Required: `false` -* Default: `null` - -Customer identifier as originally registered by POS. See [PersonIdentifier](https://developer.settle.eu/types.html#wtforms-fielddoc-callbacks-6). - -#### date_modified - -* Type: [`DateTime`](https://developer.settle.eu/types.html#wtforms-fielddoc-callbacks-7) -* Required: `false` -* Default: `null` - -Last modified date. See [DateTime](https://developer.settle.eu/types.html#wtforms-fielddoc-callbacks-7) - -#### date_expires - -* Type: [`DateTime`](https://developer.settle.eu/types.html#wtforms-fielddoc-callbacks-7) -* Required: `false` -* Default: `null` - -Expiration date for current status. After a payment authorization is given this may extend beyond the original expiry date given in the payment request. An authorization expires after 3 days. When the payment request expires it is marked as failed (whether in pending or authorized state). See [DateTime](https://developer.settle.eu/types.html#wtforms-fielddoc-callbacks-7). - -#### credit - -* Type: `Boolean` -* Required: `true` -* Default: `null` - -Whether the received payment was a credit payment. - -#### interchange_fee - -* Type: [`MoneyInteger`](/api/resources/types/#moneyinteger) -* Required: `false` -* Default: `null` - -Interchange fee to be deducted if credit payment. See [MoneyInteger](/api/resources/types/#moneyinteger). - -#### transaction_fee - -* Type: [`MoneyInteger`](/api/resources/types/#moneyinteger) -* Required: `false` -* Default: `null` - -Transaction fee to be deducted. See [MoneyInteger](/api/resources/types/#moneyinteger). - -#### attachment_uri - -* Type: `string` -* Required: `false` -* Default: `null` - -Endpoint for Attachment uploads, such as electronic receipts. This URI has a limited time to live, and a new URI is generated each time outcome is retrieved. - -#### pos_id - -* Type: `string` -* Required: `true` - -Data required (new or existing on update). The POS this request originates from, used for informing user about origin. - -#### pos_tid - -* Type: `string` -* Required: `true` -* Length: <= 64 -* Regexp: `^[a-zA-Z0-9_.-]+$` - -Local transaction id for POS. This must be unique for the POS. - -#### tid - -* Type: `string` -* Required: `true` -* Length: <= 64 -* Regexp: `^[a-zA-Z0-9_.-]+$` - -Settle transaction id. - -#### permissions - -* Type: [`AccessTokenResponse`](/api/resources/types/#moneyinteger0) -* Required: `false` -* Default: `null` - -If payment request was combined with a permission request, this field will contain the permission request outcome. Same as returned by a GET the permission request outcome endpoint. See [AccessTokenResponse](/api/resources/types/#moneyinteger0). - -
    - -### Permission request - -There are two events associated with permission requests: - -* permission_request_answered (User has processed the request and accepted or declined access to one or more resources) -* permission_request_expired - -The same data is available at the [`outcome`](https://developer.settle.eu/handlers.html#get--permission_request--rid--outcome- "GET /permission_request/\/outcome/") endpoint, with response schema: - -
    - -#### access_token - -* Type: `string` -* Required: `false` -* Default: `null` - -See [Access token](<>). - -#### id_token - -* Type: `string` -* Required: `false` -* Default: `null` - -A JWT that contains identity information about the user that is digitally signed by Settle. See [Lorem](<>). - -#### token_type - -* Type: `string` -* Required: `true` -* Default: `null` - -Type of access token, at this time it will always be Bearer. See [Lorem](<>). - -#### expires_in - -* Type: `string` -* Required: `false` -* Default: `null` - -Lifetime in seconds of the [`access_token`](#access-token). See [Lorem](<>). - -#### refresh_token - -* Type: `string` -* Required: `false` -* Default: `null` - -Refresh token used to issue new access token after expiration. See [Lorem](<>). - -#### scope - -* Type: `string` -* Required: `false` -* Default: `null` -* Values: `address` | `bankid` | `email` | `fodselsnummer` | `openid` | `phone` | `profile` | `shipping_address` - -Space-delimited list of scopes. See [Lorem](<>). - -#### currency - -* Type: [`Currency`](https://developer.settle.eu/types.html#wtforms-fielddoc-callbacks-0) -* Required: `false` -* Default: `null` -* Length: == 3 - -Currency for fee. See [Currency ](https://developer.settle.eu/types.html#wtforms-fielddoc-callbacks-0). - -#### transaction_fee - -* Type: [`MoneyInteger`](/api/resources/types/#moneyinteger) -* Required: `false` -* Default: `null` - -Permission fee to be deducted from settlement. See [MoneyInteger](/api/resources/types/#moneyinteger). - -#### status - -* Type: `string` -* Required: `false` -* Default: `null` - -Permission request status. See [Lorem](<>). - -#### status_code - -* Type: `integer` -* Required: `false` -* Default: `null` - -Permission request status code. See [Lorem](<>). - -#### pos_id - -* Type: `string` -* Required: `true` -* Data: New or existing on update -* Length: <= 64 -* Regexp: ^\[a-zA-Z0-9_.-]+$ - -The POS this request originates from, used for informing user about origin. See [Lorem](<>). - -#### pos_id - -* Type: `string` -* Required: `true` -* Data: New or existing on update -* Length: <= 64 -* Regexp: ^\[a-zA-Z0-9_.-]+$ - -Local transaction id for POS. This must be unique for the POS. See [Lorem](<>). - -#### rid - -* Type: `string` -* Required: `true` -* Data: New or existing on update - -Settle request id. This must be unique for the POS. See [Lorem](<>). - -#### user_info - -* Type: [`JSON`](/api/resources/types/#json) -* Required: `false` -* Default: `null` - -User Info. See [JSON](/api/resources/types/#json). - -
    - -### Shortlink scan - -Whenever a shortlink is scanned a callback will be made by Settle to the URI that was given in the `callback_uri` field of the shortlink resource. The event for this callback is *shortlink_scanned* and the data schema for the `object` part is: - -
    - -#### id - -* Type: `string` -* Required: `false` -* Data: New or existing on update - -The scan token ID that can be used as recipient for payment and permission requests. Expires in one day. See [Lorem](<>). - -#### argstring - -* Type: `string` -* Required: `false` -* Default: `null` - -The string that was appended to the shortlink value in the QR code that was scanned. See [Lorem](<>). - -
    - -Note that this event is exempt from the "secure callback rule". I.e. the `object` part is always included, no matter what protocol is being used for the callback. Hence the `uri` field in the `meta` part is `null`. - -If that callback is made using HTTP or HTTPS, the recipient of the callback may return the following data, which will be transported back to the user agent that scanned the shortlink, in the HTTP(S) response body: - -
    - -#### text - -* Type: `string` -* Required: `false` -* Default: `null` - -Text that will be displayed to user. See [Lorem](<>). - -#### uri - -* Type: `string` -* Required: `false` -* Default: `null` - -URI to open in Settle App. **DEPRECATED**: use [`next`](#next) action payload instead. - -#### next - -* Type: [`JSON`](/api/resources/types/#json) -* Required: `false` -* Default: `null` - -Next action. - -
    - -## Supported protocols - -The part before the first colon in the callback URI determines the protocol that will be used for the callback. The meaning of the part after the colon depends on the actual protocol. The supported protocols with descriptions are given here. - -### HTTP - -Example URI: `http://acme.com/payment_request/Qd3/callback/` - -Settle will make an HTTP POST request to the specified URI. The content-type of the request will be the *[API media type](https://developer.settle.eu/introduction.html#introduction-media-type)*, unless a different media type is documented for the particular callback. The request is signed by Settle according to *[Authentication using RSA signature](https://developer.settle.eu/authentication.html#authentication-rsa-signing)*. - -### HTTPS (secure) - -Example URI: `https://acme.com/paymjsoent_request/Qd3/callback/` - -Same as HTTP, except that HTTPS is considered secure which means that the `object` part is included in the callback message. Settle verifies SSL certificates, so the recipient of the callback must use a CA signed certificate. If the client is going to use the data in the `object` part it SHOULD verify that the callback has been correctly signed by Settle. - -## Security considerations - -One important criterion for the Settle APIs is that the responsibility for security should mostly fall on the server (Settle) not the client. However, regarding callbacks one responsibility that falls on the client is to verify the origin of the data sent with the callback before putting it to use. There are two ways to do this. - -### Validation of message URI - -If the client does not implement signature verification or is using a protocol for callbacks that does not support signatures, the callback can be verified using the following procedure: - -1. Verify that the hostname in the message URI in the `uri` field in the `meta` part is an settle.eu sub-domain and that the URI is HTTPS. I.e. check that the URI starts with "https:" and that the hostname ends with ".settle.eu". Example of a valid URI: `https://api.settle.eu/merchant/v1/`. -2. Retrieve the message by making an HTTPS GET request to the message URI. Make sure that your HTTPS client library is configured to verify SSL certificates. The retrieved message can safely be used as it's origin has been verified through HTTPS. - -Note that some of our test environments have hostnames that are not a sub-domain of ".settle.eu", in which case this method will not work. - -### Verify the callback signature - -For some protocols, like HTTP and HTTPS, it is specified that Settle signs the callback. If the client verifies the signature according to the specified signature method, any data sent with the callback can be used safely. \ No newline at end of file diff --git a/docs/api/guides/introduction/error-responses.md b/docs/api/guides/introduction/error-responses.md deleted file mode 100644 index 7d3fbfd..0000000 --- a/docs/api/guides/introduction/error-responses.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: Error Responses -description: Error Responses ---- -# Error Responses - -In general the error response body consists of an `error_type`, an `error_description` and some `error_details`. The example below shows the response for validation errors. - -```http - POST /test/ HTTP/1.1 - HOST: callbackserver.test - Content-Type: application/vnd.mcash.api.merchant.v1+json - - {"amount": "-42"} -``` - -```http - HTTP/1.1 400 Bad Request - Content-Type: application/vnd.mcash.api.merchant.v1+json - - { - "error_type": "validation_error", - "error_description": "Your request caused validation errors. Please check your data.", - "error_details":{"amount": ["Value must be larger than 0"]} - } -``` - -The HTTP response code can also hold useful information about the error that occurred, in addition to these fields: - -| | | -| ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | -| **error_type** : String : optional : default=null | Type of error. | -| **error_description** : String : optional : default=null | Human readable description. | -| **error_details** : [Json](https://developer.settle.eu/types.html#wtforms-fielddoc-callbacks-9) : optional : default=null | Keyed JSON Object structure containing detailed error information, if present. Otherwise `null`. | \ No newline at end of file diff --git a/docs/api/guides/introduction/interacting.md b/docs/api/guides/introduction/interacting.md deleted file mode 100755 index 1307bf6..0000000 --- a/docs/api/guides/introduction/interacting.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -title: Interacting with the REST API's -description: How to interact with the Settle REST API's ---- -# Creating, Retrieving, Updating and Deleting resources (CRUD) - -Resources are created by making an HTTP POST request to a list endpoint, and updated by PUTting to the detail endpoint of the created resource. Resource data is retrieved using GET and deleted using DELETE, both to the detail endpoint. Making a GET request to a list endpoint that supports it yields a list of URLs to detail endpoints for the resources of that particular resource type. A list endpoint URI is of the following form (host and API version prefix not included): - -`/my_resource/` - -A detail endpoint looks like this: - -`/my_resource//` - -where `` is the ID of the resource residing at this endpoint. In cases where an `id` field is specified in the input schema for resource creation, the value of `` will be the `id` of the created resource. Otherwise the ID is generated by Settle. - -A few examples: - -`https://api.settle.eu/merchant/v1/pos/` - -is a list endpoint for POSes. This URI: - -`https://api.settle.eu/merchant/v1/pos/12/` - -is the detail endpoint for the POS with id 12. - -Note that all URLs have a trailing slash by convention. - -URIs returned in Location headers are full URLs. The URIs returned by the API in JSON responses are absolute relative URIs, without server hostname. It's up to you to prepend hostname and protocol. A complete URL looks like this: - -`https://api.settle.eu/merchant/v1/pos/3y987j9o4o23/` - -In this documentation we'll sometimes leave out the version bit: - -`/merchant/v1/` - -when specifying endpoint URLs, for brevity's sake. - -## List endpoints - -List endpoints are associated with a resource class. Unless otherwise specified, a `GET` on a list endpoint will return a list of URIs that point to resources of its particular class, together with a cursor called `next`. The cursor points to the next list endpoint with more resources, and another `next` cursor. And so on. - -```http -GET /merchant/ HTTP/1.1 -HOST: server.test -Accept: application/vnd.mcash.api.merchant.v1+json -``` - -```http -HTTP/1.1 200 OK -Content-Type: application/vnd.mcash.api.merchant.v1+json - -{ - "uris": ["/merchant/abc1/", "/merchant/abc2/", "/merchant/abc3/"], - "next": "/merchant/?next=asDFgh" -} -``` - -## Response status codes - -Listed below are the most common http response status codes and what they mean in the Settle API. - -| **200 OK:** | A successful GET on a list or detail endpoint | -| --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **201 Created:** | A successful POST to a detail endpoint, resulting in the creation of a new resource. The response will have a `Location` header with a URI pointing to the new resource. If Settle identifies a duplicate POST request, which means both the ID chosen by client and data matches that of an earlier request, Settle will not alter the resource but will give the same response with a `Location` header pointing to the original resource. | -| **204 No content:** | A successful PUT (update) or DELETE request. | -| **400 Bad request:** | A malformed request from the client. Typically the schema does not validate for the data supplied in the request body. | -| **404 Not found:** | The status code for all requests to URLs that do not exist. This also includes detail endpoints that resolve to non-existent resources. | -| **405 Method not allowed:** | Not all endpoints support the entire set of HTTP methods. This status code is returned if the client attempts to use an HTTP method that is not supported by a particular endpoint. | -| **409 Conflict:** | A conflicting request by the client. This typically happens when the client tries to create a resource with an ID that already exists, or if it tries to create or update a resource with data that violates a uniqueness constraint on one or more resource fields; generally anytime a resource is being updated in conflicting ways, concurrently. | - -Certain endpoints might return other status codes than those listed here. Special cases are covered in the *[Settle API Reference](https://developer.settle.eu/handlers.html)*. - -## Schema definitions - -All resources in the Settle API are documented in the *[Settle API Reference](https://developer.settle.eu/handlers.html)*, with input and output schemas definitions, with the expected structure of input and output data for the respective API calls. To explain what these schemas mean, let's look at the [`POS creation`](https://developer.settle.eu/handlers.html#post--pos- "POST /pos/") method as an example. This method defines the following input schema: - -### `name` - -String : required - -* length <= 100 -* Data required (new or existing on update) - -Human-readable name of the POS, used for displaying payment request origin to end user. - -### `type` - -String : required - -* length <= 50 -* Value in store, webshop, mobile, vending, poster. -* Data required (new or existing on update). - -POS type. - -### `location` - -[Location](https://developer.settle.eu/types.html#wtforms-fielddoc-handlers-7) : optional : default=null - -Merchant location. - -### `id` - -String : required - -* length <= 100 -* Data required (new or existing on update) - -The ID of the POS that is to be created. Has to be unique for the merchant. - - -The schema is represented as a two-column table where each row represents a field (i.e. a JSON field) in the data format. For each row the right column contains a descriptive text about the field, contains the field name and lists the various constraints that apply to the field. The first line in the left column contains field name, type (e.g. String), whether the field is optional or required, and the default value for optional fields. - -The `location` field of the example schema has a field type (Location) that is linked to another schema definition-- it is a Complex Type. Complex Types can be single-value types with some special behavior, e.g. the [Money](https://developer.settle.eu/types.html#wtforms-fielddoc-oauth_api-0) type; more commonly they have a nested structure like in this example. Clicking the [Location](https://developer.settle.eu/types.html#wtforms-fielddoc-handlers-7) link leads us to the following schema definition. - -| **latitude** : Float : optional : default=null | Latitude | -| ----------------------------------------------- | ------------------- | -| **longitude** : Float : optional : default=null | Longitude | -| **accuracy** : Float : optional : default=null | Accuracy in meters. | - - - -This means that the `location` field is a nested structure composed of three other fields-- latitude, longitude and accuracy-- that together represent geographic coordinates. This is best illustrated with an example JSON object that validates for the POS creation input schema: - -```json -{ - "id": "POS1", - "name": "My first POS", - "type": "store", - "location": { - "latitude": 59.0, - "longitude": 10.0, - "accuracy": 20.0 - } -} diff --git a/docs/api/guides/introduction/ledgers.md b/docs/api/guides/introduction/ledgers.md deleted file mode 100644 index f6f783a..0000000 --- a/docs/api/guides/introduction/ledgers.md +++ /dev/null @@ -1,114 +0,0 @@ ---- -title: Ledgers -description: Ledgers ---- -# Ledgers - -A **ledger** is a log of payment requests and permission requests. How ledgers are used is up to merchants; for instance a webshop may have only a single ledger, while a convenience store may want a ledger per POS or a ledger per employee. See the `ledger` endpoints. A ledger named `default` is always available. - -A (ledger) **report** is a data for a given time period on a ledger. The merchant decides when to close the currently open report on a ledger. E.g., once the merchant closes `/ledger/X435XF2a/report/1/`, `/ledger/X435XF2a/report/2/` is created and becomes the currently open report where new payment requests and permission requests are added. - -The `report` endpoint provides for access to per-transaction and per-permission request logs, as well as summary information and information about money paid out. - -## Report summaries[](https://developer.settle.eu/ledgers.html#report-summaries "Permalink to this headline") - -The `report` endpoint gives summaries for a report on a ledger (for instance, the end-of-day report of a given POS). - -While the summary information includes fees to Settle and a "net" for the transactions contained in a report, this is for information purposes only and these nets are not used further in the settlement procedure. The settlements have their own transaction logs, see the *[Settlements](https://developer.settle.eu/settlements.html#settlement)* section. - -An example result from the [`settlement`](https://developer.settle.eu/handlers.html#get--settlement--settlement_id-- "GET /settlement/\/") endpoint could look like this: - -``` - -``` - -The **fees** list may not contain an entry if its value is `0.00`. The current fees are **transaction_fee**, **interchange** and **scope_fee**, and **scope_fee_vat**, though this list may grow with time. - -The counters simply count up the number of event lines with the corresponding actions in the CSV log files; see the log documentation below. - -In addition to what shown above, **transaction_fee** and **scope_fee** properties will also be returned, but are deprecated and only present for backwards compatibility reasons. - -## Transaction logs[](https://developer.settle.eu/ledgers.html#transaction-logs "Permalink to this headline") - -An example table from the transaction log is given below; it contains three transactions: - -* A transaction where the full amount is captured right away, 7 seconds after initiation. -* A transaction using partial capture to capture 50.00 NOK + 10.00 NOK from additional_amount first, then 50.00 NOK, leaving 50.00 NOK + 5.00 NOK additional amount left in the authorization; the remaining amount is (automatically) released when authorization expires. -* A transaction that is aborted before the customer authorized the request. -* A transaction that fails for some non-merchant related reason (e.g., rejected by the customer, spending limits exceeded, etc.). - -| tid | sub_id | timestamp | action | type | customer | currency | amount | additional_amount | gross | fee | interchange | vat | taxcode | net | merchant_id | settlement_id | -| ------------ | ------- | ------------------- | ------- | ------ | ------------ | -------- | ------ | ----------------- | ------ | ---- | ----------- | ---- | ------- | ------ | ----------- | --------------------- | -| p54daadrsdj4 |   | 2013-09-10 12:00:00 | request |   | token:F_+z/3 | NOK | 200.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |   | 0.00 | acme | 4xrf2z-2014-11-27-342 | -| p54daadrsdj4 |   | 2013-09-10 13:00:07 | auth | credit | token:F_+z/3 | NOK | 200.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |   | 0.00 | acme | 4xrf2z-2014-11-27-342 | -| p54daadrsdj4 |   | 2013-09-10 13:00:07 | capture | credit | token:F_+z/3 | NOK | 200.00 | 0.00 | 200.00 | 1.80 | 0.50 | 0.00 | NO:2013 | 197.70 | acme | 4xrf2z-2014-11-27-342 | -| p8a7sdyfax4d |   | 2013-09-10 13:00:00 | request |   | token:goBlo8 | NOK | 150.00 | 15.00 | 0.00 | 0.00 | 0.00 | 0.00 |   | 0.00 | acme | 4xrf2z-2014-11-27-342 | -| p8a7sdyfax4d |   | 2013-09-10 13:00:07 | auth | credit | token:goBlo8 | NOK | 150.00 | 15.00 | 0.00 | 0.00 | 0.00 | 0.00 |   | 0.00 | acme | 4xrf2z-2014-11-27-342 | -| p8a7sdyfax4d | mycapt1 | 2013-09-10 13:04:04 | capture | credit | token:goBlo8 | NOK | 50.00 | 10.00 | 60.00 | 1.80 | 0.60 | 0.00 | NO:2013 | 57.60 | acme | 4xrf2z-2014-11-27-342 | -| p8a7sdyfax4d |   | 2013-09-10 13:18:42 | auth | credit | token:goBlo8 | NOK | 100.00 | 5.00 | 0.00 | 0.00 | 0.00 | 0.00 |   | 0.00 | acme | 4xrf2z-2014-11-27-342 | -| p8a7sdyfax4d | mycapt2 | 2013-09-10 13:20:37 | capture | credit | token:goBlo8 | NOK | 50.00 | 0.00 | 50.00 | 1.80 | 0.50 | 0.00 | NO:2013 | 47.70 | acme | 4xrf2z-2014-11-27-342 | -| p8a7sdyfax4d |   | 2013-09-13 14:42:17 | release | credit | token:goBlo8 | NOK | 50.00 | 5.00 | 0.00 | 0.00 | 0.00 | 0.00 |   | 0.00 | acme | 4xrf2z-2014-11-27-342 | -| p9g8qrtbnews |   | 2013-09-10 15:35:00 | request |   | token:qtVXn8 | NOK | 350.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |   | 0.00 | acme | 4xrf2z-2014-11-27-342 | -| p9g8qrtbnews |   | 2013-09-10 15:36:00 | abort |   | token:qtVXn8 | NOK | 350.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |   | 0.00 | acme | 4xrf2z-2014-11-27-342 | -| pa4kjhgw65yd |   | 2013-09-10 10:00:40 | request |   | token:34_szQ | NOK | 77.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |   | 0.00 | acme | 4xrf2z-2014-11-27-342 | -| pa4kjhgw65yd |   | 2013-09-10 10:00:49 | fail |   | token:34_szQ | NOK | 77.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |   | 0.00 | acme | 4xrf2z-2014-11-27-342 | - -Note that: - -* Log lines are first sorted lexicographically by `tid`, and then sorted by timestamp within a transaction. Therefore the log as a whole is not sorted by timestamp. -* Within each report, lines grouped by transaction are all put in the same CSV file. -* However, a transaction may re-appear in several reports in the same ledger. E.g., if one first gets auth, then close the currently open report on the ledger, and then captures, the auth and capture will be on separate reports. -* The `amount` and `additional_amount` columns can not be summed, they should be read together with the `status` field and provide information only. The `gross`, `net`, `fee` and `interchange` fields are only set on capture, and so can be summed. -* The `sub_id` field is always set on partial captures. If it is empty, there was a single capture for the full amount. -* The `vat` field will currently always be `0.00` in Norwegian jurisdiction. -* If a transaction is aborted prior to customer response, it will be listed with status `abort`. -* If a transaction is aborted after the customer has authorized the transaction, the status will be `release`. -* If a transaction is aborted or expires after a partial amount has been captured, the remaining amount will be listed with status `release` in the log. -* `settlement_id` has the format `<6 letter settlement series code>--`. The last part (after the 4th dash) is what is used as settlement_id in the API. - -When Settle gives the Merchant a callback about an available report, or accesses the `report` endpoint, the response contains: - -``` - -``` - -The transaction log CSV files can then be downloaded. - -NOTE - -The log URIs are only valid for 30 days after accessing of the endpoint. Access the endpoint again to get updated tokens embedded in the URI that is valid for another 30 days. - -In addition to the table above it contains a number of reserved columns for future use; API users should accept arbitrary data in these columns, but presently no data will be sent. For the table above, the file `myledger_23_154daad.csv` may contain: - -``` - -``` - -While the second part in `myledger_23_1a4kjhg.csv` contains: - -``` - -``` - -## Permission request logs[](https://developer.settle.eu/ledgers.html#permission-request-logs "Permalink to this headline") - -The permission request log is very similar to the transaction log. Again the records are first grouped by the ID and then sorted by timestamp. For a ledger report, a request is first "pending", and then either "ok" or "fail". Note that "ok" means that the customer has answered the request one way or another (it may be a decline to share information), while "fail" is a general failure of the request to be answered (e.g., expiration). - -| rid | timestamp | status | customer | currency | fee | vat | taxcode | -| ------------ | ------------------- | ------- | ------------ | -------- | ---- | ---- | ------- | -| as23rswas5sd | 2013-09-10 13:00:07 | pending | token:F_+z/3 | NOK | 0.00 | 0.00 |   | -| as23rswas5sd | 2013-09-10 13:00:10 | ok | token:F_+z/3 | NOK | 2.00 | 0.50 | NO:2013 | -| a6495av89wcv | 2013-08-10 23:43:45 | pending | token:Q/3+Ys | NOK | 0.00 | 0.00 |   | -| a6495av89wcv | 2013-08-10 23:45:10 | fail | token:Q/3+Ys | NOK | 1.00 | 0.25 | NO:2013 | - -When Settle gives the Merchant a callback about an available report, or accesses the `report` endpoint, the response contains: - -``` - -``` - -As in the earlier case, the log can potentially be split over several CSV files. In the example above, the contents of `31_5s23rsw.csv` would be: - -``` - -``` \ No newline at end of file diff --git a/docs/api/guides/introduction/media-type.md b/docs/api/guides/introduction/media-type.md deleted file mode 100644 index 5ec9a9b..0000000 --- a/docs/api/guides/introduction/media-type.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Media Type -description: Media Type ---- -# Media Type - -This documentation defines the vendor-specific media type - -> application/vnd.mcash.api.merchant.v1+json - -We also use - -> application/vnd.mcash.api.merchant.v1+csv - -for transaction logs, and - -> image/png - -for attachments. In general, the form is - -> application/vnd.mcash.\[attachment-type].\[version]+\[format] - -Clients are expected to include media type in the Accept header listing types they understand; the Settle server responds with the media type in the Content-Type header. \ No newline at end of file diff --git a/docs/api/guides/introduction/payment-flows.md b/docs/api/guides/introduction/payment-flows.md deleted file mode 100644 index 82630e6..0000000 --- a/docs/api/guides/introduction/payment-flows.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: Payment flows -description: Payment flows ---- -# Payment flows - -The Settle Merchant API supports various ways of creating payment flows. Please note that these flows can also be tested with the api-utility.settle.eu. - -## Phone number flow - -![Phone number sequence diagram](/media/phonenumber.png "Phone number sequence diagram") - -Send payment request directly to the customer device when POS have access to customer data (or can easily accept phone number as input from customer). - -1. POS creates local order with unique id. -2. POS creates payment request for customer phone number. -3. Settle pushes payment request to the customer. -4. Settle calls back to POS with outcome. - -**Example:** Vending machine, web-shop, recurring payments - -## Paymentlink flow - -![Paymentlink sequence diagram](/media/paymentlink.png "Paymentlink sequence diagram") - -Create payment request to be claimed by user later. - -1. POS creates local order with unique id. -2. POS creates payment request. -3. POS creates unique Paymentlink QR code. -4. Customer scans QR code. -5. Settle pushes payment request to the customer. -6. Settle calls back to POS with outcome. - -**Example:** Modern cash registers, mobile pos, card terminals, web-shops. - -### Shortlink (reusable) flow - -![Shortlink (reusable) sequence diagram](/media/shortlink-reusable-.png "Shortlink (reusable) sequence diagram") - -Payment request sent when a user interacts with a reusable Shortlink QR code that was created during POS setup. - -1. Setup: POS creates Shortlink. -2. Setup: POS creates Shortlink QR code*. -3. Customer scans reusable Shortlink QR code. -4. Settle calls back to POS with customer identifier. -5. POS creates payment request for customer identifier. -6. Settle pushes payment request to the customer. -7. Settle calls back to POS with outcome. - -\* When a payment request have been resolved (accepted, rejected, or cancelled) the Shortlink can be reused. - -**Example:** POS device without customer facing display, requiring pre-printed QR code. - -### Shortlink (single use) flow - -![Shortlink (single use) sequence diagram](/media/shortlink-single-use-.png "Shortlink (single use) sequence diagram") - -QR created when POS device is turned on or registered. -The local id is passed along by Settle and can be picked up by centralised middleware to understand what POS device and purchase the request originated from. - -Customer scan the QR code, claiming the last Payment Request associated with the Shortlink. When PR have been successful, rejected, or cancelled, the SL is freed up and ready to be associated with a new Payment Request. - -**Example:** Card terminals. \ No newline at end of file diff --git a/docs/api/guides/introduction/permission-requests.md b/docs/api/guides/introduction/permission-requests.md deleted file mode 100644 index acdd268..0000000 --- a/docs/api/guides/introduction/permission-requests.md +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: Permission Requests and OAuth -description: Permission Requests and OAuth ---- -# Permission Requests and OAuth - -A user can authorize a merchant to access various endpoints, typically shipping address or phone number. To enable this in the general case, we use OAuth 2.0. The Settle API also has methods to support this. - -## OAuth terms and Settle[](https://developer.settle.eu/oauth.html#oauth-terms-and-settle "Permalink to this headline") - -The end user or customer is the resource owner, as the resource is typically user data or endpoints for doing something on the users behalf. The authorization server is Settle, who is responsible for checking credentials and handing out tokens after the resource owner authorizes access. The Merchant is the client, who consumes the resource. - -## Application registration[](https://developer.settle.eu/oauth.html#application-registration "Permalink to this headline") - -The Merchant is implicitly a confidential OAuth client for the purposes of Settle API calls, with their Settle merchant_id as the client id. There is no need to register redirect URLs for Settle API usage as the Merchant makes all the calls directly. - -If the Merchant desires to use standard OAuth with redirects, it must register an application in Settle API or in self service portal. This is equivalent to registering a client in OAuth language. This returns a client id and client secret. Those values can be used to set up standard OAuth client libraries, as they are separate from the regular merchant id and authentication. - -## OAuth authorization code grant[](https://developer.settle.eu/oauth.html#oauth-authorization-code-grant "Permalink to this headline") - -When we use regular OAuth, the authorization code grant flow is the default: - -* Client redirects user to authorization server endpoint, where user identifies and approves authorization.  (or similar) -* Authorization server redirects user back to client redirect_uri, with authorization code -* Client exchanges authorization code for access token () using client credentials -* Client accesses protected resource with access token - -## Settle API permission request[](https://developer.settle.eu/oauth.html#settle-api-permission-request "Permalink to this headline") - -In the Settle API, there is an endpoint for requesting authorization [`POST /permission_request/`](https://developer.settle.eu/handlers.html#post--permission_request- "POST /permission_request/"), a direct callback with the access token, and an outcome endpoint [`GET /permission_request//outcome/`](https://developer.settle.eu/handlers.html#get--permission_request--rid--outcome- "GET /permission_request/\/outcome/") for checking the outcome later. As the resource owner does not have to carry tokens, there is no checking of `redirect_uri` and we don't need the authorization code. - -## Making payment requests[](https://developer.settle.eu/oauth.html#making-payment-requests "Permalink to this headline") - -The access token can be used in the `customer` field when making payment requests at [`POST /payment_request/`](https://developer.settle.eu/handlers.html#post--payment_request- "POST /payment_request/"). - -## Scope values[](https://developer.settle.eu/oauth.html#scope-values "Permalink to this headline") - -If not requesting any scopes, the result is an access token that can be used as customer field for a payment request or a permission request. For more info on scopes, check out the specification for the protocol:  - -* openid - - To make a OpenID Connect request for login. NOTE: the `openid` scope is also required in order to access the `address`, `phone`, and `email` scopes, in line with the OAuth2 spec. -* address - - Included in `GET /oauth2/v1/userinfo` -* phone - - Included in `GET /oauth2/v1/userinfo` -* email - - Included in `GET /oauth2/v1/userinfo` -* profile - - Included in `GET /oauth2/v1/userinfo`. Currently this corresponds the claims \['name']. More may be added in the future. See the specification for the openid protocol for more info on this scope.  - -For Norwegian `fodselsnummer`, `shipping_address`, and specific personal id schemes like bankid, the endpoint URI is a little different. - -* shipping_address - - `GET /oauth2/v1/scope/shipping_address` -* verified fodselsnummer for user, listing proofs for jurisdiction - - `GET /oauth2/v1/scope/personal_id/no/id` -* verified fodselsnummer from `BankID`, single entry in proof list - - `GET /oauth2/v1/scope/personal_id/no/bankid` - -## OpenID ID token[](https://developer.settle.eu/oauth.html#openid-id-token "Permalink to this headline") - -When using OpenID connect scopes, an id token is returned alongside the access token. - -An ID Token is a cryptographically-signed JSON object encoded in base 64, represented as a [JSON Web Token (JWT)](http://tools.ietf.org/html/draft-ietf-oauth-json-web-token). - -## Inspiration/background[](https://developer.settle.eu/oauth.html#inspiration-background "Permalink to this headline") - - - - - - - - \ No newline at end of file diff --git a/docs/api/guides/introduction/qr-acceptance.md b/docs/api/guides/introduction/qr-acceptance.md deleted file mode 100644 index 691253a..0000000 --- a/docs/api/guides/introduction/qr-acceptance.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: QR Acceptance -description: QR Acceptance ---- -# QR Acceptance - -When a user accesses a webshop through a browser on their phone, they obviously cannot use the phone to scan a QR code in order to pay with Settle! (Except via some sort of elaborate mirror setup... Perhaps Settle should go into hardware!) Thus we provide a JavaScript library that can be found here - - - -Using that library, either a QR code can be displayed (when on a desktop) or a button (when on a smartphone). When on a mobile browser, the button will start the Settle app and do the equivalent of scanning the QR code. \ No newline at end of file diff --git a/docs/api/guides/introduction/resiliency.md b/docs/api/guides/introduction/resiliency.md deleted file mode 100644 index b398c5f..0000000 --- a/docs/api/guides/introduction/resiliency.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: A resilient payment system -description: A resilient payment system ---- -# A resilient payment system - -The hardware and database architecture of Settle has some characteristics that it is very important for API client implementors to be aware of. The advantage of this architecture is that Settle is very resilient against the failure of individual servers or network connections. The flip side of the coin is that the return of a HTTP 5xx response code (most often 500 or 503) is more common than with more traditional system that runs on only a few machines which are assumed to not fail. - -A 5xx error normally does not indicate that something is wrong. It simply indicates that the API client should try again. This behaviour is fully expected, and the API is carefully designed to make sure retrying works in all cases. \ No newline at end of file diff --git a/docs/api/guides/introduction/sandbox-environment.md b/docs/api/guides/introduction/sandbox-environment.md deleted file mode 100644 index f4b98eb..0000000 --- a/docs/api/guides/introduction/sandbox-environment.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: Sandbox Environment -description: How to get access to the Sandbox ---- - -# Overview - -The Settle Sandbox allows for exploration of Settle products and features. It is a replica of the Settle production environment, but money in this environment is not real. There may be other things that are also different, for example features enabled or disabled for easier access, such as being open to all Euro markets, or upcoming features being enabled for early beta testing by third party developers - -::: tip -Please note that cross border payments have not yet been activated for the Sandbox, so users and businesses need to be created for the same country in order to interact. -::: - -## Settle Consumer App - -While the production version is available to anyone through the App store and Playstore, the sandbox version is more exclusive since we are not allowed to publish “fake” apps. - -When the app is downloaded, the following fake card can be added for an infinite amount of funds, number: 4111 1111 1111 1111, expiry: 12/23. - -- The Android app is available at [play.google.com/apps/testing/eu.settle.app.sandbox](https://play.google.com/apps/testing/eu.settle.app.sandbox) -- The iOS sandbox app is available at .\ - It will help users first install the required Testflight app from Apple, if not already installed. - -## Settle Business portal - -The Sandbox Business portal is always available at [business.sandbox.settle.eu](https://business.sandbox.settle.eu). - -Please note that while no real documentation has to be provided during the registration, data input such as organisation number may still need to be formatted properly according to local convention. - -## Settle API - -Documentation can be found att [developer.settle.eu](https://developer.settle.eu) and the Sandbox API itself is available at [api.sandbox.settle.eu](https://api.sandbox.settle.eu) - -## Credentials - -Credentials for API access can be generated for each Shop (Merchant) in the [Business Portal](https://business.sandbox.settle.eu). A detailed overview for authentication and the various access levels can be found in the [developer documentation](https://developer.settle.eu/authentication.html).![](https://lh3.googleusercontent.com/QUsxfzdvpnt5LHhCNHaSXLqohVT9AYSfQqXlVDD8uke2Pswnhm3QUgxZkNQ0Dpk1dcWDS0kC2RDHeHAsUBv_qsYkXWKh_gRHVVimSUcnP8pAGoV0aE1N-aoe9g8Yq2BS_L479L9k) - -## Contact - -Please send questions, comments and feedback to [support@settle.eu](mailto:support@settle.eu). diff --git a/docs/api/guides/introduction/settle-sandbox-environment.md b/docs/api/guides/introduction/settle-sandbox-environment.md deleted file mode 100644 index f7f47de..0000000 --- a/docs/api/guides/introduction/settle-sandbox-environment.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Settle Sandbox Environment -description: Settle Sandbox Environment ---- - \ No newline at end of file diff --git a/docs/api/guides/introduction/settlements.md b/docs/api/guides/introduction/settlements.md deleted file mode 100644 index 9df3346..0000000 --- a/docs/api/guides/introduction/settlements.md +++ /dev/null @@ -1,98 +0,0 @@ ---- -title: Settlements -description: Settlements ---- -# Settlements - -A **settlement** is when Settle settles transactions and fees with the merchant (transfers out money and bills for services). This usually happens every week day. The details of which transactions and fees are included in each settlement depends on the specific agreement Settle has with the merchant, and there is no direct link between a settlement and ledgers except for transaction IDs and permission request IDs being the same. - -While there is no direct relation between settlement and ledger reports, the downloadable CSV files have the same format. - -The [`settlement`](https://developer.settle.eu/handlers.html#get--settlement--settlement_id-- "GET /settlement/\/") endpoint provides for access to per-transaction and per-permission request logs, as well as summary information and information about money paid out. - -## Summaries - -An example result from the [`settlement`](https://developer.settle.eu/handlers.html#get--settlement--settlement_id-- "GET /settlement/\/") endpoint could look like this: - -```json -{ - "id": "23", - "date_created": "2013-10-09 08:00:02", - "settlement_summary": [ - { - "taxcode": "NO:2013", - "currency": "NOK", - "gross": "12000.00", - "settlement_fee": "15.00", - "fees" : [ - {"type": "settlement_fee", "amount": "15.00"}, - {"type": "settlement_fee_vat", "amount": "0.00"}, - {"type": "transaction_fee", "amount": "120.00"}, - {"type": "interchange", "amount": "150.00"}, - {"type": "scope_fee", "amount": "32.00"}, - {"type": "scope_fee_vat", "amount": "8.00"} - ], - "net": "11675.00" - } - ], - "payout_details": [ - { - "currency": "NOK", - "unsettled_fees_before": "0.00", - "unsettled_fees_after": "0.00", - "payout": "11675.00", - "billed": "0.00", - "invoice_id": null, - "net": "11675.00", - "gross": "12000.00" - } - ], - "transaction_log_uris": [ - "https://sandbox.settle.eu/_download/4JD+343/transaction_43_154daad.csv", - "https://sandbox.settle.eu/_download/4JD+343/transaction_43_1a4kjhg.csv"], - "scope_log_uris": [ - "https://sandbox.settle.eu/_download/4JD+343/scope_43_154daad.csv", - "https://sandbox.settle.eu/_download/4JD+343/scope_43_1a4kjhg.csv"], -} -``` - -The **fees** list may not contain an entry if its value is `0.00`. The current fees are **transaction_fee**, **interchange** and **scope_fee**, and **scope_fee_vat**, though this list may grow with time. - -Note that **settlement_summary** is a list. This is because if the settlement spans transactions over several currencies or jurisdictions, there will be a separate summary for each relevant combination of **currency** and **taxcode**. This feature will be described in further detail when Settle launches support for multiple currencies. - -In addition to what shown above, **transaction_fee** and **scope_fee** properties will also be returned, but are deprecated and only present for backwards compatibility reasons. - -## Detailed logs - -The logs offered for download in **transaction_log_uris** and **scope_log_uris** have the same basic format as the logs described in the *[Ledgers](https://developer.settle.eu/ledgers.html#ledgers)* section. However, only lines that affect the settlement are included, that is, lines with non-zero **gross** and/or **fee**. - -An example settlement transaction log would be: - -``` -tid,sub_id,timestamp,action,type,customer,currency,amount,additional_amount,gross,fee,interchange,vat,taxcode,net,merchant_id,settlement_id,reserved1,reserved2 -p54daadrsdj4,,2013-09-10 13:00:07,capture,credit,token:F_+z/3,NOK,200.00,0.00,200.00,1.80,0.50,0.00,NO:2013,197.70,acme,4xrf2z-2014-11-27-342,, -p8a7sdyfax4d,mycapt1,2013-09-10 13:04:04,capture,credit,token:goBlo8,NOK,50.00,10.00,60.00,1.80,0.60,0.00,NO:2013,57.60,acme,4xrf2z-2014-11-27-342,, -p8a7sdyfax4d,mycapt2,2013-09-10 13:20:37,capture,credit,token:goBlo8,NOK,50.00,0.00,50.00,1.80,0.50,0.00,NO:2013,47.70,acme,4xrf2z-2014-11-27-342,, -``` - -While a settlement scope (permission request) log would be: - -``` -rid,timestamp,status,customer,currency,fee,vat,taxcode,merchant_id,settlement_id,reserved1,reserved2,reserved3 -as23rswas5sd,2013-09-10 13:00:10,ok,token:F_+z/3,NOK,1.80,0.50,NO:2013,acme,4xrf2z-2014-11-27-342,,, -a6495av89wcv,2013-08-10 23:45:10,fail,token:Q/3+Ys,NOK,1.00,0.25,NO:2013,acme,4xrf2z-2014-11-27-342,,, -``` - -## VAT rules - -Every transaction or permission request has an associated Settle-specific `taxcode`, which is a tag to specify the tax laws that apply to the transaction or permission request. - -::: tip INFO -We change the tax code whenever the rules actually change. While `NO:2013` reflect the law of Norway in 2013, we will keep that code until such a time that the tax rate is changed, not change it every year. -::: - -The current table of tax codes is: - -| taxcode | VAT on permission request fees | VAT on transaction fees | -| ------- | ------------------------------ | ----------------------- | -| NO:2013 | 25% | 0% | \ No newline at end of file diff --git a/docs/api/guides/introduction/versioning.md b/docs/api/guides/introduction/versioning.md deleted file mode 100644 index db8f29c..0000000 --- a/docs/api/guides/introduction/versioning.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Versioning -description: Versioning ---- -# Versioning - -The current major version of the API is v1. Changes within a major version will always be backwards-compatible. New major versions may or may not be backwards compatible with the previous major version. Users will always be duly notified when we bump the major version, and of any changes that might affect backwards-compatibility. You can also refer to the changelog for the most recent updates to the API. \ No newline at end of file diff --git a/docs/api/guides/quickstarts/node.md b/docs/api/guides/quickstarts/node.md deleted file mode 100644 index 61770eb..0000000 --- a/docs/api/guides/quickstarts/node.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -pageClass: guides-sidebar -title: Node.js -description: Node.js ---- -# Node.js \ No newline at end of file diff --git a/docs/api/guides/quickstarts/python.md b/docs/api/guides/quickstarts/python.md deleted file mode 100644 index 23a32aa..0000000 --- a/docs/api/guides/quickstarts/python.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -pageClass: guides-sidebar -title: Python -description: Python ---- -# Python \ No newline at end of file diff --git a/docs/api/guides/tutorials/implementation-and-integration/pos-with-dynamic-qr/index.md b/docs/api/guides/tutorials/implementation-and-integration/pos-with-dynamic-qr/index.md deleted file mode 100644 index 2761953..0000000 --- a/docs/api/guides/tutorials/implementation-and-integration/pos-with-dynamic-qr/index.md +++ /dev/null @@ -1,186 +0,0 @@ ---- -title: POS with dynamic QR -description: Coffee shop POS integration with dynamic QR ---- -# Coffee shop POS integration - -**In this tutorial, *the merchant* we will integrate is a coffee shop that uses a mobile point of sale system which allows their staff to accept payments at customers' tables. They accept cash, card and Settle.** - -When a client wishes to pay with Settle, the POS generates a QR code for the customer to scan, which is used by the POS vendor to initiate a payment request. - -### 1. Generating the QR code - -The POS generates and displays a QR code which contains the **shortlink ID** and a **transaction ID** generated by the vendor's backend system. - -Settle expects a scanned QR code to contain a specific URL: - -``` -http://settle.eu/s// -``` - -Note that *http://settle.eu/s//* is mandatory, the rest of the URL (*vendors_transaction_id*) will be sent to the callback handler. - -### 2. QR code scan - -When the customer scans the QR code and the scan is registered by Settle, Settle generates a unique *[scan token](https://developer.settle.eu/callbacks.html#callbacks-shortlink)* which can be used by the vendor's backend system to initiate a payment request. - -### 3. Callback - -Settle calls the vendor's specified *callback_uri*, passing in the *scan token* which can be used to create a payment request. The 'extra' information encoded in the QR code (*vendors_transaction_id* in this example) is also present in the payload. - -The following is an example of the payload that would be sent to the vendor's backend when a QR code containing `http://settle.eu/s//` is scanned: - -```json -{ - "meta": { - "seqno": 0, - "labels": [ - - ], - "uri": null, - "id": "D5S6WYjnQ_ObT-DyZfrVPA", - "context": "ctx:D5S6WYjnQ_ObT-DyZfrVPA", - "timestamp": "2019-03-21 08:58:49", - "event": "shortlink_scanned" - }, - "object": { - "id": "token:5632006343884800", - "argstring": "vendors_transaction_id" - } -} -``` - -The *scan token* for this scan is `token:5632006343884800`. - -### 4. Payment request - -The vendor initiates a [`payment request`](https://developer.settle.eu/handlers.html#post--payment_request- "POST /payment_request/") using the *[scan token](https://developer.settle.eu/callbacks.html#callbacks-shortlink)* that Settle generated as the value in the `customer` field. - -Example payment request for €20, using the *scan token* from the previous section: - -```json -// POST https://api.settle.demo/merchant/v1/payment_request/ - -{ - "action": "SALE", - "allow_credit": true, - "pos_tid": "vendors_transaction_id", - "pos_id": "id-of-the-pos", - "customer": "token:5632006343884800", - "currency": "EUR", - "amount": 2000 -} -``` - -Example response: - -```json -{ - "id": "p2ybyw4tq73n", - "uri": null -} -``` - -Note that the `id` field in the response is Settle's **transaction id** (`tid`), which is used to identify the payment in future API calls. - -After creating the payment request, the vendor should poll the [`payment outcome`](https://developer.settle.eu/handlers.html#get--payment_request--tid--outcome- "GET /payment_request/\/outcome/") endpoint, and monitor status changes. A newly created payment request will have `status_code` set to *1003 (PENDING)*. - -Example outcome with status *1003 (PENDING)*: - -```json -{ - "meta": { - "seqno": 0, - "labels": [ - - ], - "uri": null, - "id": "D5S6WYjnQ_ObT-DyZfrVPA", - "context": "ctx:D5S6WYjnQ_ObT-DyZfrVPA", - "timestamp": "2019-03-21 08:58:49", - "event": "shortlink_scanned" - }, - "object": { - "id": "token:5632006343884800", - "argstring": "vendors_transaction_id" - } -} -``` - -### 5. Payment confirmation - -A message appears on the customer's phone asking them to confirm the payment. - -If the user confirms the payment, the `status_code` returned from the [`payment outcome`](https://developer.settle.eu/handlers.html#get--payment_request--tid--outcome- "GET /payment_request/\/outcome/") endpoint changes to *3008 (AUTH)*: - -```json -// POST https://api.settle.demo/merchant/v1/payment_request/ - -{ - "action": "SALE", - "allow_credit": true, - "pos_tid": "vendors_transaction_id", - "pos_id": "id-of-the-pos", - "customer": "token:5632006343884800", - "currency": "EUR", - "amount": 2000 -} -``` - -Note that `auth_amount` changed from `0` to `2000`. - -If the user chooses to reject the payment, `status_code` changes to *5006 (REJECTED)*. - -### 6. Waiting for authorization - -As soon as the customer confirms the payment in their app, Settle will attempt to authorize the payment. When `status_code` changes to *3008 (AUTH)*, the payment can be captured. - -### 7. Capturing the payment - -The vendor captures the payment using the [`PUT /payment_request//`](https://developer.settle.eu/handlers.html#put--payment_request--tid-- "PUT /payment_request/\/") endpoint, sending in `{action: "capture"}`: - -```json -{ - "id": "p2ybyw4tq73n", - "uri": null -} -``` - -Note that the payment must be authorized before capture is possible; it is an error to try to capture a payment that does not have `status_code` *3008 (AUTH)*. - -### 8. Verifying the capture - -Again, polling the [`payment outcome`](https://developer.settle.eu/handlers.html#get--payment_request--tid--outcome- "GET /payment_request/\/outcome/"), the vendor can check the payment's `status_code` to see whether it succeeded. *2000 (OK)* means that the payment is captured and has been transferred to the merchant: - -```json -// GET https://api.settle.demo/merchant/v1/payment_request/p2ybyw4tq73n/outcome/ - -{ - "status": "pending", - "customer": "token:5632006343884800", - "attachment_uri": , - "pos_tid": "vendors_transaction_id", - "refunds": [ - - ], - "auth_amount": 0, - "auth_additional_amount": 0, - "captures": [ - - ], - "date_modified": "2019-03-21 08:58:49", - "date_expires": "2019-03-26 08:59:07", - "credit": false, - "amount": 2000, - "interchange_fee": 0, - "status_code": 1003, - "tid": "p2ybyw4tq73n", - "pos_id": "id-of-the-pos", - "currency": "EUR", - "additional_amount": 0, - "transaction_fee": 0, - "permissions": null -} -``` - -For a full list of status codes, see the [outcome documentation](https://developer.settle.eu/handlers.html#outcome). \ No newline at end of file diff --git a/docs/api/guides/tutorials/implementation-and-integration/pos-with-static-qr/index.md b/docs/api/guides/tutorials/implementation-and-integration/pos-with-static-qr/index.md deleted file mode 100644 index 9fd7ef8..0000000 --- a/docs/api/guides/tutorials/implementation-and-integration/pos-with-static-qr/index.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: POS with static QR -description: POS with static QR ---- -# Implement a POS with static QR - -When using a POS with a static QR, the QR code can be scanned before or after the POS is ready for submitting the payment request. The POS should submit a payment request ([`POST /payment_request/`](https://developer.settle.eu/handlers.html#post--payment_request- "POST /payment_request/")) passing in the QR "shortlink ID" or QR serial number as the `customer`. Settle will then match with the customer who scans the QR. - -The default behaviour is to match the last scan in a 60 second timeframe before the scan happens, and to keep listening for scans until the payment request is either picked up, or aborted. - -If feasible in the POS code, one will get optimal results if the POS also passes `max_scan_age`. This should be set to the number of seconds since the previous payment done at the same POS (**with any payment instruments, not only Settle!!**); this will naturally cause the scan to match the "current customer" in line at the POS, but not somebody who scanned earlier. In the example below, 341 - -If the POS does not know the time that has passed since the previous purchase, it is better to let Settle control `max_scan_age` and not set it. - -Example data to [`POST /payment_request/`](https://developer.settle.eu/handlers.html#post--payment_request- "POST /payment_request/"): - -```json -{ - "customer": "shortlink_sn:0123456789012", - "max_scan_age": 341, -} -``` - -## Checklist - -* Pass `shortlink_sn:` or `shortlink_id:` as `customer` -* If the customer changes his/her mind and wants another payment method, the POS should abort the payment request (by calling [`PUT /payment_request//`](https://developer.settle.eu/handlers.html#put--payment_request--tid-- "PUT /payment_request/\/")). -* If the POS knows the time of the previous payment, pass the number of seconds as `max_scan_age`. Otherwise pass nothing. -* Previous purchase in previous point means *any* previous purchase, not only Settle payments. - -::: tip NOTE -If you receive printed QR codes from Settle with serial number, you may pass e.g. `shortlink_sn:0123456789012`. If you generate QR codes yourself using [`POST /shortlink/`](https://developer.settle.eu/handlers.html#post--shortlink- "POST /shortlink/"), pass e.g. `shortlink_id:3XfZA`. -::: \ No newline at end of file diff --git a/docs/api/guides/tutorials/index.md b/docs/api/guides/tutorials/index.md deleted file mode 100644 index c49e41d..0000000 --- a/docs/api/guides/tutorials/index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Tutorials -description: Tutorials ---- -Lorem ipsum \ No newline at end of file diff --git a/docs/api/guides/tutorials/permission-requests-and-oauth/oauth2/index.md b/docs/api/guides/tutorials/permission-requests-and-oauth/oauth2/index.md deleted file mode 100644 index c0b616e..0000000 --- a/docs/api/guides/tutorials/permission-requests-and-oauth/oauth2/index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: OAuth2 -description: OAuth2 -permalink: /:slug ---- -## OAuth2 \ No newline at end of file diff --git a/docs/api/guides/tutorials/permission-requests-and-oauth/permission-requests/index.md b/docs/api/guides/tutorials/permission-requests-and-oauth/permission-requests/index.md deleted file mode 100644 index 55c3b40..0000000 --- a/docs/api/guides/tutorials/permission-requests-and-oauth/permission-requests/index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Permission Requests -description: Permission Requests -permalink: /:slug ---- -## Permission Requests \ No newline at end of file diff --git a/docs/api/guides/tutorials/send-and-receive-payments/request-payment/index.md b/docs/api/guides/tutorials/send-and-receive-payments/request-payment/index.md deleted file mode 100644 index 0e818dc..0000000 --- a/docs/api/guides/tutorials/send-and-receive-payments/request-payment/index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Request Payment -description: Request Payment -permalink: /:slug ---- -## Request Payment \ No newline at end of file diff --git a/docs/api/guides/tutorials/send-and-receive-payments/send-payment/index.md b/docs/api/guides/tutorials/send-and-receive-payments/send-payment/index.md deleted file mode 100644 index 29f6034..0000000 --- a/docs/api/guides/tutorials/send-and-receive-payments/send-payment/index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Send Payment -description: Send Payment -permalink: /:slug ---- -## Send Payment \ No newline at end of file diff --git a/docs/api/reference/index.md b/docs/api/reference/index.md index 42385b1..10e7d4a 100644 --- a/docs/api/reference/index.md +++ b/docs/api/reference/index.md @@ -1 +1,4 @@ +--- +home: true +--- diff --git a/docs/api/reference/rest/v1/merchant.settlement/list.md b/docs/api/reference/rest/v1/merchant.settlement/list.md new file mode 100644 index 0000000..90fdf2e --- /dev/null +++ b/docs/api/reference/rest/v1/merchant.settlement/list.md @@ -0,0 +1,12 @@ +--- +layout: SpecialLayout +title: merchant.settlement.list +description: Endpoint description... +api: merchant +schema: merchant.settlement +operationId: merchant.settlement.list +operation: get +method: get +authLevel: SECRET +authRoles: Any +--- \ No newline at end of file diff --git a/docs/api/reference/rest/v1/merchant.shortlink/index.md b/docs/api/reference/rest/v1/merchant.shortlink/index.md index a523854..0853fad 100644 --- a/docs/api/reference/rest/v1/merchant.shortlink/index.md +++ b/docs/api/reference/rest/v1/merchant.shortlink/index.md @@ -1,19 +1,21 @@ --- layout: ResourceOverview title: merchant.shortlink -description: Overview +description: Description... schema: merchant.shortlink api: merchant +resourceDesc: true --- -## Shortlink Scan Handler +::: slot resource +### Shortlink Scan Handler When user scans, Settle sends scan id and argstring, and can receive text and uri which can be transported back to the app. Uri will be opened in a web view inside the app if registered in list of trusted domains.

    - POST http://merchant.server/callback/url + POST https://merchant.server/callback/url

    @@ -41,12 +43,14 @@ The string that was appended to the shortlink value in the QR code that was scan -## Trusted Domains +### Trusted Domains Because of security considerations when opening external URIs inside the Settle App, URIs or domains that will be opened in the app needs to be preapproved by Settle. There are currently no API endpoints for managing trusted domains, please contact Settle support to register domain that should be visible inside app. -## Shortlink Management +### Shortlink Management + +To be able to receive scans, one must first [register a shortlink](/api/reference/rest/v1/merchant.shortlink/create/). +::: -To be able to receive scans, one must first register a shortlink. diff --git a/docs/api/samples/index.md b/docs/api/samples/index.md deleted file mode 100644 index e69de29..0000000 diff --git a/docs/api/support/index.md b/docs/api/support/index.md deleted file mode 100644 index 11d25f1..0000000 --- a/docs/api/support/index.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -next: false -title: How to get help -description: How to get help ---- - -# How to get help - -We use a mixture of different platforms to provide support to developers, so review the options below to determine the best way to get help. - -::: tip NOTE -These channels should only be used for developer issues. Feedback about the core product should be submitted via the **Feedback** or **Report a problem** links in the product user interface. -::: - -## Questions and advice -We use the popular programming Q&A website [Stack Overflow](https://stackoverflow.com/questions/tagged/settle-api) to field technical questions. The site is not run by Settle, but you can ... - -Stack Overflow contains questions on a variety of topics, and developers use the tag [`[settle-api]`](https://stackoverflow.com/questions/tagged/settle-api) to mark questions relevant to this service. You might want to add additional tags to your question to attract the attention of experts in related technologies. - -Before posting a new question for the first time, please take a moment to read through the [Stack Overflow Tour](https://stackoverflow.com/tour). The site and its community have guidelines and tips that you should follow to help ensure your question is answered. - -## Problems & errors - -If you're encountering an error with the API, you should start by searching or posting to Stack Overflow as mentioned above. Try to isolate the problem as much as possible and post only the relevant sections of code. - -## Bugs - -If after you've tried the above options and you have determined that the cause of a problem is due to a bug in the service itself, you can search our [Issue Tracker]() to determine if it is a known issue. If it is, you can star the issue (click the star next to the issue number) — we prioritize bugs that receive more stars. You can also add comments to existing issues, but you should only do this if you are adding context or additional information about the problem. - -If the issue is completely new, you can [report it on our Issue Tracker]() as well. If you do, please ensure you include the following information in your bug description: - -- A description of the problem, and the behavior you expected instead. -- A list of steps and a small snippet of sample code that can be used to reproduce the problem. -- A description of the output you expect and what actually occurred. Include any error messages you receive. -- Information about your development environment, including programming language, library versions, etc. - -Be aware that issues may be relatively quiet for a while. This does not mean we will never fix an issue; it just means that there are currently no updates. - -## Missing features - -If there is a feature or functionality missing that you would like to use, you can [search our Issue Tracker]() to determine if others have requested it. If it has already been requested, please star the issue (click the star next to the issue number) — we prioritize bugs that receive more stars. You can also add comments to existing issues, but you should only do this if you are adding context or additional information about the problem. - -If the feature hasn't been requested yet, you can [file a feature request on our Issue Tracker](). Please describe the specific functionality you would like to see added, as well as reasons you think it's important. If possible, include specific details about your use case and the new opportunities the feature would allow for. diff --git a/docs/discovery/index.md b/docs/discovery/index.md deleted file mode 100644 index f26c921..0000000 --- a/docs/discovery/index.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Settles API Discovery Service -description: Programmatically read metadata about Settle APIs. ---- - -## Settles API Discovery Service - -Use the Settle API Discovery Service to build client libraries, IDE plugins, and other tools that interact with Settle APIs. The Discovery API provides a list of Settle APIs and a machine-readable **"Discovery Document"** for each API. Features of the Discovery API: - -- A **directory** of supported APIs schemas based on [JSON Schema](https://json-schema.org/). -- A machine-readable **"Discovery Document"** for each of the supported APIs. Each document contains: - - A list of API methods and available parameters for each method. - - A list of available OAuth 2.0 scopes. - - Inline documentation of methods, parameters, and available parameter values. - -## Who is using it? - -### Settle has built several tools using the service: - -- [Settle API Client Libraries](): Client libraries in various languages for accessing Settle APIs. -- [Settle APIs Explorer](): An interactive web-based tool for exploring Settle APIs. diff --git a/docs/discovery/v1/guides/getting-started.md b/docs/discovery/v1/guides/getting-started.md deleted file mode 100644 index c891dfe..0000000 --- a/docs/discovery/v1/guides/getting-started.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Getting Started -description: Get started with the Settle Discovery API. ---- - -# Introduction - -The Discovery API provides a list of Settle APIs for retrieving a machine-readable "Discovery document" metadata for each API. - -This document is intended for developers who want to write client libraries, IDE plugins, and other tools for interacting with Settle APIs. - -## Discovery Service Background - -### Concepts - -The Settle APIs Discovery Service is built upon two basic concepts: - -- **APIs Directory:** A list of all APIs that are supported by the APIs Discovery Service. Each directory entry shows details about a supported API, including its name, a brief description of what it does, and a documentation link. An API can have multiple Directory entries, one for each of its supported versions. -- **Discovery document:** A machine-readable description of a particular API. The Discovery document describes the surface for a particular version of an API. The document provides details on how to access the various methods of each API via RESTful HTTP calls. A Discovery document includes descriptions of the data and methods associated with the API, as well as information about available OAuth scopes, and descriptions of schemas, methods, parameters and available parameter values. - -### Data model - -A resource is an individual data entity with a unique identifier. The Settle APIs Discovery Service operates on two types of resources, based on the above concepts. - -**APIs Directory List:** A list of APIs - -Each directory entry contains an API name/version pair with the following information: diff --git a/docs/discovery/v1/reference/apis/index.md b/docs/discovery/v1/reference/apis/index.md deleted file mode 100644 index 90ef579..0000000 --- a/docs/discovery/v1/reference/apis/index.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: Discovery Document -description: Discovery documents are available for specific versions of most APIs. Each API's Discovery Document describes the surface of the API, how to access the API and how API requests and responses are structured. The information provided by the discovery document includes API-level properties such as an API description, resource schemas, authentication scopes, and methods. ---- - -# Discovery Document - -{{$description}} - -## Methods - -The Discovery document focuses on the RESTful method of invoking an API. The [discovery.apis.list](list/) method returns the list of all APIs supported by the Google APIs Discovery Service including the urls for retrieving the REST-based discovery documents. diff --git a/docs/discovery/v1/reference/apis/list.md b/docs/discovery/v1/reference/apis/list.md deleted file mode 100644 index 55de9f5..0000000 --- a/docs/discovery/v1/reference/apis/list.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: 'Discovery Document: list' -description: Retrieve the list of APIs supported at this endpoint. ---- - -# Discovery Document: list - -{{$description}} - -The `discovery.apis.list` method returns the list of all APIs supported by the Settle APIs Discovery Service. The data for each entry is a subset of the Discovery Document for that API, and the list provides a directory of supported APIs. If a specific API has multiple versions, each of the versions has its own entry in the list. - -## HTTP Request - -
    - -
    - -GET https://api.settle.eu/discovery/v1/apis - -
    - -
    - -# Request Body - -Do not supply a request body with this method. - -# Response - -If successful, this method returns a response body with the following structure: diff --git a/docs/discovery/v1/reference/index.md b/docs/discovery/v1/reference/index.md deleted file mode 100644 index 6cb1b59..0000000 --- a/docs/discovery/v1/reference/index.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: API Reference -description: Settle API Discovery Service ---- - -## API Reference - -### Discovery Document - -For Discovery Document Resource details, see the [resource representation](/discovery/v1/reference/apis/) page. - -| Method | REST URI * | Description | -|:-------------------------------------------|:-----------|:------------------------------------------------------| -| [list](/discovery/v1/reference/apis/list/) | GET /apis | Retrieve the list of APIs supported at this endpoint. | - -**Relative to the base URI: https://api.settle.eu/discovery/v1/apis* \ No newline at end of file diff --git a/docs/index.md b/docs/index.md index c21a194..d443374 100644 --- a/docs/index.md +++ b/docs/index.md @@ -1,19 +1,4 @@ --- -home: true -heroImage: /media/people-3x.png -heroText: Settle ❤️ Developers -tagline: Get to know our APIs! -actionText: Come play with us -actionLink: /api/guides/ -features: - - title: Get Started - details: "Read a technical overview of this product. " - url: /api/guides/ - - title: Reference documentation - details: Examine all of this API's resources and methods. - url: /api/reference/ - - title: Top Tasks - details: Examine the most popular developer tasks for this API. - url: / -footer: MIT Licensed | Copyright © 2010-present Settle Group +home: false --- + diff --git a/docs/sandbox/index.md b/docs/sandbox/index.md deleted file mode 100644 index 02cadcf..0000000 --- a/docs/sandbox/index.md +++ /dev/null @@ -1 +0,0 @@ - diff --git a/docs/terms/api-services-user-data-policy.md b/docs/terms/api-services-user-data-policy.md deleted file mode 100644 index e69de29..0000000 diff --git a/docs/terms/index.md b/docs/terms/index.md deleted file mode 100644 index e69de29..0000000 diff --git a/docs/terms/site-policies.md b/docs/terms/site-policies.md deleted file mode 100644 index e69de29..0000000 diff --git a/docs/terms/site-terms.md b/docs/terms/site-terms.md deleted file mode 100644 index e69de29..0000000 From 202abecc793cbfc901002071b26e090e3ac47d51 Mon Sep 17 00:00:00 2001 From: Wick Date: Mon, 4 Oct 2021 13:02:11 +0200 Subject: [PATCH 06/10] Remove all but API Reference pages --- .idea/workspace.xml | 104 ++++++++++++++ docs/api/guides/index.md | 11 -- .../api/guides/introduction/authentication.md | 134 ----------------- docs/api/guides/introduction/interacting.md | 136 ------------------ 4 files changed, 104 insertions(+), 281 deletions(-) create mode 100644 .idea/workspace.xml delete mode 100644 docs/api/guides/index.md delete mode 100644 docs/api/guides/introduction/authentication.md delete mode 100644 docs/api/guides/introduction/interacting.md diff --git a/.idea/workspace.xml b/.idea/workspace.xml new file mode 100644 index 0000000..388c62c --- /dev/null +++ b/.idea/workspace.xml @@ -0,0 +1,104 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 1625771504616 + + + 1633344889235 + + + + + + + + + + + + +