Note: The Banking Service Provider API, app registry and key provisioning is handled internally by Sage on request.
If you are a banking or financial service provider and wish to connect your service to the Sage Banking Service, please register your interest by email.
Step 1: Register with Sage
To start using the Provider API you must register your service by email.
Once your banking service has been registered, Sage will send you instructions on how to start using the Provider API together with access credentials. You will also receive a preconfigured Postman environment for the Provider API Postman Collection guide.
Step 2: Implement a Connector API
To process webhooks sent by the banking service, you will need to implement a Connector API. The Connector API is required to handle the requests sent to the registered URl of the banking service when an end user attempts the following:
- User Signup’s to a bank feed for their chosen provider and account type
- User re-authenticates after authorisation expiration
- User requests transactions
- User disconnects the bank feed
- Authorisation has expired
Provider API requirements
- Only cleared transactions should be sent
- Each transaction should have a unique id. Statements containing transaction ids previously sent will return an error and will not be processed. It is safe to resubmit a statement should there be uncertainty around a previous delivery (e.g. connection times out before a response is received, 500 error)
- Each upload containing transactions must have a correctly signed (negative or positive) ending balance
- Concurrent statements are not permitted for a single bank account. The HTTP response for the first statement must be received before any subsequent statements are submitted
- Transactions must not be more that 2 weeks older than the newest transaction
- Transactions should be sent in the same order as they appear on the account statement
- Transitions should ideally be sent in near real time
- The Provider API will throttle requests at a pre agreed rate (default 10 requests per second) and may return a 429 error response. In the event of a 429 error response the integration should default to an appropriate back off before retrying
- Sage ID access tokens should be re-used until expiry. New tokens are not required for each new request
- Your integration should ensure client credentials and API keys are stored securely
- Sage should be immediately notified of any breach of credentials
- Providers who have chosen to create a connector API to support notifications, must validate the API key header and Sage Id token sent in any notification
Setting up and making requests
Sage has assembled a Postman Collection to illustrate the Sage Banking Service Provider API methods and workflow.
Read the Provider API Postman Collection guide.
Supported Encryption Protocols
The Payments Acceptance Service supports the Transfer Layer Security (TLS) 1.2 encryption protocol only.