GST Suvidha Provider - Instavatinsta.instavat.in/PDF/Eco-SystemforGSTandGSTSuvidhaProviders.pdf ·...

Goods and Services Tax Network (GSTN)

GST Eco-System &

GST Suvidha Provider (GSP)

Corporate Office: 4th Floor, East Wing, World Mark 1, Aero City, New Delhi 110037.

GST Suvidha Provider

1

Contents Acronyms ......................................................................................................................................................................... 2

1. INTRODUCTION .................................................................................................................................................... 3

1.1 Introduction to GST System .............................................................................................................................. 3

1.2 Introduction to GSTN ........................................................................................................................................ 3

1.3 Role of third party developed applications ....................................................................................................... 4

2. GST SYSTEM ........................................................................................................................................................... 6

2.1 Design Consideration for GST system ............................................................................................................... 6

2.1.1 Ecosystem Approach .......................................................................................................................................... 6

2.4 API Approach ...................................................................................................................................................... 8

2.4.1 Security & Privacy ............................................................................................................................................. 10

2.4.2 Configurability .............................................................................................................................................. 10

2.4.3 Data Distribution Service .............................................................................................................................. 11

2.5 Advantage of the API based Approach ............................................................................................................. 11

3. GST SYSTEM ARCHITECTURE PRINCIPLES .................................................................................................... 13

4. HIGH LEVEL ARCHITECTURE OF GST SYSTEM ............................................................................................. 15

4.1 Architecture Overview ....................................................................................................................................... 15

4.2 GST System accessibility through Ecosystem .................................................................................................. 16

5. API FRAMEWORK FOR GST SYSTEM ................................................................................................................18

5.1 Set up, Operationalize and Maintain Systems and Process for APIs ............................................................. 19

5.2 API Metering ..................................................................................................................................................... 24

5.3 Data Integrity .................................................................................................................................................... 25

API List .......................................................................................................................................................................... 28


2

Acronyms

Item Description

API Application Program Interface

BPM Business Process Management

CBEC Central Board of Excise and Customs

CGST Central Goods and Service Tax

DDS Distributed Data Service

ETL Extract Transform and Load

GST Goods and Services Tax

GSTN Goods and Services Tax Network

GSTIN Goods and Services Tax identification Number

GSP GST Suvidha Provider

IGST Inter State Goods and Service tax

IPsec Internet Protocol Security

MIS Management Information System

MSP Managed Service provider ( Selected by GSTN to design, develop and operate

GST System Project)

MSDG Mobile Service Delivery Gateway

NSDG National e-Governance Services Delivery Gateway

OLAP Online analytical processing

ORM Object-relational mapping

PKI Public Key Infrastructure

REST Representational State Transfer

RFP Request For Proposal

SGST State Goods and Service Tax

SLA Service Level Agreement

SOP Standard Operating Procedure

SOA Service Oriented Architecture

SSL Secure Socket Layer

SSDG State Service Delivery Gateway

TLS Transport Layer Security

TRP Tax Return Preparers

UUID Universally Unique identifier

VPN Virtual Private Network

XKMS XML Key Management Specification


3

1. INTRODUCTION

1.1 Introduction to GST System

The Goods and Services Tax (GST), which will replace the State VAT, Central Excise, Service

Tax and a few other indirect taxes, will be a broad-based, single, comprehensive tax levied

on goods and services. It will be levied at every stage of the production distribution chain by

giving the benefit of Input Tax Credit (ITC) of the tax remitted at previous stages. GST is

based on a destination-based taxation system, where tax is levied on final consumption. It

is expected to broaden the tax base, foster a common market across the country, reduce

compliance costs, and promote exports. The GST demands a well-designed and robust IT

system for realizing its potential in reforming indirect taxation in India. The IT system for

GST would be a unique system, which will integrate the Central and State tax

administrations.

1.2 Introduction to GSTN

Goods and Services Tax Network (GSTN) is a Section 25 (not for profit), non-Government,

private limited company set up primarily to provide IT infrastructure, systems and services

to the Central and State Governments, tax payers and other stakeholders for supporting

implementation and administration of the GST in India, hereinafter also referred as “GST

System” or “GST System Project”.

Based on consensus amongst States/UT’s and Central government on a common GST

System, GSTN has been made responsible to build and operationalize this system as the only

national agency.

The project of setting and operations of IT infrastructure for enabling country wide GST

rollout is a unique and complex IT initiative. It is unique as it seeks, for the first time, to

establish a uniform interface for the taxpayer and a common and shared IT infrastructure

between the Centre and States. Currently, the Centre and State indirect tax administrations

work under different laws, regulations, procedures and formats and consequently the IT

systems work as independent silos.


4

GSTN has embarked on a journey to implement from ground up a modern, automated, fully

digital tax infrastructure also called as “GST System”. The importance of this initiative and

the resulting considerations are as follows:

