Connecting/Disconnecting to your Pay Advantage App

Connecting Merchants To Your Pay Advantage App

Pay Advantage uses OAuth 2.0 to allow merchants to connect to your app.

An overview of connecting a merchant to your app.

  • Your App directs the User’s browser to Pay Advantage’s authorize URL.
  • The User logs into Pay Advantage and authorises your app for one of their Merchant Accounts.
  • The User’s browser is redirected to your site with a “code”.
  • Your App then sends this code to the Pay Advantage API in exchange for an Access Token and a Refresh Token.
  • Your App then has scoped access to the authorized Merchant Account using the Access Token.
  • 🚧

    It is your App’s responsibility to ensure that the Refresh Token is kept protected. If a malicious party is able to get the Refresh Token, then they will be able to generate Access Tokens and access the Merchant’s data.

Which Oauth 2.0 option to use?

iOS and Android application authentication solution

This option is ideal for iOS and Android based applications that need to make API calls directly from the application. If the application has a server, it is preferred to pass the access token request to the server as seen in the following two authentication options.

Single page application authentication solution

This option can be implemented using iOS, Android and Single Page Applications. It ensures that the server makes the request for authentication and access is then controlled via server to server communication.

Server stored secret key authentication

This option is the simplest to implement. The request to obtain the token is created using a secured secret key. This option relies on the secret kept safe and then provides an easy way to authenticate and complete server to server communication.

Creating the initial Authorization Request

Live URL

Test URL

The URL will have the following parameters appended.

client_idThis uniquely identifies your app and will be provided during the registration of your app.True
redirect_uriThe URI that the browser will be directed to once the OAuth process is complete.True
stateData that will be sent back to you in the response.Recommended
response_modeControls how the response will be sent back to the redirect_uri.

Must be one of:

- form_post
- fragment
- query (Default)
response_typeFor now, we only accept “code”.Required
code_challengeSee Code Challenge (PKCE) below.False
code_challenge_methodThe method used to verify the code_challenge:

- S256
- Plain (Not Accepted, deprecated)
grant_typeFor now, we only accept “authorization_code”True
instance_idIdentifies the instance of the app that this is for.False
instance_nameDefault display name for the instance of the app.

When not supplied, this will default to the referrer’s origin. The user has the ability to rename this to something that makes sense to them. For example “Tim’s iPhone” on a device-based app.

Extra details are located under the Oauth section

Example Authorisation Request - Secret Request

Example Authorisation Request - PKCE Request

Authorisation Code Response

Example Responses - Form Post

Successful Response when response_mode is form_post  
URL: <>  
Method: POST  
Content-Type: application/x-www-form-urlencoded

Failed Response when response_mode is form_post  
URL: <>  
Method: POST  
Content-Type: application/x-www-form-urlencoded


Example Responses - Query


Example Responses - Query


Code Challenge (PKCE)
The Code Challenges protects apps by only allowing the initiator the ability to resolve the authorization code.

Before the authorization request is made, the app will create a “code verifier”. This is a cryptographically random string using the characters A-Z, a-z, 0-9, and the punctuation characters -._~ (hyphen, period, underscore, and tilde), between 43 and 128 characters long.

Then the app will then use a BASE64-URL encoded string of the SHA256 hash of the code verifier as the code_challenge, and “S256” as the code_challenge_method.

Access Token Request

The access token request is made using the following API once the Authorisation Request has been made and the response received. For details on how to call the access token request refer to the following documentation.