Skip to main content

Issue an Access Token

POST 
/auth/brands/:brandIdentity/token

Overview​

The token endpoint is used by the client to obtain an access token utilizing the following grant types:

  • Client Credentials
  • Refresh Token
  • Token Exchange
  • Password
  • Authorization Code

Since the requests to the token endpoint result in the transmission of clear-text credentials (in the HTTP request and response), the client server MUST use TLS when sending requests to it.

Basic Authentication​

Basic Authentication is used for authenticating a client. In this mechanism, the client sends its client ID and client secret as part of the Authorization header in an HTTP request. The Authorization header contains a Base64-encoded string of {URL-encoded-client-ID}:{URL-encoded-client-secret}.

SCA Authentication​

The necessity for SCA Authentication arises when customers need to adhere to the particular regulations outlined in the PSD2 directive.

The HTTP WWW-Authenticate response header defines the SCA authentication methods that might be used to gain access to the specific resource:

HTTP/2 401 Unauthorized
WWW-Authenticate: SCA realm="Authentication" auth-param1="ewogICJzY2FEZXRhaWxzIjogewogICAgImV2ZW50SWQiOiAiMDZiZGMyYzAtY2NlLTRiMzYtOTdlYy0yODFjOGY1ZDc0M2MiLAogICAgIndhbGxldE9wZXJhdGlvbklkIjogImE1ODY1ZmQ2LTE4YzItNDVhOC05OTUzLTFjMDBlYWMzNmMzNiIsCiAgICAiYXV0aGVudGljYXRpb25Nb2RlIjogIk9VVFNPVVJDRUQiLAogICAgImF2YWlsYWJsZVZlcmlmaWNhdGlvbnMiOiBbCiAgICAgIHsKICAgICAgICAibWV0aG9kIjogIlBJTiIKICAgICAgfSwKICAgICAgewogICAgICAgICJtZXRob2QiOiAiT1RQIiwKICAgICAgICAiY2hhbm5lbCI6ICJTTVMiLAogICAgICAgICJ0YXJnZXQiOiAiam8qKipAZXhhbXBsZS5jb20iCiAgICAgIH0KICAgIF0sCiAgICAiY3JlYXRpb25UaW1lIjogIjIwMjEtMDctMTVUMTc6NTQ6MTJaIiwKICAgICJleHBpcmF0aW9uVGltZSI6ICIyMDIxLTA3LTE1VDE4OjA5OjEyWiIKICB9Cn0="

Upon the successful completion of the SCA authentication process, the user should re-request the same wallet resource. This should be done using the SCA-Authorization request header:

POST /digitalwallets/v1/auth/brands/{brandIdentity}/token HTTP/2
Host: api.paysafe.com
SCA-Authorization: ewogICJzY2FEZXRhaWxzIjogewogICAgImV2ZW50SWQiOiAiMDZiZGNkMmMtMGNjZS00YjM2LTk3ZWMtMjgxYzhmNWQ3NDNjIiwKICAgICJ3YWxsZXRPcGVyYXRpb25JZCI6ICJhNTg2NWZkNi0xOGMyLTQ1YTgtOTk1My0xYzAwZWFjMzZjMzYiCn0=

More details can be found in Strong Customer Authentication.

Attestation Authentication
Feature in development
​

The necessity for ATT Authentication arises when customers need to adhere to the particular secuirty standards.

The HTTP WWW-Authenticate response header defines the ATT authentication specifics that might be used to gain access to the specific resource:

HTTP/2 401 Unauthorized
WWW-Authenticate: ATT realm="Authentication" auth-param1="ewogICAgImF0dGVzdGF0aW9uRGV0YWlscyI6IHsKICAgICAgICAiZGV2aWNlSWQiOiAiODk1NEJGRjItNTc3NC00Q0VCLTkwMTctRjhBNzk3RUJFODk3IiwKICAgICAgICAid29ya2Zsb3dJZCI6ICJlYTk4Y2FhNi1lODc3LTQwY2ItODIwZS0wMTRkYWI4Nzg2YWYiLAogICAgICAgICJvc05hbWUiOiAiQU5EUk9JRCIsCiAgICAgICAgIndhbGxldE9wZXJhdGlvbiI6ICJBVVRIRU5USUNBVElPTiIsCiAgICAgICAgImF0dGVzdGF0aW9uTW9kZSI6ICJSRVFVSVJFRCIsCiAgICAgICAgIm5vbmNlIjogImUzZDljM2M0LWUwYzktNGZkYS1iZDU1LWUwODBlN2M4Mzc4MyIsCiAgICAgICAgImV4cGlyYXRpb25UaW1lIjogIjIwMTktMDgtMjRUMTQ6MTU6MjJaIgogICAgfQp9"

Upon the successful completion of the ATT authentication process, the system should re-request the same wallet resource. This should be done using the ATT-Authorization request header:

POST /digitalwallets/v1/auth/brands/{brandIdentity}/token HTTP/2
Host: api.paysafe.com
ATT-Authorization: ewogICAgImF0dGVzdGF0aW9uRGV0YWlscyI6IHsKICAgICAgICAiZGV2aWNlSWQiOiAiODk1NEJGRjItNTc3NC00Q0VCLTkwMTctRjhBNzk3RUJFODk3IiwKICAgICAgICAiYXR0ZXN0YXRpb25LZXlJZCI6ICJRV2s2bHhmaUFDSDlWaU94SDlYdFZ4K2h3Tk1NMXcrUmFET1VvL3JiYk84PSIsCiAgICAgICAgImF0dGVzdGF0aW9uVG9rZW4iOiAiZXlKaGJHY2lPaUpTVXpJMU5pSXNJblI1Y0NJNklrcFhWQ0o5IiwKICAgICAgICAidG14U2Vzc2lvbklkIjogImJlMDY2NWY3LTE5OTAtNGQ2Ni04NDY5LWFjYWQ0ZTk3NmFiOSIsCiAgICAgICAgIm9zTmFtZSI6ICJBTkRST0lEIgogICAgfQp9

Request​

Responses​

OK