a) It would have a large social and economic impact

b) It has adequate potential to be a major driver for the local tech ecosystem if designed

and architected carefully

c) While architectural scalability is enormous, the required technologies are available to

build an open system

d) Convenience and user experience via ecosystem provided applications to provide

multiple options to taxpayers

e) Convenience and user experience are key to overcome resistance from the taxpayers

f) Seamless end-to-end interaction with the infrastructure is paramount

1.3 Role of third party developed applications and solutions

The GST System is being developed by Infosys, the Managed Service Provider (MSP). The

work consists of development of GST Core System, provisioning of required IT

infrastructure to host the GST System and running and operating the system for five years.

The proposed GST envisages all filings by taxpayers electronically. To achieve this, the

taxpayer will need tools for uploading invoice information, matching of input tax credit

(ITC) claims, creation of party-wise ledgers, uploading of returns, payment of taxes, signing

of such document with digital signature etc.

The GST System will have a G2B portal for taxpayers to access the GST Systems, however,

that would not be the only way for interacting with the GST system as the taxpayer via his

choice of third party applications, which will provide all user interfaces and convenience via

desktop, mobile, other interfaces, will be able to interact with the GST system. The third

party applications will connect with GST system via secure GST system APIs. All such

applications are expected to be developed by third party service providers who have been

given a generic name, GST Suvidha Provider or GSP.

The taxpayers will need to electronically sign the documents before uploading and thus will

need digital signature certificates or equivalent which is easy to use. A big chunk of taxpayers

does not use automated systems for billing, accounting, inventory management, invoicing

etc. We need innovative solutions for them which is easy to use and has lower cost overheads.


5

In short, smooth deployment of GST in India requires a strong eco-system consisting of the

following:

Areas of work Possible Candidates 1 GST Solutions which enable

online filing of tax invoice information, returns, online registration etc.

Companies who provide or would like to provide all these functionalities to taxpayers thru their portal or Apps or offline tools. They could become our GSPs

2 GST compliant Accounting software products

Companies having accounting software products where additional functionalities could be added to enable online filing. They could also become GSPs

3 Tax accounting software products which would interface with ERP systems and generate GST returns etc.

Companies who are working with ERP product companies to enable their users to file variety of returns under indirect tax regime (Central Excise, Service Tax, State VATs etc.) today.

4 Payment solutions/products Innovative solutions for small and micro payments specially for those who do not have online banking facilities

5 Digital signature certificates /e-signatures

All electronic documents are to be digitally signed. Those providing easy solutions for digitally signing the returns/invoice data etc.

6 Innovative solutions for inventory management, billing and accounting etc. for small taxpayers who are not using automated tools etc.

New age companies who would like to come up with cloud and mobile based solutions for taxpayers who are small in size and averse to using PCs but are familiar with mobile/Tab based solutions.

Thus the GST Eco-System will consist of players who could become GST Suvidha Providers

as well as those who operate in specific areas but contribute to smooth operationalization of

GST. GSTN proposes to release APIs for various functions to the industry to enable them to

make their existing products GST compliant as well as to enable new companies to come up

with innovative solutions to cater to these requirements. The process needs extensive

consultation and handholding and in this regard GSTN proposes to organize a series of

workshops, first of which, is proposed to be organized at Bangalore in the last week of

January 2016.


6

2. GST SYSTEM

2.1 Design Consideration for GST system

While conceptualizing the GST solution following design considerations have been

considered.

2.1.1 Ecosystem Approach

Figure 1: GST System Stakeholders

A common GST system will provide linkage to all State/UT Commercial Tax departments,

Central Tax authorities, Taxpayers, Banks and other stakeholders. It will be a common medium

of information sharing with standardized forms, formats, payment challans,

acknowledgements, certificates etc.


7

Taxpayers will interface with GST System via GST system portal or via GSP ecosystem provided

by way of applications for activities such as Registration, Tax payments, Returns filing and other

information exchange with GST core system. Information captured on the GST System will be

shared with the respective State/Union Territories (UTs) and Centre (CBEC) for further

processing. State/UTs and Centre will process the information in their respective tax

administrative systems and re-transmit the processed information to GST system which will be

available for Taxpayers for viewing various MIS reports via their choice of applications.

2.2 Role of GST Suvidha Providers

The GSP developed Apps will connect with the GST system via secure GST system APIs. This

architectural approach has been taken as the UI based integration through a ubiquitous web

portal. It requires manual interaction and does not fit most consumption scenarios. The

following benefits are envisaged from API based integration,

a) Consumption across technologies and platforms(mobile, tablets, desktops, etc.) based

on the individual requirements

b) Automated upload and download of data

c) Ability to adapt to changing taxation and other business rules and end user usage models

d) Integration with customer software (ERP, Accounting systems) that tax payers and

others are already using for their day to day activities.

