Authentication

Generate an access token

To use Brite’s API, you need to authenticate with your APi credentials (public_key and secret) using OAuth 2.0. You can find them in the Brite Back Office for sandbox or production. Please ask your colleagues if you already have an active set of credentials.

You add them to the POST /api/merchant.authorize API call.

Brite returns the access_token, a expires timestamp and a refresh_token.

Request to generate a new access token

				
					POST /api/merchant.authorize HTTP/1.1
Host: sandbox.britepaymentgroup.com
Content-Type: application/json

{
    // This is a fake public_key, replace with your PUBLIC KEY
    "public_key": "sandbox-7d2fcc4d92ccbc8db155a51e4ba1e6991cc7cff1",
    // This is a fake secret, replace with your SECRET
    "secret": "c135b4ebbd50563ae2363e8aaa7d80147b318fe4"
}

Response - HTTP 200

				
					HTTP 200 OK
{
    "access_token": "d98479174cac814bc9ddee617885694d8d9d10b11175d13872d3364a450961e94f7d296dec956f81",
    "expires": 1741903012.0,
    "refresh_token": "503b3b90a175f30c84f1dcf57af379e018d383f64d533ea910ccfd14c1a1a384b0013b4ee84c6352"
}

access_token – valid until expire (typically 6 hours)

A new access token is valid until it expires at the expires timestamp. That is typically 6 hours after it was created. Each request will create a new access token, meaning you can create multiple access tokens.

We recommend using the access_token for as long as possible but you should refresh the token with enough time before expiry. This allows you update the token throwout your system. For example, 30 min before expiry.

expires

The timestamp at which the access_token expires. It is in unix epoch format, represented in seconds. That is typically 6 hours after it was created.

refresh_token

The refresh token allows you to create a new access and refresh token at any point in time as long as it is valid. The previous access and refresh token remain valid until they expire.

Use the access token

The access_token serves as a temporary credential for accessing protected resources. In subsequent API calls, merchants must include the access_token in the request header using the Bearer token authentication scheme.

				
					// Example create deposit request with Bearer Token
POST /api/session.create_deposit HTTP/1.1
Authorization: Bearer <YOUR_ACCESS_TOKEN>

Refresh the access token

Excessive generation or refreshing of access tokens

Please note that excessive generation of access tokens can lead to security issues. Brite is not responsible for the secure handling of access tokens.

You should create 1 access_token and maintain it for all requests until shortly before its expire timestamp. You then refresh your access_token with the refresh_token and follow that principal thorough the entire integration.

Request to refresh a access token

				
					POST /api/merchant.token HTTP/1.1
Host: sandbox.britepaymentgroup.com
Content-Type: application/json

{
    // Your currently used access_token
    "access_token": "d98479174cac814bc9ddee617885694d8d9d10b11175d13872d3364a450961e94f7d296dec956f81",
    // The associated refresh_token
    "refresh_token": "503b3b90a175f30c84f1dcf57af379e018d383f64d533ea910ccfd14c1a1a384b0013b4ee84c6352"
}

Response - HTTP 200

				
					HTTP 200 OK
{
    "access_token": "4d851354fe2a6682b5bdc38e3f332b6630a2432d6f024922989dce9f171a662ea92ed9f0ab0df97a",
    "expires": 1743696549.0,
    "refresh_token": "834a4b057450ab3a1d0dadb2bad428f70e277f20839532df42291e1f2d2efc460aa6b0bb5fff8cf5"
}

On this page