Authentication methods

There are two authentication methods used within the Viva Wallet platform: basic authentication and identity server authentication. The difference between these is outlined below.

Basic authentication

For APIs that use basic HTTP authentication over SSL, every request should include a standard authorization header with the following:

  • Username
    This is your unique MerchantId available on your profile page in the banking app.

  • Password
    The transaction password or API Key is also shown on your profile page. This is different from the password you use to access your account from the Viva Wallet website.

You can view working samples for passing the Authorization header in the samples available on the Viva Wallet GitHub page .

Create unlimited demo accounts . For the demo environments, you are required to set a new transaction password in your demo profile.

Identity server (OAuth2)

Some API calls might not support basic authentication, in which case OAuth2 should be implemented.

Environment Endpoint
Demo https://demo-accounts.vivapayments.com/connect/token
Production https://accounts.vivapayments.com/connect/token

The identity server is an OpenID Connect Provider. It is used to:

  • manage and authenticate client applications
  • issue identity and access tokens to client applications
  • validate tokens.

Step 1: Request bearer token

Resource access is allowed to clients only with the use of access tokens. The first step before issuing any calls to the Viva Payments API is to obtain an access token by making a POST request as shown below:

 POST https://accounts.vivapayments.com/connect/token HTTP/1.1
 Authorization: Basic dGVzdC1jbGllbnQtYXBwOnRlc3Qtc2VjcmV0 (*note* these are the client's credentials encoded in base64 format)
 Accept: application/json
 Content-Type: application/x-www-form-urlencoded
 grant_type=client_credentials

Step 2: Accept and store bearer token

Upon successful authentication the identity server will respond by providing the access token requested:

     {
       "access_token":
       "eyJhbGciOiJSUzI1NiIsImtpZCI6IjZCN0FDQzUyMDMwNUJGREI0RjcyNTJEQUVCMjE3N0NDMDkx RkFBRTEiLCJ0eXAiOiJKV1QiLCJ4NXQiOiJhM3JNVWdNRnY5dFBjbExhNnlGM3pBa2ZxdUUifQ.ey JuYmYiOjE0OTAwMDA1NDksImV4cCI6MTQ5MDAwNDE0OSwiaXNzIjoiaHR0cHM6Ly9hY2NvdW50cy5 1YXQudml2YXBheW1lbnRzLmNvbSIsImF1ZCI6WyJodHRwczovL2FjY291bnRzLnVhdC52aXZhcGF5 bWVudHMuY29tL3Jlc291cmNlcyIsIlB1YmxpY0FwaSJdLCJjbGllbnRfaWQiOiJtZXJjaGFudDEiL CJzY29wZSI6WyJodHRwczovL2FwaS52aXZhcGF5bWVudHMuY29tL2F1dGgvYmFua2FjY291bnRzIi wiaHR0cHM6Ly9hcGkudml2YXBheW1lbnRzLmNvbS9hdXRoL2NhcmRzIiwiaHR0cHM6Ly9hcGkudml 2YXBheW1lbnRzLmNvbS9hdXRoL3dhbGxldHMiXX0.IdCvdIEMWMb1AiLNHXbZwWOhRmmqEaDlykmB K4GW29i7Uy6DqJGsS3JCpt7PlYyX9qMR5RCrIPLMUAXS9hqjbIAP2uCy- bfbM_UY10Tf_adTOBpRwD-CkTupuMdLT8gvqFHsnjhw26a_wnQZG5lTidGRG4xmp- oXDHrScB5iqMdci93Cq9f_EFQPBRY5lszQOrqpV2Midl5cW6fJzlb-Rsq4EWUEI2YkGNeJKn- ENQBXh6- nChkleYtHX5CT1kQouf3moC_bybp9ZNEfQUXT544PEquE_ZBX4fJl8dVOIV7A9B1svBN_AsX__dfc 5NHCQWFo8C1Wa-dCHPOI5-9O5w",
       "expires_in": 3600,
       "token_type": "Bearer"
     }

Step 3: Make calls to the API

From now on the Client can access API resources with the use of the access token until it expires and then must be renewed. Each following call to the API must include the access token at the authorization header with scheme bearer instead of basic.