The GSPs will become the user agencies of the GST system APIs and build applications and web portals as alternate interface for the tax payers.

2.3 Functions / roles of stakeholders of GST Eco-System

S.N. Name of Stakeholder of GST System

Major Functions

1 Tax Payers a. Application for registration as taxpayer, and profile management

b. Payment of taxes, including penalties and interest c. Uploading of Invoice data & filing returns / annual

statements d. Status review of return/tax ledger/cash ledger e. Others

2 State Tax Authorities and Central Board of

a. Approval for enrollment/registration of taxpayers b. Tax administration of state tax(Assessment /Audit /Refund / Appeal/ Investigation)


8

Excise & Customs (CBEC)

c. MIS and other functions

3 Banks / RBI a. Receipt of tax payments b. Maintenance of records of payments c. Reconciliation/state wise accounting d. MIS and other functions

4 GST Suvidha Providers (GSPs)

a. Development of various apps / interfaces for taxpayer, TRPs of GST system b. Providing other value added services to the taxpayers

5 Other Eco-System partners

a. To provide value added services to taxpayers/TRPs b. To provide Apps/off-line solution to taxpayers

6 GSTN a. Set up of GST system and maintain the same b. Clearing house for IGST c. Interface with the ecosystem of GSPs

7 Infosys, the managed service provider (MSP) of GSTN

a. The System Integrator and developer of GST Systems b. Manage the GST Systems for 5 years c. Provide Sandbox and other required interface to GSPs

8 MSP/SI’s of Centre or State

a. Develop G2G APIs and apps relating thereto. b. APIs for GSTNs internal use.

9 GST council a. Define policies & procedure for GST b. Body for decision making

10 Tax Return Preparers (TRP)

a. TRP denotes CAs, tax advocates etc. b. Act as a mediator and helps the taxpayers in registration/payment/ return submission. c. Help the taxpayers in resolving tax related issues.

11 Income Tax & other department

a. Departments which directly or indirectly interact with GSTN for information exchange

b. Income tax system will be used for PAN , TIN validation 12 Aadhaar a. For strong unique identity usage and online

authentication of identity of partners /proprietors /Directors etc.

2.4 API Approach

One of the design considerations is to provide multiple channels/interfaces to taxpayers to

interact with GST system. The aim is to provide multiple channels to taxpayers to interact with

GST System and while doing that unleash the entrepreneurial potential of private sector

companies which can come with innovative designs of Apps to be used by the taxpayers and

other stakeholders. The other aim is to ensure that no direct communication takes place with

core engine of GST system. The bye-product of this arrangement will be multiple options to

taxpayers to interact with GST System, reduction of load on GST system portal and reduced

surface area of attack.


9

The high level view of stakeholder’s interaction with the GST system as common data hub

interfacing all communication via Open APIs is depicted below. State infrastructure

communicates with GST system to download, process, and upload data.


10

Figure 2: Stakeholder access points

2.4.1 Security & Privacy

Security and privacy of tax data is fundamental in design of GST system without

sacrificing utility of the national indirect tax system. When creating a national indirect

tax system of this scale, it is imperative that handling of privacy and security of taxpayer

data are not afterthoughts, but designed into the strategy of the system from day one.

This principle will also apply to GSPs who will act as extended arm of GSTN.

2.4.2 Configurability

GSPs need to design the Applications in such a way that any change in policy can be

pushed to the applications. Say for example, if the rate of a commodity or service gets

changed, the GST system should be able to push this information and the new rate gets

reflected in the applications.

GSP provided


11

2.4.3 Data Distribution Service

The GST system shall be able to provide data on subscription-publication basis. The

organization of the information exchange between GST System and GSPs is fundamental

to publish-subscribe (PS) systems. The PS model connects anonymous information

producers (publishers) with information consumers (subscribers). The overall distributed

application (the PS system) is composed of processes. The goal of the DDS architecture is

to facilitate efficient distribution of data in a distributed system. Participant using DDS

can ‘read’ or ‘write’ data efficiently and naturally with a typed interface. Underneath, the

DDS middleware will distribute the data so that each reading participant can access the

‘most current’ values. Various sub-systems of GST system are also going to follow this

approach.

2.5 Advantage of the API based Approach

Following are few advantages to taking the API based approach

i. Choice/Flexibility: Users across the GST ecosystem gets the choice and flexibility of using their preferred application and user interface without having to depend on a single portal. This provides them the choice of using a single ERP or Tax application within their organization for all their work including GST related activities. In addition, this provides a choice to end users/organizations to choose the most appropriate business process, customize workflows, etc. within their system rather than depending on a single portal for all their work. Having a healthy and competitive application provider ecosystem is best for tax payers and other users.

ii. Innovation: Application ecosystem (GSP eco-system) can innovate in terms of providing all kinds of features such as offline capabilities, alerting capabilities, mobile/tablet interfaces, and so on as device and user interface technologies evolve without GSTN having to build all possible features into a single portal.

iii. Agility: When entire system is loosely coupled via components exposing APIs, it allows individual API implementations to change without having to affect the rest of the system. API driven approach allows encapsulation of components and data models without every other part of system knowing the details. API based design also allows automated testing of the entire system to ensure changes are quickly tested in a completely automated way to avoid regression.

iv. Manageability: API based systems allow easy manageability in terms of monitoring, auditing, and performance analysis. In addition, individual APIs can be versioned and deployed/upgraded/rolled-back instead of entire application being released, tested, and deployed.

v. Scale: For national GST system to scale, load has to be distributed across various systems. This is key for responsive user experience as well as core system scaling. Instead


12

of entire application being monolithic and access via web portal, if should be built with stateless APIs that can be scaled horizontally. Most critically, user interface load is distributed to external applications making GST System truly a lean platform that can be scaled to country’s need. All users will not be forced to use a single web portal which will have huge performance implications during tax filing period. Instead providing stateless APIs allow load balancing across data centers for scale and distributing user interface load to 3rd party applications.

vi. Data consistency: Providing APIs to access all data models and functionality ensures data is not duplicated unnecessarily. This offers a single source of truth of data to be managed via common APIs. In addition, providing centralized data validation, digital signature, etc. ensures data is consistent and accurate across the system.

vii. Security: Data security is paramount to GST system. Accessing data only via APIs ensure centralized management of security controls. Encapsulating access control, auditing, confidentiality (via encryption), and integrity (via signatures) is only possible via common APIs.


13

3. GST SYSTEM ARCHITECTURE PRINCIPLES

GST system is a Government program built as a critical national IT infrastructure and is

being designed to sustain openness in the long run. GST system is being built on the

following core principles:

3.1 Platform Approach:

GST system is being built as a platform. This means that GST system will be built entirely

with open APIs from day one, and the system features can be accessed via any user interface

(internal or 3rd party applications) that works on top of these APIs. Hence the GST system

is envisaged as a faceless system with 100% API driven architecture at the core of it. GST

portal will be one such application on top of these APIs, rather than being fused into the

platform as a monolithic system.

Openness: Adoption of open API and open standards will ensure the system to be

lightweight, scalable and secure. Openness comes from use of open standards and

creating vendor neutral APIs and interfaces for all components. All the APIs will be

stateless. Data access must be always through APIs, no application will access data

directly from the storage layer or data access layer. For every internal data access also

(access between various modules) there will be APIs and no direct access will be there.

No Vendor lock-in and Replace-ability:

o Software vendor neutrality

o Use of commodity hardware

Security and Privacy: The system will ensure privacy and data integrity and must

disseminate data to authenticated and authorized users only (both internal and external

users).

Scalability: For achieving massive scale it is critical that technology choices are kept

simple, open, multi-vendor, and standards based.

Loose coupling through open stateless API and messaging: GST system is conceived as a

‘common platform’ on which many applications will be built/ interfaced, it is critical that

all third party interfaces be fully interoperable without any affinity to platforms,

programming languages, network technologies. Such open interoperability is an

absolute requirement for GST system to be widely adopted as a national tax platform.


14

Reliability: The system must have appropriate measures to ensure processing reliability

for the data received or accessed through the solution. As the system will be API driven

the APIs built both by internal and external authorities should go through performance

and security measures to increase reliability.

It will be necessary that the following issues be taken care properly.

a) Prevent processing of duplicate incoming files / data

b) Zero loss of data ( data already saved / date at rest should also not be lost)

c) Unauthorized access and alteration to the Data uploaded in the GST system shall

be prevented


15

4. HIGH LEVEL ARCHITECTURE OF GST SYSTEM

4.1 Architecture Overview

The GST systems architecture consists of the following high-level components:

a. The GST core system (i.e. system without user interface- GST portal) is a faceless system

consisting of a set of services exposed via APIs for storing and processing all the relevant

data. It includes all the business and functional services. It is optimized for reliability,

scalability and performance. Other components can access the core system only through

its APIs.

b. API Layer: GST system exposes three sets of distinct APIs,

1. for consumption by taxpayers/dealers and businesses (G2B) via various

application interface, (To be developed by GSPs)

2. for consumption by government agencies at central or state level (G2G) (to be

developed by MSP and SIs of States/Center, and

3. for all GSTN internal use to manage the entire system (by MSP).

Conceptually, there is no difference between APIs for taxpayers and APIs for government

entities, banks etc. each with a slightly different flavor. The most obvious difference

among these usage scenarios is in the authorization and visibility rules (e.g. taxpayers

mostly see only their own documents, tax authorities have broader access etc.), but these

rules should be configurable flexibly for each API. The APIs are RESTful, XML-based,

and stateless services. For security reasons, the production API end points should not

exposed to the internet and can only be consumed via MPLS lines or secured VPN. All

APIs are only accessible via HTTPS protocol.

c. GST system landscape also includes a web portal for direct, browser-based access by

taxpayers or government employees. The UI and access functionalities for the taxpayers

and the government authorities should be different. The web portal access the

functionality of the system through the exact / same set of APIs as any other external

application.


16

d. GST system APIs are meant to be consumed by a variety of client applications and

platforms, including mobile devices, POS machines, embedded clients in on premise or

on-cloud ERP systems, etc.

4.2 GST System accessibility through Ecosystem

The following diagram depicts the layers involved in providing the GST APIs to the last

mile.

Figure 3: GST System Accessibility View

GST System is being built with following five layers:

a. First Layer- GST Core System: The core business and functional services

reside in this layer. As mentioned before these services are loosely coupled and


17

are surrounded by the API layer. This layer interacts with the external world

through the API layer.

b. Second Layer – API Layer: Production API layer should not be exposed to

internet; accordingly there should be no threat of DDOS attack. API layer will

make sure that the access and feature control are verified through functionality

key. API key has information regarding feature, organization, expiry date, etc. are

embedded. After the licenses key is validated, the structure of data is validated.

API layer validates below for each data / request that comes i.e.:

i. License key of the caller (organization, features, expiry, etc.)

ii. Structure

iii. Size

iv. Digital signature of the API calling entity

v. Integrity of data to ensure that the data is not changed in between

c. Third Layer- Access to IT Infrastructure layer inside Data Centre:: This

layer encompasses IT infrastructure serving incoming and outgoing requests. At

this layer GST system will be secured through stringent network and security

infrastructure.

d. Fourth Layer- Access Layer for GSP community: This layer is considered

for GSPs. They uses GST authentication to enable its services and connects to the

GST system through an MPLS/ VPN connectivity. A GSP needs to enter into a

formal contract with GSTN. There can also be sub agencies desiring to use GST

APIs to enable its services through an existing GSP. Ex: a tax payer association

can become a GSP and TRP could access through it. State / CBEC / banks systems

can also access GST System through this layer whom GSTN provides licenses key.

e. Fifth Layer: This layer provides access to all end users including tax agency

employees, banks etc., taxpayers, state authorities against authentication and

authorizations granted on GST services as per the system .This layer is used by

users of the apps and portal provider. All the small and large business users fall

under this layer.


18

5. API FRAMEWORK FOR GST SYSTEM

GST system will be an API based solution having three categories of APIs as indicated in

section 4.1 (b). GST Suvidha Providers (GSPs) will build APIs to be used by the taxpayers,

TRPs (CAs, Tax Advocates, STPs etc.) and other non-official entities. GSTN will be the

overall regulator and overseer of the GSP ecosystem.

Following are some of the key principle for API framework

a. API layer would not be exposed to untrusted connection

b. All external users (including officials / taxpayers) will connect to GSTN portal through

SSL Layer of authentication along with user id, single sign authentication / OTP etc.

c. All APIs level access either to department systems or to Servers of GSPs ( for users

accessing the system through the GSPs) should be through HTTPS and through either

of the below mode of connectivity:

i. MPLS or

ii. VPN over internet

d. GSPs /Large tax payers will sign up with GSTN and get the access of license key for

accessing the system through either of the channels namely MPLS or VPN over internet.

The GSPs in turn will enter into an agreement with GSTN to provide sub-licenses to

smaller organizations and start-ups to call the APIs through their apps.

e. GST system will have provision to support issuance of license key / sub licenses key

including validation of the same in the GST System

f. All data transfer from / to GST system will happen through APIs

g. App signature authentication will be through the license key + time stamp + app version

and other meta data

h. All the APIs would be stateless in nature, thus easy to load balance, even if hit through

portal is very high and this requires high end processing.

i. GSTN would prescribe the mechanism for empanelment of GSPs who will use the GSTN

APIs and build apps using the same


19

j. MSP would deploy a developer sandbox for the GSPs to test the APIs with dummy data.

k. An API design document with the specification would be shared with the GSPs for them

to start developing the interfaces. The APIs would be RESTful services with XML payload

and would have the following minimum information in the design document.

i. Purpose of API

ii. Author & Owner of API (controlling entity)

iii. Input parameters

iv. Output

v. Error codes

5.1 Set up, Operationalize and Maintain Systems and Process

for APIs

GST System will be an API based solution where external agencies / GST Suvidha

provider (GSP)) will also build & manage APIs as well as will set up secured networks

(MPLS / VPN over internet) to access the GST system. Stakeholder can access GST

System through these agencies (GSPs) also apart from accessing the services through

GST portal. The MSP on behalf of GSTN will set up, manage and monitor the API services

for proper operation of GST system. Various functions performed by MSP in this regard

will be as follows:

5.1.1 GSPs Enrollment and operations

GSTN will be the overall regulator and overseer of the API based system, MSP on behalf

of GSTN will set up the requisite process as well as system to build, operate & manage

and sustain APIs for GSPs in a secured and controlled environment.

The entities desirous of becoming a GSP will have to enroll with GSTN. Those who

express interest will have to participate in a screening process like participation in

hackathon. Those screened out will have to sign a formal contract with GSTN to become

GSP.

The GSPs will have to establish secure connectivity compliant with GSTN’s standards

and specifications. GSPs will offer their GSTN-compliant network connectivity as a

service and transmit authentication requests to GST system. GSPs will also have their

own mechanism to issue license key to sub-GSPs.


20

i. Only agencies contracted with GSTN as GSPs shall send authentication requests

to the GST solution; no other entity can directly communicate. Sub-GSPs will

communicate through GSPs.

ii. GSPs will use GST authentication to enable its services and connect to the GST

system through an MPLS/ VPN over internet connectivity after validation of

license key.

iii. GSPs will need to take following steps to use GST authentication

a. Identify business / service delivery needs and select appropriate authentication

types

b. Fill online application form

c. Send signed contract and supporting documents to GSTN

d. Ensure process and technology compliance as prescribed by GSTN

e. Obtain approvals from GSTN and sign contract with it

f. Develop services and start working as a GSP

5.1.2 Authorization and License Key Management

License Key is the ASCII pre-defined string that shall allow enabling of various services

for a given GSP. This License Key string shall also carry validity period for each service.

i. MSP on behalf of GSTN will create an administrative portal to enable GSPs to have

a user account called the GSP ID to manage their services through their

authorized persons.

i. The GSP will upload their Digital Certificates.

ii. Admin portal shall enable GSTN to manage these license keys

iii. GSP ID, GSP's Digital Certificate shall help validate the License Key and the

authorization validations shall form the core of the API design.


21

5.1.3 Standardizing API and specification

Standardization and version control will be key to success of this project. GSTN has

developed specification of APIs for services facing the taxpayers. The list of APIs and full

specifications are at Annexure-I. These are to be used by the GSPs to create their own

services and expose them to the outer world for stakeholder use. GSTN/MSP shall

manage the API documents and publish changes etc. Annexure-II has full

documentation on two APIs for illustration purposes.

5.1.4 Environment Management

Creation of sandbox environment is the first step to enable the GSPs to publish a mock

version of APIs developed by them. This is being done by GSTN and it should be in

position by August-September 2015. GSPs can perform testing in a sandbox environment

which is distinct from production. Sandbox will provide the same catalogue as the

production framework; however these APIs will be stubbed/mocked only. All the APIs

shall be hosted in sand box environment to ensure at-least a couple of GSP integrate/test

before the API is moved to production.

The MSP will create a bigger and permanent sandbox environment to be used by GSPs

for this purpose by November 2015. MSP will also develop the admin portal to be used

to create GSP Dev IDs that can be accessed by the GSPs for development, test and

integration. GSTN thru its MSP will provide a multi-tenant solution and for each tenant

multiple environments can be created, for example a dev sandbox environment for

verifying the functionality of the APIs and a developer –pro sandbox environment for

further testing. Each environment represents a deployment target and APIs, once they

are developed, must be deployed to an environment and then published to selective

organisations to become available to consumers who belong to those organisations.

Environments are useful for separating Plans and APIs that GSP would like to test before

publishing the same.

5.1.5 User Authentication

The system (managing sandbox) will provide authentication services for allowing users

(GSPs) to access the above mentioned environments and to do the following operations

i. To authenticate user into the Sandbox.

ii. To configure authorisation policy for new APIs as they are introduced to the

framework.

iii. Allow user access the available APIs and associated properties in accordance with

his/her entitlements.


22

iv. Allow Client app exposed to the API, resources data in accordance with the

configuration for that app.

v. Blacklist/Block Access

Identity, authentication, and authorization of the tax-payer: User authentication must

be federated and the responsibility of GSP apps else everything will come to GST

Platform crowding the same. One possible way could be use of common identifier like

Aadhaar which can link GSP apps and GSTN. This way, GSP apps can create optimal

and innovative authentication schemes within their app without GSTN having to have

all that at the platform level. GSTN would be willing to have new ideas on how such

authentication will be done by GSP App.

For example a taxpayer while using GSP provided App will authenticate himself using

Aadhaar before his data or query is sent to GST Systems.

5.1.6 Publishing and Management of API

There will be a mechanism that will allow authorized users to publish new APIs as they

are created to sandbox, test and production environments, as required. Once the API are

developed and deployed in the sandbox environment MSP on behalf of GSTN will do a

proper functional, security and performance test and certify the API before they are

published for production usages. An API catalogue will be maintained by the system.

5.1.7 Version Control

MSP will provide a controlled mechanism for API versioning control for any change.

The version & release management process will cover this aspect to ensure every change

is made or rolled-out in a controlled & informed manner.

5.1.8 API Retirement

MSP will provide a mechanism to retire/archive APIs. The solution will provide full

support of managing retired and archived APIs as part of the life cycle and associated

version control.

5.1.9 API Governance

MSP on behalf of GSTN will provide a mechanism to define and enforce SLAs/quotas for

consuming entities of the API framework. The solution will provide mechanism (“Plan”)

to control how much traffic can be sent by a user through the interface. A Plan can make

available a collection of resources from one or more APIs. A plan defines a rate limiting

policy that specifies how many requests an application is allowed to make during a


23

specified time interval, and what action should be taken when the threshold is exceeded.

The solution will support both a hard limit which will throttle the traffic and a soft limit

which will notify the administrator about the policy violation. The APIs load shall be

continuously and pro-actively monitored for suitable & prompt actions in case of

excessive loads, failures or performance bottlenecks.

5.1.10 API Updates, Notification and tech support

GSTN System will provide consuming entities with appropriate notifications with respect

to APIs. Documentation about an API, such as URL used to call the API and the security

mechanism used by the API to authenticate application user, will be automatically

generated when defining the API and exposed through the developer portal. Additional

supporting documentation that can further help application developer to use the API,

such as samples and/or tutorials and other supporting documentation shall be made

available through the developer portal.

5.1.11 API Security Governance

GSTN System will have appropriate & adequate security mechanisms governing access

to API framework. The system will inspect the headers for APIs genuineness before

acceptance. It will also apply all security checks e.g. DDoS Attacks, XML Denial of

Service (xDoS), Slow down or disable an XML based System, Message Snooping, XML

Document Size Attacks, XML Document Width Attacks, XML Document Depth Attacks,

Jumbo Payloads, Recursive Elements, Public Key DoS, XML Flood, Resource Hijack

etc. to ensure rightful and secured access to API consumers. GSTN System will also track

dev/client apps consuming APIs.

5.1.12 Certification of Apps developed by GSPs

GSTN / third party certifiers and auditors will be engaged for certification of Apps

developed by GSPs. STQC or one of their empaneled auditors could be used by GSTN

for this purpose.

5.1.13 API Validation Method

Consuming apps will have individual API license keys. The proposed methods of these

validations are as below:

a) License key validation:

The token generation will be used for validating the license key

b) Payload structure


24

Validation of XML message can be supported by XSLT (Extensible Stylesheet

Language Transformations) support

c) Input size validation

This is achieved by setting parameters

d) Data structure

Message Formats – SOAP, XML, JSON, Non-XML

e) Data integrity

Achieve through digitally signing APIs. Also following actions need to be

performed – Crypto (Sign/Verify/Encrypt/Decrypt), Validation, AAA, Filters,

Virus Check, Transform XML, Transform Bin, Routing, Backend Load

Balancing, SLM, Response Caching, SQL, Side Calls

5.2 API Metering

Since all consumption of the GST services will occur via the API layer, GSTN will measure

usage and compute billing charges at the API layer. The API metering component has the task

of:

a. Measuring usage of each API by each consumer

b. Computing charges for each consumer based on the appropriate billing plan

c. Disabling access to specific APIs based on quotas etc.

As APIs are published & productized, applying limits around API becomes important policy

control point. This could be for various reasons such as controlling the usage, preventing

backend meltdown or towards monetization. These usage limits configured by the API

provider are then metered & monitored for usage. Typically API consumers like GSPs will sign

up for a plan which will provide them with some usage limits.


25

5.3 Data Integrity

Data in transit or data at rest must be protected from tampering. To handle the risks of

data being tampered by the external users and during transit, API design must ensure

checksum features and digital signatures to validate the data is secured. The API

documents explain these features in detail and all the sensitive data must adhere to

these principles. GST system shall ensure to validate integrity using the checksum and

digital signature validations before processing the data.


26

6. Selection Process

6.1 Who can become a GSP?

Registered in India as a company/firm

Engaged in development of software

Several larger companies use ERP systems of non-Indian companies. Such companies can also

become GSP provided they have a registered office in India. If they are a pure software

provider with no presence in India, then they can work with another GSP to become "Sub-

GSP".

6.2 Process to Apply Anyone who fulfills the above mentioned criteria can apply to become a GSP. GSTN will open

a registration portal for this purpose. Details given in Para 5.1

6.3 Selection criteria

We envisage two types of companies/firms becoming GSPs. One which are already providing

accounting software and for them becoming a GSP will be the next logical step. The second

group of companies/firms will be the new age Internet companies.

For the first group the criteria will be their being in the business of development and selling of

accounting software products currently in use in India with a user base of at least 5000. For

the second group GSTN proposes to conduct a hackathon or App development competition to

select 20 to 30 firms who could then develop various Apps for the taxpayers and other users of

GST System.


27

7. Business Model

The GST Suvidha Providers (GSPs) are envisaged to provide innovative and convenient

methods to taxpayers and other stakeholders in interacting with the GST Systems from

registration of entity to uploading of invoice details to filing of returns. Thus there will be two

sets of interactions, one between the App user and the GSP and the second between the GSP

and the GST System.

The GSPs will be free to adopt business models they chose to recover the cost of operations

from their users and/or through advertisements. As far as the interaction between GSP and

the GST System is concerned, the same will be free in the first year of operation but will

become chargeable from the second year of operation. Based on data from various State Tax

departments, the average interaction between an average taxpayer and the GST System is

estimated as given in the table below:

Individual transactions Quantity Remarks

Average sales invoices to be uploaded* 400

Average number as per report from 9 states

Average purchase invoices to be uploaded 20 Assuming 5% of sales upload

Payment of tax 1 Assuming one payment

Seeking Mismatch report 10 Assuming mismatch report is sought ten times a month

Miscellaneous queries 20 Other miscellaneous queries Total 451

*: The number of invoices pertaining to a taxpayer varies between 1 to 1,14,414 per month. The figure of 400 is the average number of invoices per month per taxpayer.

As mentioned in the previous chapter, GSTN envisages API metering and thus usage by each

GSP will be measured and that will be used as the yardstick for recovery of cost.


28

Annexure

API List

An illustrative list of APIs envisaged in the GST System is mentioned below. Please note

that these are indicative in nature and more APIs will be identified in due course.

S.

N.

Resources Actions API Category Service

type

Notes

1 Taxpayer uploadInvoice Return G2B update invoice details

2 Taxpayer Authorization

APP for

external users

Authorizing an

external API to

access the GST

services

G2B Authorization process

for different API to

access GST service

3 Taxpayer verifyGSTIN Registration G2B lookup (Input GSTIN,

output = Y/N, Status ,

legal name of dealer)

4 State &

CBEC

returnRemind

er

Return G2B Send reminder to return

defaulter

5 Taxpayer NewRegistrati

on

Registration G2B New Registation for tax

payers are entered by the

taxpayers.Partially filled

application form will not

be accepted by GSTN

System

6 Taxpayer updateApplica

tion

Registration G2B update application on

receipt of query from tax

authority

7 Taxpayer trackApplicati

on

Registration G2B Fetching of application

status by unregistered

dealer

8 Taxpayer updateRegistr

ation

Registration G2B a) To update any change

in the dealer registration

details auto updation (


29

self service basis)

b) To make request to

tax authority for

amendment in 6 fields

requiring approval of tax

authorities

9 Taxpayer ReqSurrender

Registration

Registration G2B Taxpayer request for

surrender of GSTIN

10 Taxpayer downloadRC Registration G2B Taxpayer can download

the Registration

certification

11 Taxpayer taxpayerDash

board

Registration G2B Taxpayer dashboard

12 Taxpayer requestUniqu

e ID

Registration G2B Registration of UN

bodies

13 Taxpayer uploadmonthl

yReturn

Return G2B monthly return details

for uploaded by the

taxpayer At the end of

process

acknowledgement

generated.

14 Taxpayer Uploadquaterl

yReturn

Return G2B Tax payer upload

quartely return.At the

end of the process

acknowledgment is

generated.

15 Taxpayer uploadAnnual

return

Return G2B Upload annual returns

16 Taxpayer updateReturn Return G2B Rectification of return

data, only individual

records are requested to

be rectified

17 Taxpayer viewInvoice Return G2B one or many, data range,


30

GSTIN based lookups

18 Taxpayer CheckReturnS

tatus

Return G2B Taxpayer can check

return status

19 Taxpayer IGSTSettleme

ntLedger

IGST

Settlement

G2B The record would be

maintained in a form of

a ledger. The ledger

generation (i.e. posting

of entries for cross

utilization) shall be done

as soon as a return is

accepted into the GST

System).

20 Taxpayer GSTChallan Payment G2B Tax payer can pay pay

taxes as per return, on

demand or non tax

payments. Both online

and offline mode

payment

21 Taxpayer refundApplica

tion

Refund G2B File refund request by

taxpayers and UN bodies

22 Taxpayer adjustmentTa

xes

Refund G2B adjustment due to wrong

tax period mention in

the challan

23 Taxpayer adjudicationP

rocess

Adjudication

Process

G2B Adjudication process

management by tax

payer

24 Taxpayer appealProcess

taxpayer

Appeal Process G2B Appeal process by tax

payer

GST Suvidha Provider - Instavatinsta.instavat.in/PDF/Eco-SystemforGSTandGSTSuvidhaProviders.pdf ·...

Documents

Transcript of GST Suvidha Provider - Instavatinsta.instavat.in/PDF/Eco-SystemforGSTandGSTSuvidhaProviders.pdf ·...